Bug 1575281 - gnome-shell freezes momentarily when switching window focus via URL opening
Summary: gnome-shell freezes momentarily when switching window focus via URL opening
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell   
(Show other bugs)
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Owen Taylor
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Triaged
Depends On:
Blocks: WaylandRelated
TreeView+ depends on / blocked
 
Reported: 2018-05-05 16:26 UTC by pav
Modified: 2018-11-01 14:51 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description pav 2018-05-05 16:26:51 UTC
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.

Comment 1 Christian Stadelmann 2018-05-31 10:44:17 UTC
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?

Comment 2 pav 2018-05-31 19:02:59 UTC
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.

Comment 3 Christian Stadelmann 2018-06-09 10:10:38 UTC
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.

Comment 4 pav 2018-06-23 12:32:07 UTC
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.

Comment 5 pav 2018-06-23 14:40:35 UTC
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.)

Comment 6 Ulrich Schinz 2018-06-26 07:28:48 UTC
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.

Comment 7 Christian Stadelmann 2018-07-03 06:31:57 UTC
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.

Comment 8 Christian Stadelmann 2018-07-03 08:42:27 UTC
(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.

Comment 9 Christian Stadelmann 2018-07-09 08:43:22 UTC
@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

Comment 11 Gergely Polonkai 2018-07-27 07:40:44 UTC
Same here. Using GNOME Shell on Fedora 28, with X.org. Happens for a lot of notification types, too.

Comment 12 John Soros 2018-08-23 10:21:52 UTC
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.

Comment 13 Ben Cotton 2018-08-29 15:08:57 UTC
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

Comment 14 pav 2018-09-01 17:53:00 UTC
Upstream bug report: https://gitlab.gnome.org/GNOME/gnome-shell/issues/470

Comment 15 Christian Stadelmann 2018-09-07 07:31:07 UTC
(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.

Comment 16 Christian Stadelmann 2018-10-08 13:38:56 UTC
The situation improved a lot on Fedora 29 (Beta). I am not yet sure it has been fixed though.

Comment 17 Jungle 2018-11-01 14:47:08 UTC
(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.

Comment 18 pav 2018-11-01 14:51:46 UTC
For me this issue is not present any more in Fedora 29.


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