gnome-shell issueshttps://gitlab.gnome.org/GNOME/gnome-shell/-/issues2024-03-27T20:18:54Zhttps://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7505Overview exits to wrong workspace after switching between two empty workspace...2024-03-27T20:18:54ZAniket MujumdarOverview exits to wrong workspace after switching between two empty workspaces on secondary screen<!--
Please read https://gitlab.gnome.org/GNOME/gnome-shell/-/tree/main#reporting-bugs
first to ensure that you create a clear and specific issue.
-->
<!--
Provide at least the following information:
* Your OS and version
* Affected GNO...<!--
Please read https://gitlab.gnome.org/GNOME/gnome-shell/-/tree/main#reporting-bugs
first to ensure that you create a clear and specific issue.
-->
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Shell version (see https://release.gnome.org/calendar/
for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
* Does this issue happen without extensions (please follow instructions below)
To properly disable extensions you can use gnome-extensions-app and then restart
your session. Disabling extensions without a restart is not sufficient to rule
out extensions as cause of a bug. If an issue can only be reproduced with a
certain extension, please file a bug report against that extension first.
-->
### Bug summary
Overview moves to next workspace instead of opening the workspace when I click on the current workspace.
This is on Wayland so I couldn't figure out a way to show mouse inputs.
I haven't tested whether the bug also happens on Xorg.
I have disabled all extensions and logged out and recorded the video attached.
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
1. Use a dual monitor setup, I haven't checked whether this only happens on dual monitors.
2. Open the overview on the primary monitor, and scroll to next workspace and then scrollback to first workspace
3. Repeat the same on the second monitor
4. Go to primary monitor and click on the current workspace
<!--
1. Step one
2. Step two
3. ...
-->
### What happened
It switches to the second workspace
<!--
What did GNOME Shell do that was unexpected?
-->
### What did you expect to happen
It should have opened the clicked workspace
<!--
What did you expect GNOME Shell to do?
-->
### Relevant logs, screenshots, screencasts etc.!
[Screencast_from_2024-03-21_22-12-36](/uploads/a1c02966222302c334fa8ae76fe9bc42/Screencast_from_2024-03-21_22-12-36.webm)
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Shell and Mutter) and attach it to
this issue following the instructions on
https://handbook.gnome.org/issues/stack-traces.html.
-->
### Affected version
# System Details Report
---
## Report details
- **Date generated:** 2024-03-21 22:29:36
## Hardware Information:
- **Hardware Model:** Lenovo IdeaPad Gaming 3 15ACH6
- **Memory:** 16.0 GiB
- **Processor:** AMD Ryzen™ 5 5600H with Radeon™ Graphics × 12
- **Graphics:** AMD Radeon™ Graphics
- **Graphics 1:** NVIDIA GeForce RTX™ 3050 Laptop GPU
- **Disk Capacity:** 1.5 TB
## Software Information:
- **Firmware Version:** H3CN32WW(V2.02)
- **OS Name:** Fedora Linux 39.20240319.0 (Silverblue nvidia-ublue Image)
- **OS Build:** (null)
- **OS Type:** 64-bit
- **GNOME Version:** 45.5
- **Windowing System:** Wayland
- **Kernel Version:** Linux 6.7.9-200.fc39.x86_64
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7130unnecessary creation and removing a workspace when opening dialog windows wit...2024-02-08T22:08:27Zdarkblaze69unnecessary creation and removing a workspace when opening dialog windows with workspaces-only-on-primary and 2 monitors* Arch / Fedora
* GNOME 45, Wayland session (44 seems affected too).
* X11 seems not affected.
Unnecessary creation and removing a workspace when opening a popup window like 'About' in any app.
Conditions:
* 2 monitors, join mode
* Pri...* Arch / Fedora
* GNOME 45, Wayland session (44 seems affected too).
* X11 seems not affected.
Unnecessary creation and removing a workspace when opening a popup window like 'About' in any app.
Conditions:
* 2 monitors, join mode
* Primary is on the right
* (check if `workspaces-only-on-primary` is true - which is default)
If you open a popup window like 'About' in any app, Shell will create a new workspace for a second and removes it (observe it by workspace indicator and Overview).
I believe it is so in 44 too, but with the introduction of Workspace indicator in 45 it became more visible.
**GNOME 45**
![Screencast_from_2023-10-24_00-25-17](/uploads/c79b99362d93607eec6bd2e86737e36a/Screencast_from_2023-10-24_00-25-17.webm)
**GNOME 44**
![Screencast_from_2023-10-24_00-29-46](/uploads/659350f24d8a7d8cc85780918e71e347/Screencast_from_2023-10-24_00-29-46.webm)https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7104Only include apps from current display in app switcher2023-10-16T11:44:42ZMladen SkrbicOnly include apps from current display in app switcherHello, I think this could be a bug, but maybe this is expected behavior. Currently when I have this setting turned on in Settings\> Multitasking\>App Switching, I can see apps from other displays in my alt+tab. I think this should not be...Hello, I think this could be a bug, but maybe this is expected behavior. Currently when I have this setting turned on in Settings\> Multitasking\>App Switching, I can see apps from other displays in my alt+tab. I think this should not be the case, most likely scenario is that when user has "Include apps from current workspace only" enabled, that means that alt-tab should only show apps from current display and current workspace of that display.
I tried to find if this is duplicate issue, but couldn't find one, sorry if I missed it.https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7089Inconsistency when Workspace Switching Interrupted by Three-Finger Gesture2023-11-21T22:05:20ZNin ZeigeInconsistency when Workspace Switching Interrupted by Three-Finger Gesture<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
- OS: archlinux with kernel 6.5.5
- gnome-shell 45.0 and earli...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
- OS: archlinux with kernel 6.5.5
- gnome-shell 45.0 and earlier
- Wayland
- reproducible with/without extensions
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Shell version (see https://wiki.gnome.org/Schedule for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
* Does this issue happen without extensions (please follow instructions below)
To properly disable extensions you can use gnome-extensions-app and then restart
your session. Disabling extensions without a restart is not sufficient to rule
out extensions as cause of a bug. If an issue can only be reproduced with a
certain extension, please file a bug report against that extension first.
-->
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
Using a three-finger gesture to interrupt a workspaces switching animation cause inconsistent behavior.
Based on the above situation and the apparent lack of intuitive behavior, I boldly speculate that this should be a bug.
### Steps to reproduce
1. Use a three-finger gesture to swipe left or right for workspace
2. Release and quickly swipe up with a three-finger gesture to enter the workspace overview interface before the switch animation completes.
3. Notice that the blue highlight box in the overview interface becomes stuck between two workspaces.
### What happened
<!--
What did GNOME Shell do that was unexpected?
-->
There are two main issues:
- When attempting to return to the workspace by swiping down with a three-finger gesture, it often returns to the previous workspace, even when the animation suggests otherwise. The blue highlight box remains in its incorrect.
- GNOME 45 introduced a new workspace indicator in the top left corner, which indicates the closer workspace when the switching animation was interrupted, instead of the one I stayed.
### What did you expect to happen
<!--
What did you expect GNOME Shell to do?
-->
I personally believe that the natural behavior should be to completely land back on the nearest workspace when the animation is interrupted by a gesture.
### Relevant screencasts
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Shell and Mutter) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
The following screenshot shows the situation when the highlight box stuck in the middle.
![Screenshot_from_2023-10-11_14-17-36](/uploads/3f266314bc20607bca0bcd813c6faa07/Screenshot_from_2023-10-11_14-17-36.png)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6901Empty workspaces don't cleanly get removed2023-10-29T04:54:42ZDallas StrouseEmpty workspaces don't cleanly get removed<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
## Hardware Information:
- **Hardware Model:** Micro-S...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
## Hardware Information:
- **Hardware Model:** Micro-Star International Co., Ltd MS-7C02
- **Memory:** 32.0 GiB
- **Processor:** AMD Ryzen™ 5 1600 × 12
- **Graphics:** AMD Radeon™ RX 5500 XT
- **Disk Capacity:** 4.0 TB
## Software Information:
- **Firmware Version:** 1.H5
- **OS Name:** Fedora Linux Rawhide.20230812.n.0 (Silverblue Prerelease)
- **OS Build:** (null)
- **OS Type:** 64-bit
- **GNOME Version:** 45.beta.1
- **Windowing System:** Wayland
- **Kernel Version:** Linux 6.5.0-0.rc5.20230811git25aa0bebba72.40.fc40.x86_64
### Bug summary
When closing a workspace, specifically by moving a window out of the current workspace, it will only update and remove the currently open workspace (if not the farthest right workspace) when scrolling to change workspaces or otherwise change the currently viewed workspace.
The workspace is also removed "suddenly", without any smooth animations.
### Steps to reproduce
1. Open several dynamic workspaces, each with their own set of applications (one min.)
2. Go to any workspace which has two other workspaces surrounding it
3. Move the windows from that workspace to a new workspace
### What happened
The empty workspace surrounded by other (used) workspaces wasn't removed automatically and cleanly
### What did you expect to happen
The empty workspace surrounded by other (used) workspaces would smoothly remove itself and rearrange without user interaction
![Screencast_from_2023-08-12_19-35-24](/uploads/edf160f2a135b53050ef0fd73a7a0cc5/Screencast_from_2023-08-12_19-35-24.webm)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6890Wrong starting point of "Show the overview" animation2023-11-04T03:46:01ZFedericoCalzoniWrong starting point of "Show the overview" animation### Affected version
- OS: Arch-Linux
- Gnome-Shell version: 44.3
- Windowing system: wayland
### Bug summary
The animation to show the overview starts from the wrong workspace if the animation to move to the next (or previous) workspac...### Affected version
- OS: Arch-Linux
- Gnome-Shell version: 44.3
- Windowing system: wayland
### Bug summary
The animation to show the overview starts from the wrong workspace if the animation to move to the next (or previous) workspace is not completed. in fact, if immediately after having made the workspace change gesture, an gesture to show the overview occurs, the animation of the show overview starts from the wrong workspace, like if no gesture to move to the next (or previous) workspace was made.
### Steps to reproduce
1. gesture to change workspace
2. gesture to show overview (immediately after)
### What happened
The animation starts from the wrong workspace
### What did you expect to happen
If at least half of the transition to the next (or previous) workspace is made, the transition should start from the next (or previous) workspace.
### Relevant logs, screenshots, screencasts etc.
![Screencast_from_2023-08-10_19-02-26](/uploads/0da8795e1282ddaf66da389dccd494f4/Screencast_from_2023-08-10_19-02-26.webm)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6784Workspace Indicator - When you switch to dynamic workspaces, should add a wor...2023-10-29T04:54:42ZStuart AxonWorkspace Indicator - When you switch to dynamic workspaces, should add a workspace if existing workspaces are fullIf you switch from fixed workspaces to dynamic workspaces, and all the current workspaces have windows in them, a new one should be added onto the end.
(Although this may be a bug in the settings app itself, not the extension)If you switch from fixed workspaces to dynamic workspaces, and all the current workspaces have windows in them, a new one should be added onto the end.
(Although this may be a bug in the settings app itself, not the extension)https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6567Desktop thumbnail in workspace panel has big corner squares2024-02-20T13:01:19ZMaxim Sokolovskysokolovskymaximorg@duck.comDesktop thumbnail in workspace panel has big corner squaresOpenSUSE Tumbleweed, Gnome 44, gnome-shell 44.0
I don't know how to describe it exactly, so I'll demonstrate it with a screenshot
![picture](/uploads/0f878891882a7cd38b01fa0611318874/Снимок_экрана_от_2023-03-30_19-39-30.png)
![picture...OpenSUSE Tumbleweed, Gnome 44, gnome-shell 44.0
I don't know how to describe it exactly, so I'll demonstrate it with a screenshot
![picture](/uploads/0f878891882a7cd38b01fa0611318874/Снимок_экрана_от_2023-03-30_19-39-30.png)
![picture](/uploads/18bd0d6561924b85bffd9bca04b904fb/Снимок_экрана_от_2023-03-30_19-44-50.png)https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6446In the Overview, swiping down with three fingers and swiping up in the middle...2023-11-21T22:04:58ZHari Ranatheevilskeleton@riseup.netIn the Overview, swiping down with three fingers and swiping up in the middle of the closing animation disables 1:1 scrolling so that it acts like a mouse scroll wheel<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS an...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Shell version (see https://wiki.gnome.org/Schedule for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
* Does this issue happen without extensions (please follow instructions below)
To properly disable extensions you can use gnome-extensions-app and then restart
your session. Disabling extensions without a restart is not sufficient to rule
out extensions as cause of a bug. If an issue can only be reproduced with a
certain extension, please file a bug report against that extension first.
-->
* Fedora 38 Silverblue Beta
* GNOME 43
* Wayland
* This bug can be reproduced without extensions.
### Bug summary
If you swipe down with three fingers in the Overview and swipe up in the middle of the closing animation, the 1:1 scrolling is disabled so that it behaves like a mouse scroll wheel.
### Steps to reproduce
1. Go to the Overview
2. Swipe down with 3 fingers and let go of your fingers
2. While the animation is still playing, swipe up with three fingers. If step 2 is too difficult, you can prevent the Overview from closing by holding with three fingers. Then, you can swipe up.
### What happened
<!--
What did GNOME Shell do that was unexpected?
-->
the 1:1 scrolling is disabled so that it behaves like a mouse scroll wheel.
### What did you expect to happen
<!--
What did you expect GNOME Shell to do?
-->
Restore the 1:1 scrolling behavior.
### Relevant logs, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Shell and Mutter) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
<details><summary>Warning: flashy video</summary>
![2023-02-27_21-51-05](/uploads/42d598ce7d75f986c407d9c6381dde80/2023-02-27_21-51-05.mp4)
</details>
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6072Captured Windows freeze when on another workspace2023-11-04T03:18:45ZZhafran Rama AzmiCaptured Windows freeze when on another workspace<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
gnome-shell : 43.1\
Distro : Arch rolling\
Pipewire : 0.3.59\
...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
gnome-shell : 43.1\
Distro : Arch rolling\
Pipewire : 0.3.59\
Display Server : Wayland
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Shell version (see https://wiki.gnome.org/Schedule for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
-->
### Bug summary
Captured window freezes when on another workspace that doesn't contain the captured window, starts playing again when I move to the workspace that contains the window being captured, or when in overview.
<!--
Provide a short summary of the bug you encountered.
-->
### Steps to reproduce
1. Start capturing a window from an app like OBS Studio
2. Move to a workspace that doesn't contain window and bring OBS Studio with you to inspect
3. see that captured window on OBS Studio has freezed
<!--
1. Step one
2. Step two
3. ...
-->
### What happened
Captured window on other workspace freezing
<!--
What did GNOME Shell do that was unexpected?
-->
### What did you expect to happen
For captured window to always play
<!--
What did you expect GNOME Shell to do?
-->
### Relevant logs, screenshots, screencasts etc.
![gnome-window-capture](/uploads/2564e4ecc2f1d03e2ecbbd9df9879a02/gnome-window-capture.mp4)
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Shell and Mutter) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6023Freeze when using keyboard shortcut to switch desktop workspace with dynamic ...2023-11-09T10:25:45ZRoy WoodFreeze when using keyboard shortcut to switch desktop workspace with dynamic workspaces and multiple monitors on Wayland<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* GNOME 43 on Ubuntu 22.10 + Wayland
* GNOME 44 on Wayland
##...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
* GNOME 43 on Ubuntu 22.10 + Wayland
* GNOME 44 on Wayland
### Bug summary
When I have an external monitor attached to my laptop and I use keyboard shortcuts (meta + pg up/down) to change desktops/workspaces, Gnome will occasionally freeze. It seems that the release of the meta key is not detected by the shell. When Gnome is frozen, if I tap the meta key, the press is detected, and a normal Activities mode starts, and I can end it cleanly.
If I use meta+tab to switch applications, or use meta alone to start the Activities mode, things are fine.
If I do not have an external monitor attached, meta + pg up/down works perfectly.
### Steps to reproduce
1. Connect an external monitor to my laptop
2. Open applications on multiple desktop/workspaces
3. Press `meta + pg up/down` (or `Ctrl+Alt + Left/Right`) to switch desktop/workspaces
4. Eventually GNOME shell freezes
### What happened
Gnome shell froze, and I had to start tapping `meta` to unfreeze
### What did you expect to happen
I expected the desktop/workspace to change as I moved through them using the keyboard shortcut.
### Relevant logs, screenshots, screencasts etc.
No additional info at this time.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5986App grid: Reduce spacing between workspaces2023-10-29T04:54:42ZTobias BernardApp grid: Reduce spacing between workspacesWorkspaces in the app grid are too far apart, making them look a bit unbalanced. Spacing is about twice what I think would look natural. The spacing seems to be dynamic, I wonder if it'd be better to go with a fixed spacing of e.g. 3 or ...Workspaces in the app grid are too far apart, making them look a bit unbalanced. Spacing is about twice what I think would look natural. The spacing seems to be dynamic, I wonder if it'd be better to go with a fixed spacing of e.g. 3 or 6px instead, similar to the workspaces minimap in the overview.
![image](/uploads/e563a088461f04de8ae744292bc5bfb2/image.png)
![image](/uploads/c626b2675571fb3ccfdca51a1b3a75b6/image.png)
cc @verdrehttps://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5596JS ERROR: TypeError: workspace is undefined and multiple stack traces2023-12-03T05:43:24ZMalcolm LewisJS ERROR: TypeError: workspace is undefined and multiple stack traces### Affected version
- gnome-shell 42.2-1.1
- openSUSE Tumbleweed 20220619
- Running wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.2
- Multiple Monitors
- Primary GPU: AMD RX550 amdgpu driver
- Secondary/Offload GPU: Quadro T...### Affected version
- gnome-shell 42.2-1.1
- openSUSE Tumbleweed 20220619
- Running wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.2
- Multiple Monitors
- Primary GPU: AMD RX550 amdgpu driver
- Secondary/Offload GPU: Quadro T400 Mobile 515.48.07 Dual MIT/GPLm license
### Bug summary
When switching workspaces via super key or activities and selecting any running application in the workspace moved to produces multiple stace trace journal entries.
### Steps to reproduce
1. Open gnome-terminal, switch to root user and run `journalctl -f` to monitor logs.
2. Open an application on Workspace 1.
3. Switch to Workspace 2 and open an application.
4. Either via supper key or activities overview switch back to Workspace 1.
5. Select application in Workspace 1.
6. Observe journalctl output.
### What happened
Logging multiple stack trace errors in the journal
### What did you expect to happen
Not produce stack traces (?).
### Relevant logs, screenshots, screencasts etc.
System information
```
inxi -SGxxz
System:
Kernel: 5.18.4-1-default arch: x86_64 bits: 64 compiler: gcc v: 12.1.0
Desktop: GNOME v: 42.2 tk: GTK v: 3.24.34 wm: gnome-shell dm: GDM
Distro: openSUSE Tumbleweed 20220619
Graphics:
Device-1: AMD Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]
driver: amdgpu v: kernel arch: GCN 4 pcie: speed: 8 GT/s lanes: 8 ports:
active: HDMI-A-2,HDMI-A-3,HDMI-A-4 off: HDMI-A-1 empty: none
bus-ID: 02:00.0 chip-ID: 1002:699f
Device-2: NVIDIA TU117GLM [Quadro T400 Mobile] driver: nvidia
v: 515.48.07 arch: Turing pcie: speed: 2.5 GT/s lanes: 16 ports:
active: none empty: DP-1,DP-2,DP-3 bus-ID: 03:00.0 chip-ID: 10de:1fb2
Display: wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.2
compositor: gnome-shell driver: X: loaded: amdgpu,nvidia
unloaded: fbdev,modesetting,vesa alternate: nouveau,nv gpu: amdgpu
display-ID: 0
Monitor-1: HDMI-A-1 model-id: AGO 0x0001 res: 1024x768 dpi: 87
diag: 378mm (14.9")
Monitor-2: HDMI-A-2 model: Sceptre E24 res: 1920x1080 dpi: 92
diag: 604mm (23.8")
Monitor-3: HDMI-A-3 model: Sceptre E24 res: 1920x1080 dpi: 92
diag: 604mm (23.8")
Monitor-4: HDMI-A-4 model: Sceptre E24 res: 1920x1080 dpi: 92
diag: 604mm (23.8")
OpenGL: renderer: AMD Radeon RX 550 / 550 Series (polaris12 LLVM 14.0.4
DRM 3.46 5.18.4-1-default)
v: 4.6 Mesa 22.1.1 direct render: Yes
```
Journalctl output observed;
```
Jun 21 08:18:29 grover gnome-shell[17852]: Object .Gjs_ui_workspaceThumbnail_ThumbnailsBox (0x5582d4476ce0), has been already disposed — impossible to get any property from it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Jun 21 08:18:29 grover gnome-shell[17852]: == Stack trace for context 0x5582cbe7ffa0 ==
Jun 21 08:18:29 grover gnome-shell[17852]: #0 7ffe92af8920 b resource:///org/gnome/shell/ui/workspacesView.js:639 (2d4bf0e5b3d0 @ 33)
Jun 21 08:18:29 grover gnome-shell[17852]: #1 7ffe92af8a70 b resource:///org/gnome/shell/ui/workspacesView.js:686 (2d4bf0e5b470 @ 488)
Jun 21 08:18:29 grover gnome-shell[17852]: #2 5582d126f9e0 i resource:///org/gnome/shell/ui/workspace.js:855 (2d4bf0e046f0 @ 370)
Jun 21 08:18:29 grover gnome-shell[17852]: #3 5582d126f958 i resource:///org/gnome/shell/ui/workspace.js:806 (2d4bf0e04650 @ 17)
Jun 21 08:18:29 grover gnome-shell[17852]: #4 5582d126f8c0 i resource:///org/gnome/shell/ui/workspacesView.js:1016 (2d4bf0e5be70 @ 124)
Jun 21 08:18:29 grover gnome-shell[17852]: #5 5582d126f830 i resource:///org/gnome/shell/ui/overviewControls.js:703 (22f1978bb420 @ 39)
Jun 21 08:18:29 grover gnome-shell[17852]: #6 5582d126f7a8 i resource:///org/gnome/shell/ui/layout.js:339 (334cdd230290 @ 22)
Jun 21 08:18:29 grover gnome-shell[17852]: #7 5582d126f718 i resource:///org/gnome/shell/ui/overview.js:586 (22f1978b8330 @ 170)
Jun 21 08:18:29 grover gnome-shell[17852]: #8 5582d126f698 i resource:///org/gnome/shell/ui/overview.js:564 (22f1978b82e0 @ 12)
Jun 21 08:18:29 grover gnome-shell[17852]: #9 5582d126f618 i resource:///org/gnome/shell/ui/overviewControls.js:741 (22f1978bb560 @ 55)
Jun 21 08:18:29 grover gnome-shell[17852]: #10 7ffe92aff990 b resource:///org/gnome/shell/ui/environment.js:151 (334cdd2cc4c0 @ 39)
Jun 21 08:18:29 grover gnome-shell[17852]: #11 7ffe92affa50 b resource:///org/gnome/shell/ui/environment.js:317 (334cdd2cc9c0 @ 14)
Jun 21 08:18:29 grover gnome-shell[17852]: == Stack trace for context 0x5582cbe7ffa0 ==
Jun 21 08:18:29 grover gnome-shell[17852]: #0 7ffe92af8920 b resource:///org/gnome/shell/ui/workspacesView.js:644 (2d4bf0e5b3d0 @ 358)
Jun 21 08:18:29 grover gnome-shell[17852]: #1 7ffe92af8a70 b resource:///org/gnome/shell/ui/workspacesView.js:686 (2d4bf0e5b470 @ 488)
Jun 21 08:18:29 grover gnome-shell[17852]: #2 5582d126f9e0 i resource:///org/gnome/shell/ui/workspace.js:855 (2d4bf0e046f0 @ 370)
Jun 21 08:18:29 grover gnome-shell[17852]: #3 5582d126f958 i resource:///org/gnome/shell/ui/workspace.js:806 (2d4bf0e04650 @ 17)
Jun 21 08:18:29 grover gnome-shell[17852]: #4 5582d126f8c0 i resource:///org/gnome/shell/ui/workspacesView.js:1016 (2d4bf0e5be70 @ 124)
Jun 21 08:18:29 grover gnome-shell[17852]: #5 5582d126f830 i resource:///org/gnome/shell/ui/overviewControls.js:703 (22f1978bb420 @ 39)
Jun 21 08:18:29 grover gnome-shell[17852]: #6 5582d126f7a8 i resource:///org/gnome/shell/ui/layout.js:339 (334cdd230290 @ 22)
Jun 21 08:18:29 grover gnome-shell[17852]: #7 5582d126f718 i resource:///org/gnome/shell/ui/overview.js:586 (22f1978b8330 @ 170)
Jun 21 08:18:29 grover gnome-shell[17852]: #8 5582d126f698 i resource:///org/gnome/shell/ui/overview.js:564 (22f1978b82e0 @ 12)
Jun 21 08:18:29 grover gnome-shell[17852]: Object .Gjs_ui_workspaceThumbnail_ThumbnailsBox (0x5582d4476ce0), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Jun 21 08:18:29 grover gnome-shell[17852]: #9 5582d126f618 i resource:///org/gnome/shell/ui/overviewControls.js:741 (22f1978bb560 @ 55)
Jun 21 08:18:29 grover gnome-shell[17852]: #10 7ffe92aff990 b resource:///org/gnome/shell/ui/environment.js:151 (334cdd2cc4c0 @ 39)
Jun 21 08:18:29 grover gnome-shell[17852]: #11 7ffe92affa50 b resource:///org/gnome/shell/ui/environment.js:317 (334cdd2cc9c0 @ 14)
Jun 21 08:18:29 grover gnome-shell[17852]: == Stack trace for context 0x5582cbe7ffa0 ==
Jun 21 08:18:29 grover gnome-shell[17852]: #0 7ffe92af8a70 b resource:///org/gnome/shell/ui/workspacesView.js:688 (2d4bf0e5b470 @ 505)
Jun 21 08:18:29 grover gnome-shell[17852]: #1 5582d126f9e0 i resource:///org/gnome/shell/ui/workspace.js:855 (2d4bf0e046f0 @ 370)
Jun 21 08:18:29 grover gnome-shell[17852]: #2 5582d126f958 i resource:///org/gnome/shell/ui/workspace.js:806 (2d4bf0e04650 @ 17)
Jun 21 08:18:29 grover gnome-shell[17852]: #3 5582d126f8c0 i resource:///org/gnome/shell/ui/workspacesView.js:1016 (2d4bf0e5be70 @ 124)
Jun 21 08:18:29 grover gnome-shell[17852]: #4 5582d126f830 i resource:///org/gnome/shell/ui/overviewControls.js:703 (22f1978bb420 @ 39)
Jun 21 08:18:29 grover gnome-shell[17852]: #5 5582d126f7a8 i resource:///org/gnome/shell/ui/layout.js:339 (334cdd230290 @ 22)
Jun 21 08:18:29 grover gnome-shell[17852]: #6 5582d126f718 i resource:///org/gnome/shell/ui/overview.js:586 (22f1978b8330 @ 170)
Jun 21 08:18:29 grover gnome-shell[17852]: #7 5582d126f698 i resource:///org/gnome/shell/ui/overview.js:564 (22f1978b82e0 @ 12)
Jun 21 08:18:29 grover gnome-shell[17852]: #8 5582d126f618 i resource:///org/gnome/shell/ui/overviewControls.js:741 (22f1978bb560 @ 55)
Jun 21 08:18:29 grover gnome-shell[17852]: #9 7ffe92aff990 b resource:///org/gnome/shell/ui/environment.js:151 (334cdd2cc4c0 @ 39)
Jun 21 08:18:29 grover gnome-shell[17852]: #10 7ffe92affa50 b resource:///org/gnome/shell/ui/environment.js:317 (334cdd2cc9c0 @ 14)
Jun 21 08:18:29 grover gnome-shell[17852]: == Stack trace for context 0x5582cbe7ffa0 ==
Jun 21 08:18:29 grover gnome-shell[17852]: #0 7ffe92af8a70 b resource:///org/gnome/shell/ui/workspacesView.js:692 (2d4bf0e5b470 @ 612)
Jun 21 08:18:29 grover gnome-shell[17852]: #1 5582d126f9e0 i resource:///org/gnome/shell/ui/workspace.js:855 (2d4bf0e046f0 @ 370)
Jun 21 08:18:29 grover gnome-shell[17852]: #2 5582d126f958 i resource:///org/gnome/shell/ui/workspace.js:806 (2d4bf0e04650 @ 17)
Jun 21 08:18:29 grover gnome-shell[17852]: #3 5582d126f8c0 i resource:///org/gnome/shell/ui/workspacesView.js:1016 (2d4bf0e5be70 @ 124)
Jun 21 08:18:29 grover gnome-shell[17852]: #4 5582d126f830 i resource:///org/gnome/shell/ui/overviewControls.js:703 (22f1978bb420 @ 39)
Jun 21 08:18:29 grover gnome-shell[17852]: #5 5582d126f7a8 i resource:///org/gnome/shell/ui/layout.js:339 (334cdd230290 @ 22)
Jun 21 08:18:29 grover gnome-shell[17852]: #6 5582d126f718 i resource:///org/gnome/shell/ui/overview.js:586 (22f1978b8330 @ 170)
Jun 21 08:18:29 grover gnome-shell[17852]: Object .Gjs_ui_workspaceThumbnail_ThumbnailsBox (0x5582d4476ce0), has been already disposed — impossible to get any property from it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Jun 21 08:18:29 grover gnome-shell[17852]: #7 5582d126f698 i resource:///org/gnome/shell/ui/overview.js:564 (22f1978b82e0 @ 12)
Jun 21 08:18:29 grover gnome-shell[17852]: #8 5582d126f618 i resource:///org/gnome/shell/ui/overviewControls.js:741 (22f1978bb560 @ 55)
Jun 21 08:18:29 grover gnome-shell[17852]: #9 7ffe92aff990 b resource:///org/gnome/shell/ui/environment.js:151 (334cdd2cc4c0 @ 39)
Jun 21 08:18:29 grover gnome-shell[17852]: #10 7ffe92affa50 b resource:///org/gnome/shell/ui/environment.js:317 (334cdd2cc9c0 @ 14)
Jun 21 08:18:29 grover gnome-shell[17852]: Object .Gjs_ui_workspaceThumbnail_ThumbnailsBox (0x5582d4476ce0), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Jun 21 08:18:29 grover gnome-shell[17852]: Spurious clutter_actor_allocate called for actor 0x5582d4476ce0/<unnamed>[<Gjs_ui_workspaceThumbnail_ThumbnailsBox>:0x5582d4476ce0] which isn't a descendent of the stage!
Jun 21 08:18:29 grover gnome-shell[17852]: JS ERROR: TypeError: workspace is undefined
_getSpacing@resource:///org/gnome/shell/ui/workspacesView.js:213:13
vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:339:18
vfunc_allocate@resource:///org/gnome/shell/ui/workspacesView.js:711:30
removeWindow@resource:///org/gnome/shell/ui/workspace.js:855:29
addWindow/<.destroyId<@resource:///org/gnome/shell/ui/workspace.js:806:22
vfunc_hide@resource:///org/gnome/shell/ui/workspacesView.js:1016:38
vfunc_unmap@resource:///org/gnome/shell/ui/overviewControls.js:703:33
hideOverview@resource:///org/gnome/shell/ui/layout.js:339:28
_hideDone@resource:///org/gnome/shell/ui/overview.js:586:32
_animateNotVisible/<@resource:///org/gnome/shell/ui/overview.js:564:55
onStopped@resource:///org/gnome/shell/ui/overviewControls.js:741:21
_makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:151:22
_easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:317:60
Jun 21 08:18:29 grover gnome-shell[17852]: Object St.Button (0x5582cd8c8460), has been already disposed — impossible to get any property from it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Jun 21 08:18:29 grover gnome-shell[17852]: == Stack trace for context 0x5582cbe7ffa0 ==
Jun 21 08:18:29 grover gnome-shell[17852]: #0 7ffe92affbb0 b resource:///org/gnome/shell/ui/windowPreview.js:566 (2d4bf0e09830 @ 10)
Jun 21 08:18:29 grover gnome-shell[17852]: == Stack trace for context 0x5582cbe7ffa0 ==
Jun 21 08:18:29 grover gnome-shell[17852]: #0 7ffe92affbb0 b resource:///org/gnome/shell/ui/windowPreview.js:567 (2d4bf0e09830 @ 36)
Jun 21 08:18:29 grover gnome-shell[17852]: == Stack trace for context 0x5582cbe7ffa0 ==
Jun 21 08:18:29 grover gnome-shell[17852]: #0 7ffe92affbb0 b resource:///org/gnome/shell/ui/windowPreview.js:570 (2d4bf0e09830 @ 77)
Jun 21 08:18:29 grover gnome-shell[17852]: Object St.Label (0x5582d36dca80), has been already disposed — impossible to get any property from it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
Jun 21 08:18:29 grover gnome-shell[17852]: Object .Gjs_ui_windowPreview_WindowPreview (0x5582cff68820), has been already disposed — impossible to get any property from it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
```
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5413After some time all programs from different workspaces end up on the first wo...2023-10-29T04:54:42ZAndrew KingAfter some time all programs from different workspaces end up on the first workspace### Affected version
* Ubuntu 22.04 LTS
* GNOME 42.0 version
* Wayland
### Bug summary
After some time all programs from different workspaces end up on the first workspace.
Under Settings > Multitasking I have default "Dynamic workspa...### Affected version
* Ubuntu 22.04 LTS
* GNOME 42.0 version
* Wayland
### Bug summary
After some time all programs from different workspaces end up on the first workspace.
Under Settings > Multitasking I have default "Dynamic workspaces".
### Steps to reproduce
The bug repeats periodically if you lock the screen and return after a while (sometimes 2-3 minutes is enough, sometimes more time is needed), it also repeats if you work on another monitor, and returning to the main one - all programs on the first workspace.
### What happened
What did GNOME Shell do that was unexpected?
After some time all programs from different workspaces end up on the first workspace
### What did you expect to happen
So that programs from different workspaces remain in their workspaces, and do not merge everything into the first workspace.
### Update
Settings > Multitasking changed to "Fixed number of workspaces" with value 4.
Bug repeated.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5353gnome-shell 42 dynamic workspaces behave in a weird fashion2023-10-29T04:54:42ZRalf Oltmannsgnome-shell 42 dynamic workspaces behave in a weird fashion### Affected version
gnome-shell 1:42.0-1
gnome-tweaks 42beta+r9+gc66d8c3-1
ArchLinux 5.17.3-arch1-1 #1 SMP PREEMPT Thu, 14 Apr 2022 01:18:36 +0000 x86_64 GNU/Linux
Session Type = XOrg (x11)
### Bug summary
Up until the most current up...### Affected version
gnome-shell 1:42.0-1
gnome-tweaks 42beta+r9+gc66d8c3-1
ArchLinux 5.17.3-arch1-1 #1 SMP PREEMPT Thu, 14 Apr 2022 01:18:36 +0000 x86_64 GNU/Linux
Session Type = XOrg (x11)
### Bug summary
Up until the most current update, Gnome was set to "dynamic workspaces". There also was a "workspaces" section in gnome-tweaks to switch between a static number of workspaces and dynamic workspaces with is now missing.
Now, I'm stuck with exactly two workspaces and can't switch the mode nor can add further workspaces.
### Steps to reproduce
Log in to Gnome. Try to move a window to a workspace to the right beyond workspace #2, which fails/does nothing.
### What happened
Gnome shell does not allow a window to be moved right beyond workspace #2 and does not dynamically create a new workspace.
### What did you expect to happen
Setting focus on a window and then i. e. pressing Shift+Ctrl+Alt+cursor right, I should still be able to move the window in question to a new workspace to the right.
### Relevant logs, screenshots, screencasts etc.
What I just now realized is, that (for whatever reason I cannot imagine yet) I could move a new window to a new workspace ON THE LEFT, which now moves my "main workspace" to position #2. I now can create as many new workspaces TO THE LEFT, but not, as was true for a very long time, TO THE RIGHT. Is this the behaviour you intended? If yes, please explain why, because I can't think of an apparently good reason for a change like this.
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5204Opening overview before 3 finger swipe animation finishes causes workspace sw...2023-11-21T21:38:42ZdolwupOpening overview before 3 finger swipe animation finishes causes workspace switch to get canceled<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Arch Linux
gnome-shell 42.rc.0
Wayland
### Bug summary
...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
Arch Linux
gnome-shell 42.rc.0
Wayland
### Bug summary
When switching workspaces with a 3 finger swipe, opening the overview with a 3 finger swipe up or through pushing the super key causes the switching action to get cancled and instead opens the overview on the previous workspace.
### Steps to reproduce
1. Open one window
2. Do a 3 finger swipe to switch to another workspace
3. Quickly open overview before the animation finishes
### What happened
The overview opens on the previous workspace
### What did you expect to happen
The overview opens on the workspace I tried to switch to
### Relevant logs, screenshots, screencasts etc.
![workspace_swipe_bug](/uploads/6f6b34435bdea899761dcf1f5dd287a1/workspace_swipe_bug.mp4)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4965Switching workspaces is stuck if Meta key is released before two finger swipe...2023-04-27T19:50:16ZLomapurSwitching workspaces is stuck if Meta key is released before two finger swipe is finished.<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS an...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Shell version (see https://wiki.gnome.org/Schedule for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
-->
OS: Fedora Workstation 35
Gnome Shell version: 41.3
Wayland
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
When using Meta + two finger swipe gesture to change workspaces the changing of workspaces is stuck in position if Meta is released before swipe is finished (fingers off the touchpad).
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1. Press Meta.
1.a While holding Meta start two-finger swipe left or right to change workspaces.
2. Release the Meta key before swipe is finished (taking fingers off the touchpad)
### What happened
<!--
What did GNOME Shell do that was unexpected?
-->
Workspace switcher is stuck between two workspaces.
### What did you expect to happen
<!--
What did you expect GNOME Shell to do?
-->
Workspace switch should be finished (either previous or next workspace should be switched to); basically the same behaviour that happens when two-fingers swipe is finished before Meta key is released.
### Relevant logs, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Shell and Mutter) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
![workspace_switcher_stuck](/uploads/b0380e584863995f87ee3053be60b5e1/workspace_switcher_stuck.webm)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4935Switch workspace while dragging window thumbnail in overview2023-10-18T19:45:49ZExposedCatSwitch workspace while dragging window thumbnail in overview<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
Add ability to switch between workspaces while dragging a wind...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Feature summary
Add ability to switch between workspaces while dragging a window thumbnail in overview
### How would you like it to work
1. Open any window
2. Open overview
3. Press and hold window thumbnail
4. One or more option:
4.1. Using keyboard shortcut, mouse scroll, touchpad gesture or multitouch gesture to switch between workspaces
4.2. Hovering on workspace switcher for a second (small thumbnail of whole workspace) with window opens workspace
4.3. Moving app to screen edge and waiting a second opens next/previous workspace
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4793Secondary windows get put behind when switching from the very last workspace ...2023-11-21T22:02:37ZHari Ranatheevilskeleton@riseup.netSecondary windows get put behind when switching from the very last workspace to its previous workspace<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS an...<!--
Please read https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines
first to ensure that you create a clear and specific issue.
-->
### Affected version
<!--
Provide at least the following information:
* Your OS and version
* Affected GNOME Shell version (see https://wiki.gnome.org/Schedule for currently supported versions)
* Does this issue appear in XOrg and/or Wayland
-->
- OS: Fedora Silverblue 35
- GNOME Shell version: GNOME Shell 41.1
- Only reproducible on Wayland (untested on Xorg)
- Works when no extensions are used
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
Having three windows in one workspace and switching from the last workspace to its previous workspace causes and issue where the second window gets put behind, by either swiping with three fingers or using the Super+Pg{Up,Dn} shortcut.
### Steps to reproduce
1. Place three different windows in the last workspace. This will create a new workspace.
2. Simply between previous and next workspaces.
### What happened
<!--
What did GNOME Shell do that was unexpected?
-->
The second window gets put behind the third window.
### What did you expect to happen
<!--
What did you expect GNOME Shell to do?
-->
The second window is supposed to remain as the second window.
### Relevant logs, screenshots, screencasts etc.
<!--
If you have further information, such as technical documentation, logs,
screenshots or screencasts related, please provide them here.
If the bug is a crash, please obtain a stack trace with installed debug
symbols (at least for GNOME Shell and Mutter) and attach it to
this issue following the instructions on
https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces.
-->
![2021-11-14_22-59-55](/uploads/3a6bbfa32407f22716a9fc72896f596b/2021-11-14_22-59-55.mp4)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4767Workspace previews are a very small drop target in portrait mode2021-11-09T09:52:55ZAlexandre FrankeWorkspace previews are a very small drop target in portrait modeIn the same context as #4765, once there is more than one workspace, the previews are displayed at the top. Because the previews are so narrow, it is extremely difficult to drag a window to the desired location, be it an existing workspa...In the same context as #4765, once there is more than one workspace, the previews are displayed at the top. Because the previews are so narrow, it is extremely difficult to drag a window to the desired location, be it an existing workspace or a new one between two existing ones. A simple lateral move to adjust the drop location often results in big jumps and one has to be very careful and slow to find the right spot.
Here is an example at different speed, but never really fast, to show the behaviour and the required precision in the current setting.
![screencast-narrow-workspace-previews](/uploads/1755a6e7b2036fe76548e8c982c2b5fc/screencast-narrow-workspace-previews.webm)
With plenty of available real estate, the previews could be made larger on taller monitors. Even with a narrow monitor (1050px wide) I can currently fit 18 workspaces up there, so I really wouldn’t mind if I had to trade a lower amount of them for increased individual width.