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.

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.

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.

Note we can't really debug the crash until we first solve bug #1754867.

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?

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....

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.

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.

Created attachment 1620600 [details]
Screencast of issue

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

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.

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.

Created attachment 1621147 [details]
Backtrace

Managed to get a backtrace.

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

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.

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.

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?

(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.

(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.

FEDORA-2019-8f20f9e4e3 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-8f20f9e4e3

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

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.

It seems to work fine with the latest updates-testing packages installed, can't reproduce any weird behaviour or crash anymore.

Yes, I agree it seems to be fixed.

OK, let's call this VERIFIED then.

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.

Thanks, this update has fixed the workspaces bug and quite a few other things besides.