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 695487 - Gnome shell reset moves windows to a different workspace
Gnome shell reset moves windows to a different workspace
Product: gnome-shell
Classification: Core
Component: general
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
: 709997 (view as bug list)
Depends on:
Reported: 2013-03-09 10:55 UTC by James
Modified: 2014-06-09 20:37 UTC
See Also:
GNOME target: ---
GNOME version: ---

main: Move pref overrides back into C (6.67 KB, patch)
2014-06-06 13:27 UTC, Florian Müllner
committed Details | Review

Description James 2013-03-09 10:55:36 UTC
After about a day my GNOME shell gets sluggish. My workaround is to run: Alt-F2 r, to reset the shell. It is great that this exists, because it doesn't close all the apps. However, any windows on the last workspace get moved, usually to the before last workspace.

I currently have six workspaces.

Let me know if you don't get this same behaviour when you test.

Comment 1 James 2013-03-09 11:04:27 UTC
After further testing, I put one window on workspace seven, and I had stuff on workspace six. I did a reset, and the one window went to #5, and everything on #6 went to #1...

Weird :(
Comment 2 Milan Bouchet-Valat 2013-03-09 11:12:28 UTC
Yeah, I've noticed this too with 3.6. If I remember correctly, most windows went to the first workspace, but not all of them (at least not all the time).
Comment 3 kritphong 2013-04-30 07:08:08 UTC
Seems to be fixed 3.8.1
Comment 4 James 2013-05-01 04:28:12 UTC
(In reply to comment #3)
> Seems to be fixed 3.8.1

Can you confirm that it's fixed when you're using 5 or more workspaces ? (with stuff on each)
Comment 5 kritphong 2013-05-01 08:12:10 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Seems to be fixed 3.8.1
> Can you confirm that it's fixed when you're using 5 or more workspaces ? (with
> stuff on each)

I just tested with 6 workspaces. Seems to work fine.
Comment 6 Nuno Araujo (IRC: russo79) 2013-06-08 08:21:54 UTC
For me this was fully working with version 3.8.2 (even with only 2 workspaces).
Now that I have updated to version 3.8.3, the old behavior (all windows go to the first workspace again).
Comment 7 James 2014-05-29 06:03:35 UTC
This still happens on GNOME 3.12, although not consistently.
Comment 8 James 2014-05-29 06:06:28 UTC
Possible dup:
Comment 9 Didier M. 2014-05-29 08:58:15 UTC
When, after a crash, Gnome Shell erroneously restores 30+ windows (formerly spread over 6+ workspaces) to one single workspace, this is a lifesaver :
Comment 10 Florian Müllner 2014-05-29 09:06:53 UTC
(In reply to comment #8)
> Possible dup:

No, different issue. This bug was fixed with, but broke shortly after with 
I hope to get this fixed for 3.14, in the meanwhile you should be able to work around the issue by running
  gsettings set org.gnome.mutter dynamic-workspaces true
Comment 11 Florian Müllner 2014-05-30 18:45:56 UTC
*** Bug 709997 has been marked as a duplicate of this bug. ***
Comment 12 Florian Müllner 2014-06-06 13:27:13 UTC
Created attachment 278030 [details] [review]
main: Move pref overrides back into C

Commit 6c2f3d1d178a65d moved pref overrides into JS to implement
session mode specific overrides in a clean and generic way.
However that approach comes with a cost - doing the overrides only
after having handled over control to JS means that the core will
be initialized with the non-overridden settings before changing
to the correct values. In the best case this is unnecessary work,
but it can in fact have a worse effect: when initializing workspaces,
we will restore the previous number of workspaces when using
dynamic-workspaces and reset to the configured number otherwise.
As the non-overridden default for dynamic-workspaces is FALSE, we
can easily end up moving the user's windows to the "wrong" workspace.

Now GSettings is expected to grow support for session specific defaults,
which will render our entire override system obsolete (yay!). Given
that, it seems acceptable to use a less generic (and uglier) approach
in the meanwhile, in order to fix aforementioned problems. So move
overrides back before core initialization and just hardcode the
session-mode => override-schema relation.
Comment 13 Jasper St. Pierre (not reading bugmail) 2014-06-09 19:36:39 UTC
Review of attachment 278030 [details] [review]:

Comment 14 Florian Müllner 2014-06-09 20:37:34 UTC
Attachment 278030 [details] pushed as ae2751a - main: Move pref overrides back into C