After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 709064 - flicker of content from other workspaces when closing last window
flicker of content from other workspaces when closing last window
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 708842 709295 710660 715072 715153 720018 720889 721133 723984 725387 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-09-30 03:33 UTC by Allison Karlitskaya (desrt)
Modified: 2014-02-28 10:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screencast of the issue (447.12 KB, video/webm)
2013-09-30 03:33 UTC, Allison Karlitskaya (desrt)
  Details
windowManager: Activate new workspace before removing the current one (1.78 KB, patch)
2013-10-01 20:23 UTC, Florian Müllner
committed Details | Review
windowManager: Don't remove the active workspace (2.65 KB, patch)
2013-10-01 20:25 UTC, Florian Müllner
committed Details | Review

Description Allison Karlitskaya (desrt) 2013-09-30 03:33:21 UTC
Since upgrading to 3.10:

When I close the last window on an otherwise-empty workspace, I briefly see the contents of other workspaces flicker onto the screen before I (correctly) see the empty desktop.
Comment 1 Allison Karlitskaya (desrt) 2013-09-30 03:33:46 UTC
Created attachment 256050 [details]
Screencast of the issue
Comment 2 Rui Matos 2013-09-30 09:01:11 UTC
*** Bug 708842 has been marked as a duplicate of this bug. ***
Comment 3 Florian Müllner 2013-10-01 20:23:30 UTC
Created attachment 256219 [details] [review]
windowManager: Activate new workspace before removing the current one

When removing the current workspace, the active workspace is changed
to the preceding one automatically before we change explicitly to the
last workspace. There is no good reason to change workspaces twice in
this case, we can avoid the first one just by changing to the new
workspace before removing any workspaces.


I'm not quite sure why, but this change appears to make the block-animations code that is already there work reliably.
Comment 4 Florian Müllner 2013-10-01 20:25:31 UTC
Created attachment 256220 [details] [review]
windowManager: Don't remove the active workspace

Currently workspaces (except for the last one) are removed when
they become empty. While we do have special treatment for the
case where the currently active workspace is removed, we just
move directly without animations to the last workspace to avoid
ending up on a "random" workspace. However this behavior is still
a bit confusing, so keep the workspace around instead until the
user decides to move to another one.


Here is an alternative approach that changes the behavior of workspace removal which happens to fix this issue as a side effect. Obviously needs design review ...
Comment 5 Florian Müllner 2013-10-02 18:22:50 UTC
*** Bug 709295 has been marked as a duplicate of this bug. ***
Comment 6 Florian Müllner 2013-10-12 23:35:25 UTC
This would be a nice polish fix for 3.10.1
Comment 7 Rui Matos 2013-10-22 16:00:16 UTC
*** Bug 710660 has been marked as a duplicate of this bug. ***
Comment 8 Florian Müllner 2013-11-23 17:01:09 UTC
*** Bug 715072 has been marked as a duplicate of this bug. ***
Comment 9 Florian Müllner 2013-11-25 16:11:35 UTC
*** Bug 715153 has been marked as a duplicate of this bug. ***
Comment 10 Florian Müllner 2013-12-06 22:01:48 UTC
*** Bug 720018 has been marked as a duplicate of this bug. ***
Comment 11 Emmanuel Pacaud 2013-12-06 22:17:41 UTC
The second patch would be very welcome, as I agree it is quite confusing to be moved to the last workspace after we close the last window of a workspace.
Comment 12 Florian Müllner 2013-12-21 18:15:21 UTC
*** Bug 720889 has been marked as a duplicate of this bug. ***
Comment 13 Lionel Landwerlin 2013-12-22 14:10:32 UTC
Any plan to merge to patches upstream?
Comment 14 Jasper St. Pierre (not reading bugmail) 2013-12-22 16:42:59 UTC
There's two solutions, but we need design review to determine which one to push.
Comment 15 Florian Müllner 2013-12-27 22:01:24 UTC
*** Bug 721133 has been marked as a duplicate of this bug. ***
Comment 16 Florian Müllner 2014-02-09 22:18:08 UTC
*** Bug 723984 has been marked as a duplicate of this bug. ***
Comment 17 Florian Müllner 2014-02-19 20:18:51 UTC
Comment on attachment 256219 [details] [review]
windowManager: Activate new workspace before removing the current one

Attachment 256219 [details] pushed as 0dab133 - windowManager: Activate new workspace before removing the current one
Comment 18 Florian Müllner 2014-02-19 20:54:21 UTC
Attachment 256220 [details] pushed as 2631f03 - windowManager: Don't remove the active workspace

(That's the approach the designer's preferred, but as it changes behavior, I pushed the alternative to 3-10).
Comment 19 Ferry Huberts 2014-02-20 10:47:09 UTC
(In reply to comment #18)
> Attachment 256220 [details] pushed as 2631f03 - windowManager: Don't remove the active
> workspace
> 
> (That's the approach the designer's preferred, but as it changes behavior, I

IMHO that solution is what should be done. It's way more intuitive
Comment 20 Ferry Huberts 2014-02-20 11:04:30 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > Attachment 256220 [details] [details] pushed as 2631f03 - windowManager: Don't remove the active
> > workspace
> > 
> > (That's the approach the designer's preferred, but as it changes behavior, I
> 
> IMHO that solution is what should be done. It's way more intuitive

As an example:

I run Eclipse on the workspace and have my gitk and git gui and terminal on a different workspace, the one below.

When I restart Eclipse, it goes away, the workspace is removed, Eclipse comes up again, and now Eclipse is on the workspace below the git tools instead of above it. Very very annoying...

This is but 1 example.
I strongly believe that the active workspace should never be removed (or reordered for that matter)
Comment 21 Florian Müllner 2014-02-20 12:07:52 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > (That's the approach the designer's preferred, but as it changes behavior, I
> 
> IMHO that solution is what should be done. It's way more intuitive

Yes, and it's the solution that got committed to master (the upcoming 3.12). The other patch was just pushed to the stable branch, as changing behavior of a stable version shortly before the next one will be released is a bit questionable.
Comment 22 Ferry Huberts 2014-02-20 13:45:38 UTC
(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > (That's the approach the designer's preferred, but as it changes behavior, I
> > 
> > IMHO that solution is what should be done. It's way more intuitive
> 
> Yes, and it's the solution that got committed to master (the upcoming 3.12).
> The other patch was just pushed to the stable branch, as changing behavior of a
> stable version shortly before the next one will be released is a bit
> questionable.

So 3.12 will have the behaviour I described in comment 20?
That will be awesome!
Thanks!
Comment 23 Florian Müllner 2014-02-20 13:51:27 UTC
(In reply to comment #22)
> So 3.12 will have the behaviour I described in comment 20?

Yes, in 3.12 an empty workspace will only be removed once you move away from it (e.g. never when it is active)
Comment 24 Florian Müllner 2014-02-28 10:17:06 UTC
*** Bug 725387 has been marked as a duplicate of this bug. ***