Bug 1754630 - Automatic workspaces are seriously broken
Summary: Automatic workspaces are seriously broken
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Müllner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F31FinalBlocker, FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2019-09-23 18:44 UTC by Peter Simonyi
Modified: 2019-10-11 01:23 UTC (History)
14 users (show)

Fixed In Version: gnome-shell-3.34.1-1.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-10 18:27:04 UTC


Attachments (Terms of Use)
Screencast of issue (1.16 MB, video/webm)
2019-09-28 17:51 UTC, Jonathan Haas
no flags Details
Screenshot before crash (979.21 KB, image/png)
2019-09-28 18:03 UTC, Jonathan Haas
no flags Details
Screencast of issue (570.12 KB, video/webm)
2019-09-28 18:14 UTC, Jonathan Haas
no flags Details
Backtrace (21.67 KB, text/plain)
2019-09-30 13:52 UTC, Jonathan Haas
no flags Details


Links
System ID Priority Status Summary Last Updated
GNOME Gitlab GNOME/gnome-shell/issues/1497 None None None 2019-09-25 15:10:41 UTC

Description Peter Simonyi 2019-09-23 18:44:25 UTC
Description of problem:
With the default automatic workspaces, any empty workspaces other than the current one are automatically removed.  However, if a non-active workspace is emptied by closing the windows in it without using the shell, some workspaces can become "stuck" and not close until you log out.

Version-Release number of selected component (if applicable):
gnome-shell-3.34.0-2.fc31.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Open several windows in some multi-window application.  I've tried this with Firefox and Nautilus ("Files").
2. Open another application window, e.g. Terminal.
3. Arrange the windows in workspaces as follows:
 Workspace 1: Nautilus
 Workspace 2: Terminal
 Workspace 3: Nautilus
4. Go to Workspace 1 and quit Nautilus (Ctrl+Q); this will also close the window in workspace 3.

Actual results:
Workspace 3 is still present, though empty.  Further window rearrangements won't dismiss it either.

