1653850 - UI freezes under GNOME until I hit super key

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[mozbugilla]

Attachment: about_support.txt

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

There is no clear pattern to me, the UI freezes here and there. For example, if I scroll through my bookmarks, click on the "three bars" to to right top, play a video (note, audio still plays fine but UI is complete stuck), scrolling a web page. Then out of a sudden the whole UI freezes. If froozen and I hit e.g. Page Down key, then I don't see that Firefox scrolls down. However, if I hit SUPER key under GNOME twice, then the UI is refreshed and I can see that Firefox really scrolled down. Therefore, it seems that Firefox is still responding but it does not refresh the window.

In general, I can unfreeze Firefox while pressing super key in GNOME.

The problem still persists even if I run in safe-mode. Please find attached the about:support output.

This is happening for me since I upgraded from Fedora 31 to 32. Thus I'm not sure whether this is a Firefox bug or not. Though, this is the only regression I have since updating.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[mozbugilla]

I also tried to enable/disable hardware acceleration without luck.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Please try Firefox X11 which is provided by firefox-x11 package.
Thanks.

Comment 4

[spastorino]

Is this a dupe or similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1575171

Comment 5

[David Heidelberg [:okias]]

I don't think it's similar, due the fact this issue came up recent (with Firefox 78). Menus items won't get marked in UI, but when clicked, UI freeze. Then switching to another window or SuperKey makes Firefox responsible again, but this behaviour repeat itself after while (or immediately) again.

GNOME Shell/ Mutter: 3.36.4

Comment 6

[spastorino]

To be honest I'm not sure but I've been having hangs like this since a while in Gnome and just learned from this issue that pressing the super key unhangs Firefox.

Comment 7

[mozbugilla]

For the last two days I gave Firefox-X11 a try and since then I do not had any UI freeze. With Wayland I had at least a couple of freezes within a day.

If there is anything else I can test, just let me know.

Comment 8

[Martin Stránský [:stransky] (ni? me)]

Okay, Thanks. Robert, any idea how to debug this? Can mutter be the factor here?
Thanks.

Comment 9

[spastorino]

I still don't see how this issue is not the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1575171 or very similar. Martin, have you seen this comment I have made https://bugzilla.mozilla.org/show_bug.cgi?id=1575171#c24 where I've recorded a performance profile and it seems to get stucked for ~2 seconds in __GI___poll that is triggered from g_io_channel_new_file?.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

(In reply to spastorino from comment #9)

I still don't see how this issue is not the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1575171 or very similar. Martin, have you seen this comment I have made https://bugzilla.mozilla.org/show_bug.cgi?id=1575171#c24 where I've recorded a performance profile and it seems to get stucked for ~2 seconds in __GI___poll that is triggered from g_io_channel_new_file?

I haven't seen that. But should any application action cause whole UI freeze? I don't think so.

Comment 11

[Robert Mader [:rmader]]

I also tend to think of this as a duplicate of bug 1575171, but OTOH I used to see this in the past and can't recall having seen it in the last 2month or so. Given that I ride Mutter master, which has got a bigger frame callback emission rework for the next release (3.38), this could be in part caused by Mutter. bug 1575171 was also observed on sway, however.

Anyhow, I also see this as a important bug to be solved, will have a look if I can reproduce something around the g_io_channel_new_file stuff.

Comment 12

[David Heidelberg [:okias]]

With 79.0 issue seems to be gone. Can you retest @mozbugilla?

Comment 13

[David Heidelberg [:okias]]

it seems to be little bit better, but issue persist

Comment 14

[spastorino]

I can also confirm that the issue persist, I've just also turned on some wayland config options in about:config and the same happens.

Comment 15

[Martin Stránský [:stransky] (ni? me)]

Can you try to set "widget.wayland.use-opaque-region" to false at about:config and restart the browser?

Comment 16

[spastorino]

That's one of the first things I've tried and I'm using the browser since a while with that option set to false but it doesn't make any difference.

My current wayland related settings look like ...

widget.wayland-dmabuf-vaapi.enabled true
widget.wayland-dmabuf-video-textures.enabled true
widget.wayland-dmabuf-webgl.enabled true
widget.wayland-smooth-rendering true
widget.wayland.use-opaque-region false
widget.wayland_vsync.enabled false

but, I've only recently changed the following ones ...

widget.wayland-dmabuf-vaapi.enabled
widget.wayland-dmabuf-video-textures.enabled
widget.wayland-smooth-rendering

Comment 17

[Martin Stránský [:stransky] (ni? me)]

Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1860738

I'm not sure if that's Mutter or Firefox issue. There may be some lag in getting system events from Wayland display, it may be a problem with event loop or so but I'm not sure how to debug it.

Can you guys for instance try to run Firefox on terminal with

WAYLAND_DEBUG=1

env variable set and see if Firefox is getting any events when the freeze happens? But I suspect it should as it's mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=1860738 that PIP window keeps playing the video during the freeze.

Comment 19

[mozbugilla]

I've been using WAYLAND_DEBUG=1 extensively in the last couple of days and come to the following conclusion:

If Firefox is run in fullscreen mode, then the problem still persists.

If Firefox is not run in fullscreen mode and parts of a different application are focused and whenever the window of Firefox freezes you can "unfreez" Firefox by pressing a key (remember Firefox is not focused and this is not directly influenced by pressing a key). For example, having Firefox opened and playing a video it freezes here and there. If I open a terminal side by side and press a key whenever Firefox freezes, the video is "unfreezed". This "unfreezing" happens even if I run Firefox with WAYLAND_DEBUG=1 and put Firefox and the terminal side by side. For the latter test, Firefox did not freeze for the last couple of days whereas in fullscreen mode it typically freezes at least once after some time.

Comment 20

[David Heidelberg [:okias]]

my issue went away when I set widget.wayland_vsync.enabled back to false.

Sadly I haven't realised this change. Version 79.0 now, working well (also it sometimes crashed when clicking on MENU, which haven't occured yet after vsync disable).

