Description of problem: firefox while on page freezes intermittently, preventing scroll or any other input, unfreezes when mouse hovered over adjacent tab Version-Release number of selected component (if applicable): Noticed it since firefox-135 How reproducible: happens often happens on any webpage Steps to Reproduce: 1. firefox has many tabs open 2. firefox does have many extensions installed, but unsure if any is responsible 3. just open some long webpage, read and keep scrolling down Actual results: - At some point using the laptop touchpad to scroll up/down will not work - When the mouse pointer is hovered over the adjacent tab, the page instantly unfreezes. It seems like the attempted inputs are buffered and get replayed when unfrozen. For instance if one was trying to scroll up, the page does jump up to final position. - Though not exactly timed, it takes duration before the same page freezes again. Expected results: - firefox should never freeze like this. irritating/frustrating effects user experience. Additional info: - It is not that the OS or firefox has hung - It has happened since fedora-41,now on fedora-42 - It does not seem to be an out-of-memory issue - It does not appear like memory garbage cleanup issue - The freeze does not seem to unfreeze on its own. The mouse pointer move to hover over the tab instantly unfreezes the page. - The processor does not seem to be overloaded, just a couple of browser profiles. - Using Linux - Using gnome-desktop , gnome-shell - Using gen-4 Intel i7-4700MQ CPU with gen-7.5 iGPU Intel HD graphics 4600 , intel i915 driver - has Nvidia GT740m kepler hybrid DGPU, but that GPU is most likely not being invoked, nouveau driver - On Mesa 25.0.2-3.fc42.x86_64 Other bug reports elsewhere describing the same issue - Mozilla upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1949725 - Arch: https://bbs.archlinux.org/viewtopic.php?id=303079 - Debian: https://forums.debian.net/viewtopic.php?t=161779 - Nobara: https://www.reddit.com/r/linuxquestions/comments/1jklkuj/firefox_tab_in_focus_on_nobara_hangs_but_acts/ Logs: ``` root@localhost:/home/user# uname -a Linux localhost 6.14.0-63.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Mar 24 19:53:37 UTC 2025 x86_64 GNU/Linux root@localhost:/home/user# rpm -qa | grep mesa-filesystem | grep x86_64 mesa-filesystem-25.0.2-3.fc42.x86_64 root@localhost:/home/user# glxinfo | grep -i "OpenGL renderer" OpenGL renderer string: Mesa Intel(R) HD Graphics 4600 (HSW GT2) root@localhost:/home/user# vulkaninfo | grep "^GPU id" MESA-INTEL: warning: Haswell Vulkan support is incomplete GPU id : 0 (Intel(R) HD Graphics 4600 (HSW GT2)): GPU id : 1 (llvmpipe (LLVM 20.1.1, 256 bits)): ```
Please run on terminal as: MOZ_LOG="Widget:5 WidgetVSync:5" firefox and if you see the freeze, switch Firefox to terminal, hit CTRL+C and attach the log here. Thanks.
Created attachment 2083721 [details] log attempt 01 to catch a freeze In attempt 01, I thought I had a freeze, I alt tabbed to terminal and ctrl-C-ed as fast as possible.
Created attachment 2083722 [details] log attempt 02 to catch a freeze In attempt 02, I think I had a freeze, I may have instinctively moved cursor to outisde window/tab area, which may caused an unfreeze, but then alt-tabbed to terminal and ctrl-C-ed.
- Unsure if the below matters. - I usually notice/encounter these freezes when I'm on a forum website, gitlab bugreport, github=bugreport, discourse-fedoraproject, maybe scrolling down youtube comments and the like - The nature of the browing activity, and the webpage has to retrieve posts/comments. the user me will be scrolling, sometimes there will be posts in edit mode, sometimes a text maybe selected. - Though it may be more general, but may also be a function on what kinds of webpages I'm usually on. - Sometimes it felt like it doesn't happen if I'm just waiting for it to happen, it needs something like a genuine user doing genuine browsing while doing a touchpad finger scroll.
Created attachment 2083734 [details] log attempt 03 to catch a freeze In attempt 03, I tried to resist the urge to unfreeze by the focus on tab method that has become habit. It seems like the freeze can go on over a minute, perhaps indefinitely, its not waiting on something to complete, just stuck. I eventually alt-tab-ed to the terminal and ctrl-c-ed the process. Its possible that alt-tabbing itself will unfreeze the webpage, which should get logged into the log-files before I press ctrl-C. After a unfreeze, I don't see anything logged in the firefox-console shift-ctrl-C
- In the logs, I observe that - there is a block of log-lines near the end which have only D/Widget and V/Widget lines and no D/WidgetVSync - this block of lines could correspond to the frozen state - this block of lines are preceded by lnes where D/Widget , V/Widget and D/WidgetVSync are all intersparsed - later, at the end of this block of lines, one can see a OnKeyPressEvent, OnLeaveNotify, OnContainerFocusOutEvent , which probably correspond to doing the Alt-Tab (which is to switch window) - after this the D/WidgetVSynclog lines also resume intersparsed wth the D/Widget and V/Widget lines - soon after end of file happens due to Ctrl-C .
Does it help if you set widget.wayland.vsync.enabled to false at about:config? Thanks.
- I have been using the browser profile for several hours now, with `widget.wayland.vsync.enabled set to false` and not seen the freeze. - One can't prove a negative, but the freeze hasn't happened so far. - So it might be a workaround until a real fix lands. - If it does happen in the browser profile that I usually use, I will write a bugzilla comment to that effect to notify you. - In the logs, usually there are almost-no D/WidgetVsync Lines. Apart from the below pair of lines that appear rarely, sometimes at least a 1000 lines apart, - [Parent 1347243: Main Thread]: D/WidgetVSync [7efc07607700]: nsWindow::CreateCompositorVsyncDispatcher() - [Parent 1347243: Main Thread]: D/WidgetVSync [7efc07607700]: mWaylandVsyncSource is missing, create nsBaseWidget::CompositorVsyncDispatcher() $ rpm -qa | grep x86_64 | grep -Ei "gdm-|gnome-session-wayland-session|libwayland-|xorg-x11-server-Xwayland" libwayland-client-1.23.0-3.fc42.x86_64 libwayland-server-1.23.0-3.fc42.x86_64 libwayland-egl-1.23.0-3.fc42.x86_64 libwayland-cursor-1.23.0-3.fc42.x86_64 xorg-x11-server-Xwayland-24.1.6-1.fc42.x86_64 gnome-session-wayland-session-47.0.1-2.fc42.x86_64 gdm-48.0-1.fc42.x86_64
- Do let me know, if you want me to gather any further logs, in order to help you narrow the root-cause.
Thanks! I think this is related. The comment 6 help me to find it, thanks for the guide: [Parent 1231517: Main Thread]: D/WidgetVSync [7fbc8f8fd600]: WaylandVsyncSource::DisableVsync fps 3.615839 [Parent 1231517: Main Thread]: D/WidgetVSync [7fbc8f8fd600]: WaylandVsyncSource::EnableVsync fps 3.615839 [Parent 1231517: Main Thread]: D/WidgetVSync [7fbc8f8fd600]: WaylandVsyncSource::HiddenWindowCallback() we're hidden, time since last VSync 1002 ms We're firing event for hidden window with after VSync enable which is wrong.
Upstream bug, will solve it there: https://bugzilla.mozilla.org/show_bug.cgi?id=1951249 Thanks again!
okie thx # rpm -qa | grep firefox firefox-137.0-2.fc42.x86_64 firefox-langpacks-137.0-2.fc42.x86_64