Expected results:
Workspace 3, being empty, is removed.  The remaining workspaces are 1 (empty but still present because it's the current one) and 2 (because it still has the Terminal window).

Additional info:
The extra workspace with an unrelated window and no windows from Nautilus/Firefox/whatever seems to be required to make this bug appear.

You can make more than just one perma-workspace by having more than one workspace with a Nautilus window following the one with the Terminal window.

After getting one of these perma-workspaces, arranging windows into workspaces sometimes gets messed up in all kinds of weird ways, e.g. moving windows between workspaces 3 and 4 might also move windows in workspaces 1 or 2.

Comment 1 Michael Catanzaro 2019-09-25 15:07:19 UTC
Well it's more than that. We have several related regressions here:

 * The issue reported above, empty workspaces lingering when they should be removed.
 * Dragging windows to a workspace in the shell overview sometimes causes the window to move to the wrong workspcae (the workspace above)
 * Dragging windows to a workspace very frequently causes the entire shell to crash. gnome-shell 3.34 seems to be suppressing core dumps, so it's impossible to provide a backtrace. But this is really easy to reproduce by just dragging windows around in the overview's workspace switcher. Either pick up one window and drag it from workspace to workspace (it should crash quickly), or pick up icons from the dash and drag them into workspaces to launch new applications.

I'm piling onto this bug rather than creating two new ones because I think this is likely all one underlying issue. The workspace switcher has been 100% reliable for many years, and now all of a sudden all these bugs occur all at once. It smells like one underlying state tracking issue, something like that.

This is all serious and should be a blocker under either the default panel functionality criterion, depending on how loosely we interpret the word "panel," or the data loss criterion, because it's really easy to trigger a full desktop crash (and lose all your work) just by using normal functionality of the shell.

Comment 2 Fedora Blocker Bugs Application 2019-09-25 15:09:29 UTC
Proposed as a Blocker for 31-final by Fedora user catanzaro using the blocker tracking app because:

 All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use.

Comment 3 Adam Williamson 2019-09-25 15:47:21 UTC
Yeah, I'd be +1 especially for the "Dragging windows to a workspace very frequently causes the entire shell to crash" element. And yes, workspace switching would be considered part of the 'panel', we generally interpret 'panel' for Shell to include the top menu and all the things on it, plus the functionality of the overview.

Comment 4 Michael Catanzaro 2019-09-25 20:52:47 UTC
Note we can't really debug the crash until we first solve bug #1754867.

Comment 5 Kamil Páral 2019-09-26 11:35:18 UTC
I can reproduce the original issue from comment 0.

(In reply to Michael Catanzaro from comment #1)
>  * Dragging windows to a workspace very frequently causes the entire shell
> to crash. gnome-shell 3.34 seems to be suppressing core dumps, so it's
> impossible to provide a backtrace. But this is really easy to reproduce by
> just dragging windows around in the overview's workspace switcher. Either
> pick up one window and drag it from workspace to workspace (it should crash
> quickly), or pick up icons from the dash and drag them into workspaces to
> launch new applications.

I spent 5 minutes dragging windows, but I'm unable to cause gnome-shell to crash. Are there some reliable reproduction steps?

Comment 6 Michael Catanzaro 2019-09-26 16:10:13 UTC
I don't have reliable steps.

Yesterday I was able to crash it twice by doing this, with little effort. And I've triggered the crash by accident several more times in the past week. But today, hoping to find a reliable reproducer, I failed to make it crash at all. Instead I managed to get my shell into some really broken state where I could not exit the overview or interact with applications....

Comment 7 Jonathan Haas 2019-09-28 17:51:38 UTC
Created attachment 1620586 [details]
Screencast of issue

I can crash my shell easily. Attached some video that shows the first steps. You basically drag one or two windows repeatedly between workspaces, which will actually add the window to the upper workspace and create an empty one below (instead of adding the window to the new empty one). Once you have 3 empty workspaces at the bottom, dragging a window between the bottom two will crash pretty reliably the shell.

Comment 8 Jonathan Haas 2019-09-28 18:03:32 UTC
Created attachment 1620598 [details]
Screenshot before crash

Once you reached this state, dragging a window to one of the workspaces below or between them reliable crashes the shell. One time, I also experienced that it gets stuck instead of crashing, so the activity view won't open anymore for example.

Comment 9 Jonathan Haas 2019-09-28 18:14:52 UTC
Created attachment 1620600 [details]
Screencast of issue

Uploaded a clearer video of the issue, the first one doesn't really show the problem

Comment 10 Kamil Páral 2019-09-30 10:27:31 UTC
I didn't manage to create so many empty workspaces as in comment 8. I managed to make gnome-shell crash once by dragging a window between workspaces repeatedly (the crash didn't how up in abrt nor coredumpctl, though), but it's not reliably reproducible for me.

Comment 11 Jonathan Haas 2019-09-30 10:42:05 UTC
I agree that it's not easy to crash the shell, you pretty much have to deliberately try it and I can only see that happening accidentally for users who (ab)use workspaces a lot and don't reboot their computer very often.

On the other hand, there is definitely some sort of data corruption going on with windows appearing on the wrong workspace and sometimes the shell locking up and so on. I would block more for being generally broken and less for the occasional crash (even though it's obviously bad and can lead to data loss).

> the crash didn't how up in abrt nor coredumpctl, though

Dis you try with Bug 1748145 fixed? If not I can try if I manage to get a backtrace with that update applied.

Comment 12 Jonathan Haas 2019-09-30 13:52:20 UTC
Created attachment 1621147 [details]
Backtrace

Managed to get a backtrace.

Comment 13 Geoffrey Marr 2019-09-30 23:10:43 UTC
Discussed during the 2019-09-30 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criteria:

"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" and "All known bugs that can cause corruption of user data must be fixed or documented at Common F31 bugs" (as any Shell crash on Wayland can cause data loss/corruption).

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-30/f31-blocker-review.2019-09-30-16.00.txt

Comment 14 Kamil Páral 2019-10-01 10:19:16 UTC
Please note that this bug has been accepted as a blocker because of the *crash* that happens occasionally (see comment 12) and makes users lose all their unsaved work. The fact that workspaces don't always behave correctly might be related to the crash, but it's not the basis for blocking the release.

Comment 15 Adam Williamson 2019-10-01 15:45:48 UTC
well...we accepted it with reference to the data loss criterion but also the default panel functionality criterion. Workspaces are certainly considered part of 'default panel functionality', by precedent. We didn't specifically unpick which elements we were blocking on in the meeting, but it's at least possible we'd consider the bad behaviour to be blocking as well as the crash.

Comment 16 Lukas Ruzicka 2019-10-03 11:02:09 UTC
On gnome-control-center-3.34.0.1-2.fc31.x86_64, I was not able to reproduce any of the described behaviour. The workspace icons behaved correctly as expected.
I even was not able to start Nautilus twice to put it on two different workspaces, any attempt to start it via the Menu brought me back to its original instance on the Workspace No. 1. 

Is the problem fixed, or I am doing it wrong?

Comment 17 Kamil Páral 2019-10-03 12:41:11 UTC
(In reply to Lukas Ruzicka from comment #16)
> I even was not able to start Nautilus twice to put it on two different
> workspaces, any attempt to start it via the Menu brought me back to its
> original instance on the Workspace No. 1. 

You can start another instance from the overview with right click -> new window, or with ctrl+left click. But I think it should not be related to this problem at all, you can easily just use multiple different app windows.

When I reproduced the crash, I was using just a single application window and dragged into onto and between workspaces over and over again.

Comment 18 Peter Simonyi 2019-10-03 20:57:50 UTC
(In reply to Lukas Ruzicka from comment #16)
> I even was not able to start Nautilus twice to put it on two different
> workspaces, any attempt to start it via the Menu brought me back to its
> original instance on the Workspace No. 1. 

If you're trying to follow my STR from comment 0, you can open new Nautilus windows from an existing one with Ctrl+N, or the New Window button at the top of the hamburger menu, or, as kparal says in comment 17, from the New Window command in the overview, or from the app menu in the top bar.

Comment 19 Fedora Update System 2019-10-09 08:34:50 UTC
FEDORA-2019-8f20f9e4e3 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8f20f9e4e3

Comment 20 Fedora Update System 2019-10-09 23:05:28 UTC
accerciser-3.34.1-1.fc31, almanah-0.12.0-1.fc31, at-spi2-atk-2.34.1-1.fc31, eog-3.34.1-1.fc31, epiphany-3.34.1-1.fc31, evince-3.34.1-1.fc31, evolution-3.34.1-1.fc31, evolution-data-server-3.34.1-1.fc31, evolution-ews-3.34.1-1.fc31, evolution-mapi-3.34.1-1.fc31, four-in-a-row-3.34.1-1.fc31, gdk-pixbuf2-2.40.0-1.fc31, gdm-3.34.1-1.fc31, geary-3.34.1-2.fc31, gjs-1.58.1-1.fc31, glib-networking-2.62.1-1.fc31, glib2-2.62.1-1.fc31, gnome-2048-3.34.1-1.fc31, gnome-boxes-3.34.1-1.fc31, gnome-builder-3.34.1-1.fc31, gnome-calculator-3.34.1-1.fc31, gnome-calendar-3.34.1-1.fc31, gnome-control-center-3.34.1-3.fc31, gnome-desktop3-3.34.1-1.fc31, gnome-initial-setup-3.34.1-1.fc31, gnome-maps-3.34.1-1.fc31, gnome-session-3.34.1-2.fc31, gnome-shell-3.34.1-1.fc31, gnome-shell-extensions-3.34.1-1.fc31, gnome-software-3.34.1-1.fc31, gnome-taquin-3.34.1-1.fc31, gnome-terminal-3.34.1-1.fc31, gnome-tetravex-3.34.1-1.fc31, gpaste-3.34.1-1.fc31, gtk3-3.24.12-1.fc31, gvfs-1.42.1-1.fc31, iagno-3.34.1-1.fc31, libdazzle-3.34.1-1.fc31, libgweather-3.34.0-1.fc31, librsvg2-2.46.1-1.fc31, libsoup-2.68.2-1.fc31, mutter-3.34.1-1.fc31, nautilus-3.34.1-1.fc31, quadrapassel-3.34.1-1.fc31, simple-scan-3.34.1-1.fc31, sysprof-3.34.1-1.fc31, totem-3.34.1-1.fc31, vala-0.46.3-1.fc31, vte291-0.58.1-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-8f20f9e4e3

Comment 21 Kamil Páral 2019-10-10 13:08:14 UTC
Peter, Michael, J. Haas, can you please try the behavior with the updates packages from comment 20? Please try whether the workspaces still behave incorrectly and whether you can still reproduce the gnome-shell crash. Thank you.

Comment 22 Jonathan Haas 2019-10-10 13:11:03 UTC
It seems to work fine with the latest updates-testing packages installed, can't reproduce any weird behaviour or crash anymore.

Comment 23 Michael Catanzaro 2019-10-10 17:06:26 UTC
Yes, I agree it seems to be fixed.

Comment 24 Adam Williamson 2019-10-10 17:12:05 UTC
OK, let's call this VERIFIED then.

Comment 25 Fedora Update System 2019-10-10 18:27:04 UTC
accerciser-3.34.1-1.fc31, almanah-0.12.0-1.fc31, at-spi2-atk-2.34.1-1.fc31, eog-3.34.1-1.fc31, epiphany-3.34.1-1.fc31, evince-3.34.1-1.fc31, evolution-3.34.1-1.fc31, evolution-data-server-3.34.1-1.fc31, evolution-ews-3.34.1-1.fc31, evolution-mapi-3.34.1-1.fc31, four-in-a-row-3.34.1-1.fc31, gdk-pixbuf2-2.40.0-1.fc31, gdm-3.34.1-1.fc31, geary-3.34.1-2.fc31, gjs-1.58.1-1.fc31, glib-networking-2.62.1-1.fc31, glib2-2.62.1-1.fc31, gnome-2048-3.34.1-1.fc31, gnome-boxes-3.34.1-1.fc31, gnome-builder-3.34.1-1.fc31, gnome-calculator-3.34.1-1.fc31, gnome-calendar-3.34.1-1.fc31, gnome-control-center-3.34.1-3.fc31, gnome-desktop3-3.34.1-1.fc31, gnome-initial-setup-3.34.1-1.fc31, gnome-maps-3.34.1-1.fc31, gnome-session-3.34.1-2.fc31, gnome-shell-3.34.1-1.fc31, gnome-shell-extensions-3.34.1-1.fc31, gnome-software-3.34.1-1.fc31, gnome-taquin-3.34.1-1.fc31, gnome-terminal-3.34.1-1.fc31, gnome-tetravex-3.34.1-1.fc31, gpaste-3.34.1-1.fc31, gtk3-3.24.12-1.fc31, gvfs-1.42.1-1.fc31, iagno-3.34.1-1.fc31, libdazzle-3.34.1-1.fc31, libgweather-3.34.0-1.fc31, librsvg2-2.46.1-1.fc31, libsoup-2.68.2-1.fc31, mutter-3.34.1-1.fc31, nautilus-3.34.1-1.fc31, quadrapassel-3.34.1-1.fc31, simple-scan-3.34.1-1.fc31, sysprof-3.34.1-1.fc31, totem-3.34.1-1.fc31, vala-0.46.3-1.fc31, vte291-0.58.1-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 26 Peter Simonyi 2019-10-11 01:23:02 UTC
Thanks, this update has fixed the workspaces bug and quite a few other things besides.


Note You need to log in before you can comment on or make changes to this bug.