Comment 21

[Kuba Orlik]

For me the issue only happens when I have a "hide title bar" extension enabled in Gnome. (see also: https://github.com/mlutfy/hidetopbar/issues/180 ).

This seems to somehow be a more general wayland issue, as I'm encountering it in other apps, as well

Comment 22

[Török Edwin]

I see something similar with firefox-wayland-80.0.1-2.fc32.x86_64 lagging/freezing (I have to alt-tab away, and then alt-tab back) when playing video or even just html5 presentations.
A good example of a page that reproduces this is https://store.steampowered.com/app/1286830/STAR_WARS_The_Old_Republic/: the videos there all freeze up from time to time as soon as they start playback under GNOME and mutter-3.36.5-1.fc32.x86_64, usually within the first few seconds. Not all videos reproduce the issue (e.g. youtube or just an .ogg file plays just fine)
However same page on sway-1.4-6.fc32.x86_64 works fine, so this might be DE specific.

The PIP mode seems better, it doesn't freeze, also if I open the .webm URL directly I don't see the freezes.

I think it might be lack of rendering rather than UI freeze as mentioned elsewhere: e.g. if I click on a different tab, or do some other action on the page it is not visible, but if I alt-tab away and back I find myself on the tab I clicked on previously.

I've noticed the messages below in journalctl -xe.

Sep 07 22:23:08 storm-broadband rtkit-daemon[1119]: Supervising 11 threads of 7 processes of 2 users.
Sep 07 22:23:08 storm-broadband rtkit-daemon[1119]: Successfully made thread 39117 of process 38472 (/usr/lib64/firefox/firefox) owned by '1000' RT at priority 10.
Sep 07 22:23:08 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:23:10 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:23:10 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:25:28 storm-broadband rtkit-daemon[1119]: Supervising 11 threads of 7 processes of 2 users.
Sep 07 22:25:28 storm-broadband rtkit-daemon[1119]: Supervising 11 threads of 7 processes of 2 users.
Sep 07 22:25:28 storm-broadband rtkit-daemon[1119]: Supervising 11 threads of 7 processes of 2 users.
Sep 07 22:25:28 storm-broadband rtkit-daemon[1119]: Supervising 11 threads of 7 processes of 2 users.
Sep 07 22:25:28 storm-broadband rtkit-daemon[1119]: Successfully made thread 39741 of process 39056 (/usr/lib64/firefox/firefox) owned by '1000' RT at priority 10.
Sep 07 22:25:28 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:26:30 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:26:30 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:26:35 storm-broadband gnome-shell[35390]: libinput error: event3 - Kinesis Advantage2 Keyboard: client bug: event processing lagging behind by 15ms, your system is too slow
Sep 07 22:26:41 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:26:41 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:27:10 storm-broadband gnome-shell[35390]: libinput error: event3 - Kinesis Advantage2 Keyboard: client bug: event processing lagging behind by 32ms, your system is too slow
Sep 07 22:27:36 storm-broadband gnome-shell[35390]: libinput error: event3 - Kinesis Advantage2 Keyboard: client bug: event processing lagging behind by 26ms, your system is too slow
Sep 07 22:28:04 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:28:04 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:29:00 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:29:00 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.
Sep 07 22:29:08 storm-broadband rtkit-daemon[1119]: Supervising 12 threads of 8 processes of 2 users.

If I stop rtkit with sudo rtkitctl -k the whole UI doesn't freeze up completely anymore, I can switch tabs, although there is a few second delay between clicking and switching (not always, but perhaps this depends whether the 2 tabs share the same 'Web Content' process or not?).
At least one of the videos still freezes during playback. Especially if you move the mouse over the video playback or the playback controls.

The messages about 'system is too slow' probably indicate an issue/bug in gnome-shell, I don't think the hardware could be at fault here:
CPU: AMD Ryzen 9 3900X 12-Core Processor
GPU: OpenGL renderer string: AMD Radeon RX 5700 XT 50th Anniversary (NAVI10, DRM 3.37.0, 5.7.11-200.fc32.x86_64, LLVM 10.0.1)
$ free
total used free shared buff/cache available
Mem: 65831624 16645500 12576800 2127572 36609324 46436600
Swap: 4194300 159304 4034996

Comment 23

[Török Edwin]

Further experimentation shows that CLUTTER_PAINT=continuous-redraw helps.
I modified /usr/share/wayland-sessions/gnome.desktop to contain this Exec line:
Exec=env CLUTTER_PAINT=continuous-redraw /usr/bin/gnome-session

(Note that to undo I had to make it CLUTTER_PAINT=, just logging out and back in has retained the env var otherwise)

Comment 24

[Török Edwin]

Opened clutter bug here: https://gitlab.gnome.org/GNOME/clutter/-/issues/18

Comment 25

[Michel Dänzer]

(In reply to Török Edwin from comment #23)

Further experimentation shows that CLUTTER_PAINT=continuous-redraw helps.
I modified /usr/share/wayland-sessions/gnome.desktop to contain this Exec line:
Exec=env CLUTTER_PAINT=continuous-redraw /usr/bin/gnome-session

That's really weird though, since Firefox doesn't use clutter, and AFAICT mutter's own copy of clutter completely ignores CLUTTER_PAINT=continuous-redraw.

Comment 26

[Michel Dänzer]

(In reply to Michel Dänzer from comment #25)

[...] AFAICT mutter's own copy of clutter completely ignores CLUTTER_PAINT=continuous-redraw.

Nvm, it still had an effect in mutter 3.36. However, that could just work around this Firefox bug, by doing a redraw cycle and sending a frame callback to Firefox even when there is really no reason to (because Firefox didn't make any changes to its surface).

Comment 27

[[e-mail]]

I use layers.acceleration.draw-fps = true as a workaround.

Comment 28

[zaitcev]

Setting layers.acceleration.draw-fps to true causes significant artifacts in my setup, drawing over UI elements. This is on Linux, Fedora 32, FF 79.

Comment 29

[Martin Stránský [:stransky] (ni? me)]

Can you try to enable webrender? I have a report that claims it helps. I suspect it's a bug in event handling in Basic compositor we have for Wayland, more specifically some kind of event exhaustion or so as we paint in different thread.

Comment 30

[Martin Stránský [:stransky] (ni? me)]

It will be really useful to get a part of WAYLAND_DEBUG=1 log when the freeze happens.

Comment 31

[Michel Dänzer]

(In reply to Martin Stránský [:stransky] from comment #29)

Can you try to enable webrender? I have a report that claims it helps.

FWIW, I've seen freezes like this with WebRender, but only with widget.wayland_vsync.enabled enabled. Since others are seeing it even with the latter disabled, maybe there are two separate bugs with similar symptoms:

• One with WebRender disabled
• One with WebRender & widget.wayland_vsync.enabled enabled

Comment 32

[Török Edwin]

Thanks, setting CLUTTER_PAINT= and gfx.webrender.all=true helps fix the problem as well. And setting gfx.webrender.all=false again makes it appear again. Will attach logs, when the problem happens I just see repeated entries like this in the log:
[40827.487] -> [e-mail]_buffer_scale(2)
[ 40846.101] -> [e-mail]_buffer_scale(2)
[ 40860.675] -> [e-mail]_buffer_scale(2)
[ 40879.144] -> [e-mail]_buffer_scale(2)
[ 40893.869] -> [e-mail]_buffer_scale(2)
[ 40913.176] -> [e-mail]_buffer_scale(2)
[ 40946.396] -> [e-mail]_buffer_scale(2)
[ 40979.754] -> [e-mail]_buffer_scale(2)
[ 40994.348] -> [e-mail]_buffer_scale(2)
[ 41012.874] -> [e-mail]_buffer_scale(2)
[ 41027.486] -> [e-mail]_buffer_scale(2)

Then if I switch away it starts drawing again:
[ 41631.868] [e-mail](1175, wl_surface@46)
[ 41631.878] [e-mail](1175, wl_surface@46)
[ 41631.887] [e-mail](wl_surface@46)
[ 41631.891] [e-mail](1176, wl_surface@46)
[ 41631.898] -> [e-mail]_cursor(1170, wl_surface@25, 3, 3)
[ 41631.905] -> [e-mail](wl_buffer@75, 0, 0)
[ 41631.911] -> [e-mail]_buffer_scale(2)
[ 41631.914] -> [e-mail](0, 0, 24, 24)
[ 41631.920] -> [e-mail]()
[ 41631.924] [e-mail]()
[ 41641.488] -> [e-mail]_buffer_scale(2)
[ 41641.658] -> [e-mail](wl_buffer@65, 0, 0)
[ 41641.668] -> [e-mail]_buffer_scale(2)
[ 41641.671] -> [e-mail](0, 0, 1920, 1053)
[ 41641.675] -> [e-mail]_min_size(502, 147)
[ 41641.677] -> [e-mail]_max_size(16435, 16435)
[ 41641.679] -> [e-mail]_window_geometry(0, 0, 1920, 1053)
[ 41641.683] -> [e-mail]_region(new id wl_region@77)
[ 41641.687] -> [e-mail](0, 0, 1920, 1053)
[ 41641.691] -> [e-mail]_opaque_region(wl_region@77)
[ 41641.693] -> [e-mail]()
[ 41641.696] -> [e-mail]_region(new id wl_region@63)
[ 41641.699] -> [e-mail](-10, -10, 1940, 1073)
[ 41641.703] -> [e-mail]_input_region(wl_region@63)
[ 41641.706] -> [e-mail]()
[ 41641.725] -> [e-mail](new id wl_callback@79)
[ 41641.729] -> [e-mail]()
[ 41642.182] [e-mail]_id(73)
[ 41642.197] [e-mail](199229259)
[ 41642.207] -> [e-mail]_buffer_scale(2)
[ 41642.211] -> [e-mail](0, 0, 2147483647, 2147483647)
[ 41642.215] -> [e-mail](new id wl_callback@73)
[ 41642.218] -> [e-mail](wl_buffer@78, 0, 0)
[ 41642.223] -> [e-mail]()
[ 41642.228] -> [e-mail](new id wl_callback@81)
[ 41646.049] [e-mail]_id(77)

Comment 33

[Török Edwin]

Attachment: wayland-debug-webrender.log

Comment 34

[Török Edwin]

Attachment: wayland-debug-no-webrender2.log

Comment 35

[Robert Mader [:rmader]]

FTR: I've personally not seen this in quite a while, but still remember having seen it in the past (https://bugzilla.mozilla.org/show_bug.cgi?id=1653850#c11). Mutter 3.36 just got a big backport concerning frame callbacks (https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1456), which potentially fixes this issue. It will get released in 3.36.7, which is due on saturday (03. oct, https://wiki.gnome.org/ThreePointThirtyseven/). So maybe an up to date Mutter + GTK3 will resolve this.

Comment 36

[Martin Stránský [:stransky] (ni? me)]

Bug 1668771 may help here, I added a timeout to the frame callback delay.

Comment 37

[Martin Stránský [:stransky] (ni? me)]

Bug 1668771 needs to be reverted due to https://bugzilla.redhat.com/show_bug.cgi?id=1888920

Comment 38

[Robert Mader [:rmader]]

Can someone still reproduces this on Mutter 3.36.7 / 3.38 and without the patch from bug 1668771?

Comment 39

[Robert Mader [:rmader]]

@Michel: I think what you were seeing on WR was one of the many incarnations of bug 1619246

Comment 40

[Robert Mader [:rmader]]

Török, as you seem to use Fedora I assume you are already on Mutter 3.36.7 or 3.38 - if that's the case, could you quickly say if you can still reproduce this? Thanks!

Comment 41

[mozbugilla]

Using mutter-3.38.1-1.fc33.x86_64 and firefox-82.0.2-1.fc33.x86_64 I cannot reproduce it anymore. The only thing I noticed is that some videos hang for roughly 1 to 2 seconds once in a while but they start playing normal without any interaction from my side. However, the UI---as initially reported---does not get stuck at all. This also happens so rarely that I can barely notice. Thus I would consider this bug as resolved for me. Not sure if others still run into problems.

Comment 42

[Török Edwin]

mutter-3.38.1-1.fc33.x86_64 with firefox-wayland-82.0.2-1.fc33.x86_64 and gfx.webrender.all set back to the default false: I can't repro the bug anymore.

Comment 43

[Robert Mader [:rmader]]

Thanks both of you. I then conclude this has been fixed by https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1218

Comment 44

[nightwalker85]

I'm still seeing these or similar issues with FF 100.0 and Mutter 41.4

Comment 45

[Coenraad]

I'm seeing this same issue on 105.0.2+build1-0ubuntu0.22.04.1~mt1 and xwayland 22.1.1-1ubuntu0.2 (Ubuntu 22, not using the Firefox snap, but I suspect it will do the same)

It only happens when I have more than 6 Firefox windows open. Firefox stops responding to window manager resizes ie. the inside of the browser page still occupies the space it did before the resize.

Comment 46

[Coenraad]

Pressing the super key updates/redraws the contents of Firefox windows.

Comment 47

[Martin Stránský [:stransky] (ni? me)]

Robert, any idea?
Thanks.

Comment 48

[Robert Mader [:rmader]]

Coenraad, can you post the content of your about:support ("Copy text to clipboard" -> paste here in a comment -> bugzilla will ask to make an attachment out of it -> yes)? That would be very helpful, in case there's something special/unusual about your setup.

Comment 49

[Jake]

Attachment: about:support output

Comment 50

[Jake]

I'm also running into the problem very frequently

• MOZ_ENABLE_WAYLAND=1
• 2 monitors, no HiDPI/LoDPI
• NVIDIA 3070 Ti (515.65.01)
• AMD 5800X processor

Hitting the super key to show previews makes all the firefox windows display correctly. Hitting it again to bring them back causes them all to freeze again. Maximizing windows seems to trigger it, one of my general fixes is to resize all the firefox windows so they're just smaller than maximized. It seems like if I have too many firefox windows open in a workspace it's more likely to happen.

Comment 51

[Jake]

Also to add:

• on PopOS 22.04
• installed via flatpak (flathub)

I can reliably reproduce if there's any DEBUG or config options you'd like me to turn on.

Comment 52

[Sandi Vujaković [:elsandosgrande]]

I get this freezing on GNOME Wayland as well — Ubuntu Jammy — using Firefox Nightly, but only after I've hovered over a tab with the cursor for long enough, because the title popups fail to display, which seems to cause the user interface to completely freeze up; maximising, minimising, fullscreening, unfullscreening, and bringing up the Activities overview does refresh the user interface, but only for a moment, as it is frozen once again after the refresh. I can even reliably freeze only one windows out of the three that I have open by only hovering over tabs in that one window.

Fun fact, whilst this freezing doesn't affect any regular web pages (aside from the amount of screen space available to them), it seems to have the exact same effect on the about: pages as it does on the user interface. Also, if any new tabs are created after the user interface freezes, they don't show up even after the user interface gets briefly refreshed. Oh, and you need to refresh the user interface when switching between tabs as well, or else the previous tab's page contents will still be present instead of the current tab's page contents.

---

It was much worse last week, when the entirety of Firefox seemed to just completely lock up seconds after opening for seemingly no apparent reason, including the page contents. I assume that that was essentially just this issue, but it wasn't just the user interface of one window freezing up.

Comment 53

[Sandi Vujaković [:elsandosgrande]]

Attachment: `about:support` text

Comment 54

[Sandi Vujaković [:elsandosgrande]]

Here's a recording: https://we.tl/t-TbOmOPE7Vi

Note: Towards the end, I pressed Ctrl+Tab and scrolled without refreshing the user interface to show what happens when you switch a tab and the page contents remain, you get to see part of the page contents as you scroll.

Comment 55

[Jan Alexander Steffens [:heftig]]

(In reply to Sandi Vujaković from comment #52)

I get this freezing on GNOME Wayland as well — Ubuntu Jammy — using Firefox Nightly, but only after I've hovered over a tab with the cursor for long enough, because the title popups fail to display, which seems to cause the user interface to completely freeze up

This should be the just-fixed bug 1796392.

Comment 56

[Sandi Vujaković [:elsandosgrande]]

(In reply to Jan Alexander Steffens [:heftig] from comment #55)

(In reply to Sandi Vujaković from comment #52)

I get this freezing on GNOME Wayland as well — Ubuntu Jammy — using Firefox Nightly, but only after I've hovered over a tab with the cursor for long enough, because the title popups fail to display, which seems to cause the user interface to completely freeze up

This should be the just-fixed bug 1796392.

And the tooltips appear properly now without any freezing! Thanks to the development team for the swift response!