Open Bug 2040066 Opened 21 days ago Updated 2 days ago

[CachyOS/KDE] Window freezes and becomes unresponsive randomly after scrolling a page

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 152
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
firefox152 --- affected

People

(Reporter: fiveNinePlusR, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

journalctrl -xb output
10.18 KB, text/plain
Details
freeze recorded
6.60 MB, video/x-matroska
Details
new recording
5.36 MB, video/x-matroska
Details
about_support
48.66 KB, text/plain
Details
about:support
59.01 KB, text/plain
Details
Attached file journalctrl -xb output —

While scrolling the page will be unresponsive to clicks and be unable to be scrolled or interacted with. typing the shortcut to change tabs will change the tab as firefox understands it(start playing a video) but will not change the visual chrome. This occurs with both middle mouse click auto scroll and also just normal mouse wheel scroll. Unsure if it also happens with keyboard scroll as I don't use that often.

If i move the window a little bit and use the desktop effect to show an overview of all the windows open and hover over the frozen firefox window there is a discrepancy between where the highlighted kwin outline and the visual representation of the window; kwin thinks that the window is in a different location.

It is sometimes possible to get the window responsive again by moving it to another virtual desktop and clicking on the taskbar icon associate with the window and tab.

I can not reliably replicate it but it happens fairly often with it happening a few times a day at least. My hunch is that there is some kind of wayland compatibility issue and firefox getting into an odd state. every other firefox window is interactable and works like normal.

KDE plasma, wayland.

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: General → Widget: Gtk
Product: Firefox → Core
Severity: -- → S3

Thanks for the report and the journalctl file.

To dig deeper, could you help with three things?

  1. Capture logs during a freeze. Run Firefox from a terminal like this, then reproduce the freeze:
MOZ_LOG="WidgetWayland:5" \
  MOZ_LOG_FILE=~/ff-freeze \
  WAYLAND_DEBUG=1 \
  firefox 2> ~/ff-freeze.wayland.log

Then attach both ff-freeze.moz_log and ff-freeze.wayland.log. About 30 seconds covering one freeze is enough.

  1. Tell us about your system. Please paste the output of:
firefox --version
plasmashell --version && kwin_wayland --version
glxinfo | grep -E "OpenGL renderer|OpenGL version|OpenGL vendor"
vulkaninfo --summary 2>&1 | head -40
lsmod | grep -E "nvidia|nouveau"
  1. Try two quick tests. Each one is just a one-line change:
  • Does the freeze still happen if you run MOZ_ENABLE_WAYLAND=0 firefox?
  • If you can install the proper NVIDIA driver on CachyOS, does the freeze still happen with it loaded?

You don't need to do both tests if one is hard. The logs in step 1 matter most.

Flags: needinfo?(fiveNinePlusR)

It's been random but it seems like I am able to get it to trigger on amazon pages if i scroll a lot.

As for part 1 what is the best way to get the last 30 seconds of the freeze... I was able to get the window to freeze fairly quickly but the file is around 500MB and I'm not sure if all that is needed or even able to be uploaded here?

as to part 3:

"If you can install the proper NVIDIA driver on CachyOS, does the freeze still happen with it loaded?"

I am using the NVIDIA proprietary drivers I believe. I don't think they are being modified by CachyOS.

Here's part 2:

Mozilla Firefox 152.0a1

plasmashell 6.6.4
kwin 6.6.4

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: NVIDIA GeForce GTX 1660 SUPER/PCIe/SSE2
OpenGL version string: 4.6.0 NVIDIA 595.71.05

==========
VULKANINFO
==========

Vulkan Instance Version: 1.4.341


Instance Extensions: count = 25
-------------------------------
VK_EXT_acquire_drm_display             : extension revision 1
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_EXT_surface_maintenance1            : extension revision 1
VK_EXT_swapchain_colorspace            : extension revision 5
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_portability_enumeration         : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_maintenance1            : extension revision 1
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6
VK_LUNARG_direct_driver_loading        : extension revision 1
VK_NV_display_stereo                   : extension revision 1

Instance Layers: count = 9
--------------------------
VK_LAYER_FROG_gamescope_wsi_x86_64 Gamescope WSI (XWayland Bypass) Layer (x86_64) 1.3.221  version 1
VK_LAYER_MANGOHUD_overlay_x86      Vulkan Hud Overlay                             1.3.0    version 1
VK_LAYER_MANGOHUD_overlay_x86_64   Vulkan Hud Overlay                             1.3.0    version 1

i2c_nvidia_gpu         16384  0
nvidia_drm            159744  422
drm_ttm_helper         20480  1 nvidia_drm
nvidia_uvm           2605056  0
nvidia_modeset       2203648  78 nvidia_drm
video                  81920  2 asus_wmi,nvidia_modeset
nvidia              16588800  1538 nvidia_uvm,nvidia_modeset
Flags: needinfo?(thinker.li)

I believe I have the same issue. I can consistently reproduce it on garmin's site when viewing an activity with a map. It happens as soon as I scroll down and then up a bit. Otherwise mostly happens on imgur (dumps with mostly videos, main page sometimes but less likely when I tried) and reddit. I'm on amd.
It doesn't happen with MOZ_ENABLE_WAYLAND=0. I also tried an empty profile which doesn't do it but if I try my main profile with addons disabled it still happens.

Mozilla Firefox 150.0.3

plasmashell 6.6.5
kwin 6.6.5

OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 7900 XTX (radeonsi, navi31, ACO, DRM 3.64, 7.0.7-arch2-1)
OpenGL version string: 4.6 (Compatibility Profile) Mesa 26.0.6-arch1.1

WARNING: [Loader Message] Code 0 : Removing layer VK_LAYER_VKBASALT_post_processing (/usr/share/vulkan/implicit_layer.d/vkBasalt.json) because it is a duplicate of VK_LAYER_VKBASALT_post_processing (/usr/share/vulkan/implicit_layer.d/vkBasalt.x86.json)
==========
VULKANINFO
==========

Vulkan Instance Version: 1.4.350


Instance Extensions: count = 26
-------------------------------
VK_EXT_acquire_drm_display             : extension revision 1
VK_EXT_acquire_xlib_display            : extension revision 1
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
VK_EXT_direct_mode_display             : extension revision 1
VK_EXT_display_surface_counter         : extension revision 1
VK_EXT_headless_surface                : extension revision 1
VK_EXT_layer_settings                  : extension revision 2
VK_EXT_surface_maintenance1            : extension revision 1
VK_EXT_swapchain_colorspace            : extension revision 5
VK_KHR_device_group_creation           : extension revision 1
VK_KHR_display                         : extension revision 23
VK_KHR_external_fence_capabilities     : extension revision 1
VK_KHR_external_memory_capabilities    : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2         : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2       : extension revision 1
VK_KHR_portability_enumeration         : extension revision 1
VK_KHR_surface                         : extension revision 25
VK_KHR_surface_maintenance1            : extension revision 1
VK_KHR_surface_protected_capabilities  : extension revision 1
VK_KHR_wayland_surface                 : extension revision 6
VK_KHR_xcb_surface                     : extension revision 6
VK_KHR_xlib_surface                    : extension revision 6
VK_LUNARG_direct_driver_loading        : extension revision 1

Instance Layers: count = 16
---------------------------
VK_LAYER_FROG_gamescope_wsi_x86_64 Gamescope WSI (XWayland Bypass) Layer (x86_64)               1.3.221  version 1
Flags: needinfo?(stransky)
Attached video freeze recorded —

Small recording of the freeze, it happens as I scroll up when viewing the activity. Pressing any of the menu buttons don't refresh the rendered page. Dragging the window has some kind of 'after effect' and the bottom right corner has some pixels that refreshes the underlying background or transparent. Minimising the window fixes it.

Also got the logs from the above request (links will expire in ~1 month)

https://drive.proton.me/urls/JYQJT48FAW#fWeQPadBBUpY
https://drive.proton.me/urls/PMEJ324HBM#hfWqilHMWxDA

Are log files created for the same session as the video?

Flags: needinfo?(thinker.li)
Flags: needinfo?(rly)

(In reply to Thinker Li [:sinker] from comment #7)

Are log files created for the same session as the video?

No, it was a separate one.

Flags: needinfo?(rly)

Could you explain what you did to generate these two files? It it the same flow as the video?

Flags: needinfo?(rly)

Which KDE version is that?
Thanks.

Flags: needinfo?(stransky)
Summary: Window freezes and becomes unresponsive randomly after scrolling a page. → [CachyOS/KDE] Window freezes and becomes unresponsive randomly after scrolling a page

(In reply to Thinker Li [:sinker] from comment #9)

Could you explain what you did to generate these two files? It it the same flow as the video?

More or less the same, I can't recall if I had garmin open already for the logs. In the video I dragged garmin's tab to a new window before the recording. But I just redid the logs and the video and will upload it again, this time I copied my main profile to a new one, closed all tabs and only left garmin up. Also I forget to mention but I'm on Arch, not Cachy if that matters.

Flags: needinfo?(rly)
Attached video new recording —

Opened activity, scrolled down then up till window freezed. Clicked around the left menu then dragged the window around, lastly minimised firefox to unfreeze (sometimes inconsistent and needs to do multiple times)
Logs during the recording:
https://drive.proton.me/urls/SHSV13QGAG#k26ebAOTUW36
https://drive.proton.me/urls/GRYKHVNSA8#rmXo0RsKtZgO

I dug into the attached wayland log file and video from comment #12, and found following facts.

  1. According to the video, Firefox freeze during 9s ~ 24s.
  2. Compoistor stop sending any wl_callback.done message in 9s ~ 24s about the same time.
  3. There are 6 pending wl_callbacks in the same period of time.
  4. The associated buffers are released or destroyed at the 24s.
  5. These associated buffers are all in 1024x512 size. (WebRender Tiles?)
  6. at 24s, the window was iconized 2nd time. The compositor started sending wl_callback.done and wl_buffer.release again.

It is more likely a compositor's issue. The after effects is also an issue of the compositor as well.

In this case, I guess vsync stops for not receiving any wl_callback.done. If rly can capture a profile, we can verify it.
If that is the case, Firefox could recover from it by starting emulated vsync after not receiving expected wl_callback.done for a few seconds even it is not caused by Firefox.

Hi Rly, could you use firefox profiler to capture a profile for freezing?

Flags: needinfo?(rly)

(In reply to Thinker Li [:sinker] from comment #14)

Hi Rly, could you use firefox profiler to capture a profile for freezing?

What profiler setting should I use?

Flags: needinfo?(rly)

Graphics or the default one would work.

(In reply to Thinker Li [:sinker] from comment #16)

Graphics or the default one would work.

Should be this one: https://share.firefox.dev/43hjshM

What is your default one? This profile misses the compositor thread. Could you try the Graphics setting? Make sure there is compositor thread in it. Thanks!

Flags: needinfo?(rly)

(In reply to Thinker Li [:sinker] from comment #18)

What is your default one? This profile misses the compositor thread. Could you try the Graphics setting? Make sure there is compositor thread in it. Thanks!

I used the Graphics for that one and it has the compositor thread in that. Is that considered a hidden thread that I need to select during the upload? Also made a new one with the default Firefox named profile which also has compositor.
https://share.firefox.dev/4eZRDlb

Also it seems like something may have changed because it no longer happens on the first try on garmin. It still happens but had to scroll a up/down a couple of times while before it was immediate. I updated my system on the evening of 19, but yesterday it was still happening.

Flags: needinfo?(rly)

Not sure! But trying to check every checkbox should work.

Flags: needinfo?(rly)

(In reply to Thinker Li [:sinker] from comment #20)

Not sure! But trying to check every checkbox should work.

I ticked to record all registered threads and ticked everything to upload.
https://share.firefox.dev/49IdD0s

Flags: needinfo?(rly)
Flags: needinfo?(fiveNinePlusR)

According to the profile from comment #21, Firefox didn't receive any wl_callback.done, our vsync source, from compositor when freeze.
Logs from comment #12 also show not receiving any wl_callback.done. Some requests of surface.frame are never emitted.
It is very likely a problem of compositor.
I would suggest to report it to the compositor community.

On the other hand, Firefox could detect missing vsync signals, and try to recover from it if possible.
It probably can recover by starting emulated vsync to restart wl_surface.frame.

(In reply to Thinker Li [:sinker] from comment #22)

According to the profile from comment #21, Firefox didn't receive any wl_callback.done, our vsync source, from compositor when freeze.
Logs from comment #12 also show not receiving any wl_callback.done. Some requests of surface.frame are never emitted.
It is very likely a problem of compositor.
I would suggest to report it to the compositor community.

On the other hand, Firefox could detect missing vsync signals, and try to recover from it if possible.
It probably can recover by starting emulated vsync to restart wl_surface.frame.

I opened bugreport on KDE.
Thank you!

I opened bugreport on KDE.
Thank you!

can you link the bug you opened here?

Flags: needinfo?(rly)

(In reply to fiveNinePlusR from comment #24)

I opened bugreport on KDE.
Thank you!

can you link the bug you opened here?

https://bugs.kde.org/show_bug.cgi?id=520564

Flags: needinfo?(rly)

Please attach your about:support page. I don't think it's KDE related.
Thanks.

Flags: needinfo?(fiveNinePlusR)
Attached file about_support —

(In reply to Martin Stránský [:stransky] (ni? me) from comment #26)

Please attach your about:support page. I don't think it's KDE related.
Thanks.

I attached mine. However as 151.0.1 got released in arch repo and updated to it, I can no longer reproduce it on garmin and haven't experienced it on any of the other sites mentioned since.

(In reply to rly from comment #28)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #26)

Please attach your about:support page. I don't think it's KDE related.
Thanks.

I attached mine. However as 151.0.1 got released in arch repo and updated to it, I can no longer reproduce it on garmin and haven't experienced it on any of the other sites mentioned since.

Okay, that's good new then. Please reopen if you see it again.
Thanks.

Status: NEW → RESOLVED
Closed: 11 days ago
Resolution: --- → WORKSFORME
Attached file about:support —

I'm on nightly so 153 version and it was happening for me (the reporter). I haven't really had it act up the last day or so though. Does 151 and 153 share code to the point where that could be resolved like that?

See above attached for the about:support

Flags: needinfo?(fiveNinePlusR) → needinfo?(stransky)

Happened twice again to me today.

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Could you still reproduce it reliably?

Flags: needinfo?(fiveNinePlusR)

(In reply to Thinker Li [:sinker] from comment #33)

Could you still reproduce it reliably?

I haven't found a reliable way to reproduce it like the other person did but I have found a reliable way to repair from the frozen window:

  1. Without moving the window at all click on a different tab or create a new tab.
  2. Minimize the window in the upper right corner
  3. Go to the icons only taskmanager and hover over the window that was just frozen. This creates a popup thumbnail that "re-activates" the window somehow.
  4. Click on it and it should be on a different tab and is able to be interacted with.

I wish I had a reliable reproduction... it seems to occur with some kind of video playing more often than not. I'm not certain if that is a requirement for the error or just random luck.

Maybe this will help narrow it down a little? It happened a few times today as well on: 153.0a1 (2026-05-26) (64-bit)

Flags: needinfo?(fiveNinePlusR)
Blocks: wayland-kde
Flags: needinfo?(stransky)

(In reply to fiveNinePlusR from comment #34)

(In reply to Thinker Li [:sinker] from comment #33)

Could you still reproduce it reliably?

I haven't found a reliable way to reproduce it like the other person did but I have found a reliable way to repair from the frozen window:

  1. Without moving the window at all click on a different tab or create a new tab.
  2. Minimize the window in the upper right corner
  3. Go to the icons only taskmanager and hover over the window that was just frozen. This creates a popup thumbnail that "re-activates" the window somehow.
  4. Click on it and it should be on a different tab and is able to be interacted with.

I wish I had a reliable reproduction... it seems to occur with some kind of video playing more often than not. I'm not certain if that is a requirement for the error or just random luck.

Maybe this will help narrow it down a little? It happened a few times today as well on: 153.0a1 (2026-05-26) (64-bit)

Thant may indicate broken D&D state when Firefox thinks is in active D&D.

It reliably happens for me on the latest nightly on this page: https://troutmanforamerica.com/ (I don't know anything about the guy but someone sent me the link as they had run a terrible campaign)

It seems to mainly happen on pages with embedded videos like the top one there that autoplay. Could be a red herring since it's not 100% that and has frozen on other pages without videos I think.

I took a log using the wayland thing from up above in one of the first comments but I'd like to know where to send it since it's fairly large at about a gig or so. If it is important I can share.

Flags: needinfo?(stransky)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: