Description of problem: Gnome-shell on Wayland freezes for several seconds (mouse stops moving etc.) when clicking on URLs on applications that launch them in Firefox. I think this is not necessarily specific to Firefox, but it may be associated with switching to a different window in cases where gnome-shell briefly displays a notification saying the "window is ready" (the notification however disappears almost immediately, when the window becomes focused). Version-Release number of selected component (if applicable): gnome-shell-3.28.1-3.fc28.x86_64 How reproducible: Not 100% of the time but can be triggered by trying several times, see below. Steps to Reproduce: 1. Start with user account on Fedora 28 with default config. 2. Open Firefox. 3. Open Evolution on a different workspace, write an email with URL link and save as draft. 4. Click on an URL link in the email in Evolution. 5. The desktop hangs momentarily (mouse etc. freezes) before switching to firefox. Alternatively, it can also triggered when opening URL links in gnome-terminal via the right-click menu. Starting on a new user account produces a freeze only sometimes, maybe 10% of the time, and mouse stops moving for a shorter time (< 1 sec) so the issue is not as easily noticeable. On my existing user account this however occurs more often, and the momentary freezing lasts longer --- also reproducible with gnome-shell extensions disabled. So far I haven't managed to find out what is the difference. Actual results: The window manager (and mouse cursor) freezes for several seconds before before switching windows. Expected results: I would expect the focus switches to firefox window with no freezing. Additional info: As noted in different bug reports, gnome-shell spams the logs with messages of the form May 05 18:10:49 localhost.localdomain gnome-shell[16354]: Object Clutter.Actor (0x56379043d710), has been already finalized. Impossible to get any property from it. May 05 18:10:49 localhost.localdomain org.gnome.Shell.desktop[16354]: == Stack trace for context 0x56378b971190 == ... However, the log spam also occurs all the time also when there is no freezing so I'm not sure it's related. I think the issue did not occur on Fedora 27.
I can reproduce this issue too. It is a clear regression from Fedora 27. See also bug #1565931. Can you confirm that this issue is not present when choosing Xorg instead of wayland?
Just tried, and clicking on URLs in Evolution seems to cause gnome-shell to freeze for a few seconds also on Xorg. The mouse cursor however doesn't freeze, but gnome-shell stops responding to key presses for a few seconds. I also note that I see somewhat similar freezes on Gnome/Wayland on a different Ubuntu 18.04 machine.
This issue may be related to bug #1242210. Sometimes, I get a gnome-shell dialog above firefox telling me that firefox is not responding. This dialog looks wrong to me as every time gnome-shell displayed the dialog, firefox had already loaded + rendered the website from the URL I've clicked on. To me it looks like firefox always immediately reacts on input. Every I've closed the dialog, firefox immediately reacted on mouse and keyboard input too.
I also sometimes get freezes when "Command completed" notifications from gnome-terminal appear, the notification appears immediately after the freeze. This is on Wayland, don't know about Xorg. It may be this is the same notification issue also noted in other bug reports here (and which then appears unrelated to firefox specifically), or perhaps there are multiple issues.
Freezes on "Command completed" notification also appear on Xorg, although perhaps somewhat shorter. (The freeze is also less noticeable than on Wayland, as the mouse pointer still moves, even though the rest of the UI is frozen.)
Having same problems here. Fedora 28, kernel 4.17.2-200.fc28.x86_64, Gnome Version 3.28.2. Klicks on urls (e.g. in evolution, or ctrl-click in shell) freeze session for 1-15 seconds. I do have freezes on all notifications. Examples: - evolution (e.g. calender notifications, new mail) - spotify, installed via flatpak - gnome plugins, e.g. TeaTime On last freeze I had to reset laptop, couldn't use mouse or keyboard. Waited for 3 minutes.
I only get this dialog when I disable gnome-shell animations. When I enable the animations, gnome-shell will still freeze for a few seconds but it will no longer show the "not responding" dialog on firefox.
(In reply to Christian Stadelmann from comment #7) > I only get this dialog when I disable gnome-shell animations. When I enable > the animations, gnome-shell will still freeze for a few seconds but it will > no longer show the "not responding" dialog on firefox. I was wrong about that. The dialog still appears with animations enabled.
@pav: Can you please nominate this bug as prioritized bug by adding "PrioritizedBug" to the "Whiteboard" field? The process is described at https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues_-_the_process
Possibly related issues (for reference): https://bugzilla.redhat.com/show_bug.cgi?id=1597032 https://bugzilla.redhat.com/show_bug.cgi?id=1565931 https://bugzilla.redhat.com/show_bug.cgi?id=1563811 https://bugzilla.redhat.com/show_bug.cgi?id=1566240 https://bugzilla.redhat.com/show_bug.cgi?id=1589440 https://bugzilla.redhat.com/show_bug.cgi?id=1585254 (Forgot to mention my system is Lenovo x240. The issue is still present with today's mutter-3.28.2-2.fc28)
Same here. Using GNOME Shell on Fedora 28, with X.org. Happens for a lot of notification types, too.
This is not new to fedora 28. I've been having these kinds of issues at least since f27 but more probably f26. - the lock screen freezing up for 30 seconds at a time on resume from sleep (this seems to have been MOSTLY fixed in one of the latest f28 updates, maybe kernel) - complete UI freezes of 10+ seconds on receiving a notification - session crashes due to or in relation to these said freezes. I'm not really sure what exactly is causing this but the simplest common denominator seems to be gnome-shell and/or wayland. I haven't tested on gnome-shell on xorg yet. I'm on a full-intel thinkpad T450s: only intel graphics and intel wifi.
At today's Prioritized Bugs and Issues meeting, we agreed to reject this as a Prioritized Bug. However, we are suggesting to the Workstation Working Group that they develop a "desktop polish" list that includes this bug. https://meetbot.fedoraproject.org/fedora-meeting-2/2018-08-29/fedora_prioritized_bugs_and_issues.2018-08-29-14.00.log.html#l-95
Upstream bug report: https://gitlab.gnome.org/GNOME/gnome-shell/issues/470
(In reply to Ben Cotton from comment #13) > At today's Prioritized Bugs and Issues meeting, we agreed to reject this as > a Prioritized Bug. However, we are suggesting to the Workstation Working > Group that they develop a "desktop polish" list that includes this bug. > > https://meetbot.fedoraproject.org/fedora-meeting-2/2018-08-29/ > fedora_prioritized_bugs_and_issues.2018-08-29-14.00.log.html#l-95 Has this desktop polish list been set up? This issue is really pressing (as you can see when looking at all the duplicates and related bug reports) and I would really like seeing this issue fixed as it hinders productivity for many people.
The situation improved a lot on Fedora 29 (Beta). I am not yet sure it has been fixed though.
(In reply to Christian Stadelmann from comment #16) > The situation improved a lot on Fedora 29 (Beta). I am not yet sure it has > been fixed though. No, it becomes more serious after I upgraded to F29.
For me this issue is not present any more in Fedora 29.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.