Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Firefox freezes up for a minute. This seems to be associated with something AJAX-related, and does not happen on static pages with no JavaScript. But it's not looping on the CPU [sic]! So, it's not a performance issue with GC or anything like that. In particular, it appears Firefox unfreezes if one switches to another application (such as gnome-terminal). The moment the window manager or compositor switches, Firefox UI unfreezes. Switching to other tab is not possible. The whole UI is frozen. Version-Release number of selected component (if applicable): firefox-78.0.2-1.fc32.x86_64 How reproducible: Not obvious how. Try visiting notifications in Facebook. Another site to try is LinkedIn. Steps to Reproduce: 1. Find a website with Javascript, such as Facebook 2. Try to dismiss notifications or do something in general 3. Observe a freeze Actual results: UI freezes (no CPU loop, just a hang) Expected results: Working normally. Additional info: I think this actually started in FF77 in F31. The FF78 is no different. I saw a reference to this on a blog by Colin Walters: "However, I am already noticing the Firefox UI periodically lock up for seconds at a time, which wasn’t happening before." He makes a conjecture that SQLite is at fault. I'm pretty sure it's not. In particular, the command that he suggests finds tiny numbers of fragments on my desktop. The largest is 81. A couple of commenters on Colin's blog entry also complained. So, it happens quite a bit and yet I cannot find a bug already filed.
Bug 1838951 may be a dup, but there's not enough detail to tell.
Can you check if you see it also with firefox-x11 package? Thanks.
Indeed as you suspected the firefox-x11 is not affected. Tested with firefox-x11-79.0-3.fc32.x86_64.
By the way, reproducing this is a bit more tricky than I let on. It will not happen if the system is fresh after a reboot. Takes a few hours to start happening.
I think it's related to some GPU resource exhaustion and may be different for GL Firefox backend for instance and also a different Wayland compositor (KDE/Sway) may behave better here.
For instance do you have anything related in journalctl log? use 'journalctl -b -1' on terminal to show log from previous boot.
Happens to me quite consistently on a web pages with multiple UI elements (like GitHub Pull Request pages, for example). It unfreezes after several seconds if there is no user input, and unfreezes immediately after switching to a different window in Gnome session. The package is: firefox.x86_64-79.0-4.fc32 running in Gnome Shell session on Wayland. When the freezes happen, no log records are being added, (so neither journalctl, nor dmesg report anything at a time of the bug — be it related to Firefox, Gnome, Wayland, GPU or anything else. Firefox from firefox-x11-79.0-4.fc32.x86_64 seems to be working normally in the same circumstances.
From the description it looks like lack of rendering rather of freeze. How does the freeze look like? Does it react to mouse/keyboard input or so? Can you do a simple test, when you run a video from youtube, move it to PIP (picture-on-picture), mark the PIP window stay on top (right click on the PIP window) and then try to freeze the browser? To see if the browser is frozen of just a single page is non-reposible or so. Also it would be great to have some test page for reproduction. Thanks.
Please also try to set 'widget.wayland.use-opaque-region' to 'false' at about:config and restart the browser. That tells mutter to always paint FF window.
Thanks for the hints! The freeze starts, in general, from an interaction with UI elements on a page (like checking-in a checkbox or scrolling a window by dragging scrollbar with the cursor). Firefox window doesn't react to any input for up to 5 or more seconds, but it seems that all this input is being delivered to the window, because after passing of some time it correctly renders all letters that has been typed, moves the view by a number of scrolled lines or switches to a different tab in the same window if such action had been dispatched (ctrl+tab or alt+some_number). It is possible to make it update the window content quicker by switching windows (alt + tab'ing or tapping Meta/Win key in Gnome Shell quickly). So it indeed may be called "a lack of rendering", as you said. I have tried running a window with a video in PIP and marked it to remain on top. The situation still occurred, although the video was still running without any problem. Setting 'widget.wayland.use-opaque-region' to 'false' also didn't prevent the behaviour from showing up. The pages that I used during the testing: https://github.com/torvalds/linux/pull/804/files https://reactrouter.com/web/example/auth-workflow I have a double-monitor setup and during testing I had two windows of Firefox opened on each monitor, also had an opened windows of Gnome Terminal and Visual Studio Code. I switched between these windows for a couple of minutes, interacting with UI elements of the pages (clicking checkboxes on and off, selecting elements and text on them, scrolling the pages up and down with scrollbar) then the freezes started. The freezes occurred on both Firefox windows (but if I moved a cursor to another window and tried to scroll, the first window would unfroze). No messages regarding firefox.desktop (or any other aforementioned suspected subsystems or packages) were found in journalctl output afterwards. There were some messages from ghome-shell though, but I'm not sure whether it is related or not: Aug 06 18:39:03 Katris-MBP gnome-shell[2145]: libinput error: event8 - ALP0017:00 044E:121C Touchpad: client bug: event processing lagging behind by 18ms, your system is too slow Aug 06 18:39:26 Katris-MBP gnome-shell[2145]: libinput error: client bug: timer event5 debounce short: scheduled expiry is in the past (-1ms), your system is too slow
Above I mentioned a double-monitor setup and having several windows opened, but the same happened when I switched the monitor off and had only a single Firefox window.
Thanks for testing. Let's track it upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1653850
Created attachment 1710717 [details] journalctl -n 1000 I don't see anything graphics related in the journalctl output when the freeze happens.
I think it's more related to some event handling or rendering.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1653850#c23 I think it is a bug in clutter, since CLUTTER_PAINT=continuous-redraw seems to help