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/7344Inconsistent desktop and preview feed animations2024-02-02T00:34:23Zberezki plakaliInconsistent desktop and preview feed animations### Feature summary
There are three main screen states in GNOME:
1. Usual (only the current desktop visible)
2. Activities (desktop feed and desktop preview feed visible)
3. Applications (applications and desktop preview feed visible)
...### Feature summary
There are three main screen states in GNOME:
1. Usual (only the current desktop visible)
2. Activities (desktop feed and desktop preview feed visible)
3. Applications (applications and desktop preview feed visible)
When opening Activities state current desktop becomes part of the desktop feed and preview feed appears. That's totally ok. But then in the Applications state suddenly the desktop feed becomes the preview feed, and the preview feed disappears. That seems illogical.
At the same time, due to this inconsistency, another problem appears: although due to the animation it seems that the desktop feed replaces the preview feed in the Applications, this is not true. Actually this **IS** the preview feed (the one from the Activities), this can be noticed by the disappearing nice layout of windows of the desktops (which is the feature of the desktop feed, when all the windows are arranged in a grid like on a showcase).
And current desktop from Usual state is already part of the desktop feed, and it turns out three functions are hung on one entity at once.
By the way noticed desktop previews in application menu don't have rounded corners but in activities they do.
### How would you like it to work
When switching from the Activities to the Applications, the desktop feed should be overlapped by applications, and the preview feed should become larger. The final appearance and usability of the states will not change, but there will be a clear distinction between these two feeds.
### Relevant links, screenshots, screencasts etc.
On these screenshots I've marked entities with colors (parts of desktop feed as green and preview feed as red) according with GNOME animations. I'm trying to say there should be the red one in Applications menu.
![Usual_desktop](/uploads/351eac61d46f37802c0643644a4f96e7/Usual_desktop.png)
_Usual state_
![Activities](/uploads/b861c1209b3a15824f06a77d61be2d3f/Activities.png)
_Activities state_
![Applications](/uploads/c0bd7180ee8e748d1f28bbd9c5695774/Applications.png)
_Applications state_https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7294Terminal resizes by one row whenever overview key is pressed2024-01-10T23:02:50ZJamesTerminal resizes by one row whenever overview key is pressed```
$ uname -a
Linux computer 6.6.4-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC
Sun Dec 3 18:11:27 UTC 2023 x86_64 GNU/Linux
$ cat /etc/redhat-release
Fedora release 38 (Thirty Eight)
```
Title says it all. It happens about once a week or...```
$ uname -a
Linux computer 6.6.4-100.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC
Sun Dec 3 18:11:27 UTC 2023 x86_64 GNU/Linux
$ cat /etc/redhat-release
Fedora release 38 (Thirty Eight)
```
Title says it all. It happens about once a week or so. Not sure what causes it. Video attached or you probably wouldn't believe me. I couldn't get gnome screen recording working, so I apologize for the shaky video.
![gnome-shell-terminal-resize](/uploads/35cdc24a068da1faac80c498f9e45a55/gnome-shell-terminal-resize.mp4)
Cheers!https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/7168When opening the overview, all icons create shadow pipelines, which adds up t...2023-11-27T17:21:26ZIvan Molodetskikhyalterz@gmail.comWhen opening the overview, all icons create shadow pipelines, which adds up to lag / slowdowns over time<!--
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 39 Silverblue, Wayland, gnome-shell 45.1 + !3001 + !3004
### Bug summary
<!--
Provide a short summary of the bug you encountered.
-->
Every time when opening the overview, all `StIcon`s generate shadow pipelines in their `paint()`. This takes ~1.5 ms per icon. Also, identical icons all generate shadow pipelines individually, rather than sharing.
This is one of the main contributors to the first frame of opening the overview taking a while to process, especially with many windows open.
Here's a Tracy profile of an overview opening frame:
![image](/uploads/094a3bdabd1c7a214edb285b0b76a819/image.png)
This issue is about the right part of this profile, the `paint`. Here's it zoomed-in:
![image](/uploads/9479e0b819100fc97f753d553a9d35cc/image.png)
As you can see, most of this time is taken up by the shadow pipeline generation. Dark stripes are blocking syscalls, in this case to allocate textures and such.
### Steps to reproduce
<!--
1. Step one
2. Step two
3. ...
-->
1. Open a lot of windows (bind a key to spawn a terminal, then hold it for a bit).
2. Open the overview.
### What happened
<!--
What did GNOME Shell do that was unexpected?
-->
The first frame takes a while, with enough windows skipping the animation entirely.
### What did you expect to happen
<!--
What did you expect GNOME Shell to do?
-->
The problem is not this severe.
### 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.
-->
<!-- Do not remove the following line. -->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/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/6725Search opens incorrect result when typing quickly2023-11-21T18:51:00ZChris TuckerSearch opens incorrect result when typing quickly
### Affected version
* GNOME Shell: 44.1
* Fedora Silverblue: 38.20230509.0
* Wayland
**I did not experience this bug when using Fedora Silverblue 36, which I believe was running GNOME 42.**
### Bug summary
When performing a search ...
### Affected version
* GNOME Shell: 44.1
* Fedora Silverblue: 38.20230509.0
* Wayland
**I did not experience this bug when using Fedora Silverblue 36, which I believe was running GNOME 42.**
### Bug summary
When performing a search by typing on the keyboard quickly, GNOME very often opens the incorrect search result.
For example, if I type "c", I get Celluloid appearing as the first/selcted search result. When I add "alc" to search for "calc", the search bar correctly shows "calc" as my search term, and the search results correctly show Calculator as the selected search result — but when I press the Enter key, Celluloid still opens!
Visually everything is shown correctly, but when actually pressing the Enter key opens the previously-shown result. It's like GNOME is delayed and acting on the older search results, which are not in sync with what is shown visually.
This is very easily reproducible for me, and happens often enough to be frustrating. I have to intentionally slow down when doing a search to make sure GNOME opens the right thing.
### Steps to reproduce
Either:
1. Open the Overview screen.
2. Type one letter of the search term and view the search results.
3. Quickly type the rest of the search term (to change the results) and press Enter.
Or:
1. Open the Overview screen.
2. Quickly type a search term and press Enter.
### What happened
GNOME opens the wrong program. The selected search result shown on-screen does not match the application that is opened.
### What did you expect to happen
I expected GNOME to open the result that was shown on-screen as selected. With Calculator shown as the selected search result, I expected Calculator to be opened, not Celluloid.
### Relevant logs, screenshots, screencasts etc.
![Screencast_from_2023-05-27_19-06-18__trimmed_](/uploads/1522d22c8809a06cf09a123a133f55d6/Screencast_from_2023-05-27_19-06-18__trimmed_.webm)
![Screencast_from_2023-05-27_19-07-28](/uploads/419251bc66435b103cb5106bfd4703ca/Screencast_from_2023-05-27_19-07-28.webm)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6600Gnome-Shell Activities Overview glitches: Firefox, Libre Office -> 'New Window'2023-05-31T13:38:56ZcooperbangGnome-Shell Activities Overview glitches: Firefox, Libre Office -> 'New Window'Hi,
i´ve experinced some GUI glitches when opening additional windows of Firefox and Libre Office (Writer, Calc, Impress) via Gnome Launcher.
Environment:
```
Fedora Linux 37
Gnome 43.4 (Wayland)
```
```
firefox-112.0-3.fc37.x86_64
l...Hi,
i´ve experinced some GUI glitches when opening additional windows of Firefox and Libre Office (Writer, Calc, Impress) via Gnome Launcher.
Environment:
```
Fedora Linux 37
Gnome 43.4 (Wayland)
```
```
firefox-112.0-3.fc37.x86_64
libreoffice-writer-7.4.6.2-2.fc37.x86_64
libreoffice-calc-7.4.6.2-2.fc37.x86_64
libreoffice-impress-7.4.6.2-2.fc37.x86_64
gnome-shell-43.4-1.fc37.x86_64
```
Steps to reproduce:
1. Open Firefox or Libre Office by clicking on Firefox or Libre Office icon in Gnome Launcher.
2. Open a further Firefox or Libre Office window by right-clicking on Firefox icon in Gnome Launcher and selecting 'New Window' (Firefox) or 'New Document' (Libre Office).
Actual results:
1. A spinning mouse cursor appears for about 15 seconds in Gnome Activities overview (Firefox and Libre Office)
2. Preview of Firefox window in Gnome Activities overview is blank.
Expected results:
1. Firefox and Libre Office windows should open immediately without showing spinning mouse cursor for about 15 seconds.
2. Preview of Firefox in Gnome Activities overview should show thumbnail of currently opened Firefox website (e.g. about:blank or google.com) instead of appearing blank.
![Bildschirmfoto_vom_2023-04-14_13-56-56](/uploads/8505e4db67a1ff7d8c50d06b1be2fa17/Bildschirmfoto_vom_2023-04-14_13-56-56.png)https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6563Icon grid changes size mid-animation2023-10-09T19:46:21ZDaniel van Vugtdaniel.van.vugt@canonical.comIcon grid changes size mid-animationGNOME 44.0:
![Screencast_from_2023-03-30_14-43-14](/uploads/14d11dc7b8a45c65530b20d0cd53500a/Screencast_from_2023-03-30_14-43-14.webm)GNOME 44.0:
![Screencast_from_2023-03-30_14-43-14](/uploads/14d11dc7b8a45c65530b20d0cd53500a/Screencast_from_2023-03-30_14-43-14.webm)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/5745Issue when selecting options from dock menus using long press2023-08-24T23:11:22ZMichael FIssue when selecting options from dock menus using long press### Affected version
GNOME 42.3 on Fedora 36, also present on Fedora 35
EDIT: as of 17/08/2022 the issue is present in the newest version of GNOME available with Fedora Rawhide.
### Bug summary
After using long-press to select an option ...### Affected version
GNOME 42.3 on Fedora 36, also present on Fedora 35
EDIT: as of 17/08/2022 the issue is present in the newest version of GNOME available with Fedora Rawhide.
### Bug summary
After using long-press to select an option from a menu, gnome-shell appears to interpret it as an in-progress drag operation when entering the overview successive times.
### Steps to reproduce
1. Go to overview.
2. Long press (hold left click) on an application and, without releasing the mouse, move it over an option that will cause it to open (such as "New Window").
3. Release. The overview will exit, and the application will open.
4. Open the overview again, and mouse over the application, without clicking. At least in my case, it will act as though you are dragging the application icon without ever having done so.
### What happened
It treats it like you're dragging the application, even though you're not pressing any buttons on the mouse.
### What did you expect to happen
Overview opens as usual.
### Relevant logs, screenshots, screencasts etc.
See this reddit post.
https://www.reddit.com/r/gnome/comments/wjf1av/possible_bug_when_selecting_options_from_dock/
Here is a copy of the screencast. Sorry if it's not clear from the video; I was unable to get OBS to display click events.
[2022-08-08_10-32-16.mkv](/uploads/f9d8886001163b6779bfb61f3d456304/2022-08-08_10-32-16.mkv)https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5631Thumbnails in window picker sometimes unnecessarily small2023-05-20T09:29:12ZJohnThumbnails in window picker sometimes unnecessarily smallRelated to #5001, may be fixed by changes in #3634
In certain cases, the thumbnails in the window picker are very small even though there is plenty of free space, making it unnecessarily hard to distinguish between windows. In the scre...Related to #5001, may be fixed by changes in #3634
In certain cases, the thumbnails in the window picker are very small even though there is plenty of free space, making it unnecessarily hard to distinguish between windows. In the screenshot attached, I have one window (Extension Manager) open but small, 10 maximized Firefox windows, 2 Firefox windows that are long but very narrow, and one Firefox window that is relatively large but not maximized.
The window picker layout algorithm should more effectively make use of the space available.
I'm using Shell 42.2 and Fedora 36.
![Screenshot_from_2022-07-04_01-25-35](/uploads/7fd087ff4148560733220aa05dd430aa/Screenshot_from_2022-07-04_01-25-35.png)https://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/5316When in overview app grid mode window preview close buttons and labels are cl...2024-03-19T18:36:25ZCharles GagnonWhen in overview app grid mode window preview close buttons and labels are clipped on secondary monitor### Affected version
gnome-shell 42, X.Org
### Bug summary
On gnome-shell 42, when in overview app grid mode the window preview close button and labels are clipped on secondary monitors. It is fine for the same window preview when in ...### Affected version
gnome-shell 42, X.Org
### Bug summary
On gnome-shell 42, when in overview app grid mode the window preview close button and labels are clipped on secondary monitors. It is fine for the same window preview when in overview window picker mode.
### Steps to reproduce
Open some windows on a secondary monitor, go in the overview app grid
### Relevant logs, screenshots, screencasts etc.
Notice the top right close button (app grid mode)
![image](/uploads/be12a8bfd27fbe8276e733b5bef57f0a/image.png)
In window picker mode
![image](/uploads/87a7079c909b911d038ea8f24169abd8/image.png)
<!-- 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/5134Workspace Switch stutters left and right when using two actions at once2022-07-02T20:20:47ZClocksWorkspace Switch stutters left and right when using two actions at once### Affected version
- Fedora 35
- GNOME 41.3
### Bug summary
When using two actions, specifically super & 3 finger swipe, quickly one after another to change workspace, the workspace shakes left and right.
### Steps to reproduce
1. ...### Affected version
- Fedora 35
- GNOME 41.3
### Bug summary
When using two actions, specifically super & 3 finger swipe, quickly one after another to change workspace, the workspace shakes left and right.
### Steps to reproduce
1. Open overview with the super key
2. With one fluid motion. swipe 3 fingers from right to left and press the super key as your hand leaves the touch pad.
3. Notice the workspace shake back and forth.
This might need some trial and error to invoke.
### What happened
The workspace shakes left and right and then stabilizes. The amount of shaking does not seem to be consistent.
### What did you expect to happen
The workspace is swapped to neatly.
### Relevant logs, screenshots, screencasts etc.
[2022-02-23_14-09-38.mkv](/uploads/3a221a32f64ade7916324e3c587cbcda/2022-02-23_14-09-38.mkv)
<!-- Do not remove the following line. -->https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5070After logging in, the cursor doesn't move until the overview appears2023-11-22T05:59:08ZGhost UserAfter logging in, the cursor doesn't move until the overview appears## Problem
When logging in, the cursor doesn't move until the overview appears. I remember this didn't happen a while back and I could move the cursor normally.
## Affected scenarios
This can be confused with an system crash/freeze, e...## Problem
When logging in, the cursor doesn't move until the overview appears. I remember this didn't happen a while back and I could move the cursor normally.
## Affected scenarios
This can be confused with an system crash/freeze, especially if the machine is slow or if something is affecting the startup.
## Possible solutions
- Make the cursor movable;
- Instead of just making the cursor movable again, I think it should be changed to an animated cursor to better indicate that the shell is loading:
![Untitled](/uploads/60bccaea8fd33d28cfd8fcd79442b0b4/Untitled.png)
## Additional info
- GNOME 41.3 (Wayland)
- Fedora 35https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5036Add a fade in transition to the search box when entering Overview2023-11-21T18:55:42ZGhost UserAdd a fade in transition to the search box when entering OverviewCurrently, all of the hover elements have a fade in transition, except the search box.
![Kooha-02-08-2022-09-49-10](/uploads/1a0d72a20299b56544f4c48d96fbf99e/Kooha-02-08-2022-09-49-10.mp4)Currently, all of the hover elements have a fade in transition, except the search box.
![Kooha-02-08-2022-09-49-10](/uploads/1a0d72a20299b56544f4c48d96fbf99e/Kooha-02-08-2022-09-49-10.mp4)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/4914Highlight matching windows when hovering dash icons2022-01-08T16:32:18ZAllan DayHighlight matching windows when hovering dash iconsSince GNOME 40, I find myself using the running apps section of the dash to see, well, what's running. The next thing my brain asks me is - "which open windows belong to this app?" Currently this isn't easy - once you've seen that an app...Since GNOME 40, I find myself using the running apps section of the dash to see, well, what's running. The next thing my brain asks me is - "which open windows belong to this app?" Currently this isn't easy - once you've seen that an app is running, you still need to scan through all the open apps to see which windows it has.
The use case for this kind of behaviour is often cleaning up - closing some apps and windows either to free up resources or to tidy away the clutter.
Highlighting each of an app's windows when hovering over its icon in the dash would be really helpful here.
I also wonder whether there could be a way to quit apps from the dash, say with a close button on the top right of one, when it's being hovered.
@jimmac @bertob @snwh