Closed Bug 1752717 Opened 2 years ago Closed 2 years ago

[sway][nvidia] Firefox freeze when moving a window to another workspace (Fixed in upcoming egl-wayland release, the one after 1.1.10)

Categories

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

Firefox 96
x86_64
Linux
defect

Tracking

()

RESOLVED MOVED

People

(Reporter: kkartaltepe, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: hang)

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

Steps to reproduce:

Open a second firefox window. A full window or even just the "Help > About firefox" window is sufficient as a second window.

Send the 2nd window to a workspace that is not displayed (having a single monitor and sending the window to whatever workspace is not active is sufficient).

Observe the original window is no longer rendering and cannot be interacted with.

Go to the 2nd workspace and see the 2nd window is also not responsive. At this point we could resolve the issue by moving the 2nd window back to the same workspace as the original.

But instead lets now attempt to close the 2nd window, but it will not close immediately. To allow firefox to register the previously attempted close, swap between the workspaces with the original and 2nd window until the 2nd window closes.

Tested on sway 1.6 and 1.7, nvidia 495, egl-wayland 1.1.9, firefox 96 (with MOZ_ENABLE_WAYLAND=1, and webrender/wayland window system confirmed by about:support). I am including nvidia in this report as they have very particular locks on the wayland socket that have caused issues in firefox before and I cannot replicate this issue on intel hardware/drivers so I presume this is related.

Actual results:

Firefox froze and became unresponsive until we move all windows to the same workspace.

Expected results:

I would expect firefox to render correctly even if there are windows on other workspaces.

One minor note: There are some workarounds, such as un-focusing the firefox window before switching to other workspaces can avoid this issue sometimes. (alternately swapping workspaces with the firefox window in-focus can break a previously working two workspace setup).

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

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Blocks: wayland-sway
Keywords: hang
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
See Also: → 1751887
Priority: -- → P3

I can confirm this problem with sway 1.6.1, firefox 96.0.3 (with wayland enabled) and amdgpu. I always happens when switching focus with another window or switching workspaces. Let me know if I can gather any information to try and help.

Getting a profile with https://profiler.firefox.com and sharing it (top right corner) would be the most useful to know where time is spent.

https://share.firefox.dev/3oDe6ta here you can see the hang, screenshots show the partial render of the window that gets stuck.

I started with 2 windows in one workspace, at 2s I move the right window to a background workspace and the hang begins. During the 8s I left it hung I was also moving my mouse around the window. At 10s I swap between workspaces in order to close the 2nd window. Then I return to the 1st window and end the profile.

Any updates on this? The issue is still present on nvidia 515.65.01 and latest sway

https://share.firefox.dev/3QRagst
https://share.firefox.dev/3e2mqk5

Is there any place to get debug builds for firefox? My distro doesn't provide debug symbols

Flags: needinfo?(stransky)

Also, there's another issue where firefoz randomly freezes sometimes when launching an extension's pop-up window. I'm pretty sure that's related to this bug.

I suspect this is actually related to nvidia's egl-wayland platform libraries being completely broken in relation to frame delivery and eglSwapInterval. In their next release swapinterval should be fixed and ill test to see if this still occurs.

That was it! Firefox works fine with the latest egl-wayland commit. There are a few assertion failures on a debug build though (when opening the authenticator extension), release build seems to work fine. I also remember a bug where firefox would randomly exit on nvidia, will test a bit more and see if that occurs.

Blocks: wr-nv-linux
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Flags: needinfo?(stransky)
Resolution: --- → MOVED
Summary: [sway][nvidia] Firefox freeze when moving a window to another workspace → [sway][nvidia] Firefox freeze when moving a window to another workspace (Fixed in upcoming egl-wayland release, the one after 1.1.10)

Update: the issue where firefox randomly exits with "exiting due to channel error" is still present. Not sure if it's a sway thing (as there are bugs like this: https://github.com/swaywm/sway/issues/7011), will file a new issue after investigating.

This occured on the pling.com site, downloading a file with the download pop up open, and it exited when hovering over one of the tabs (for tooltip)

* WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
* Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS)
JavaScript warning: https://www.pling.com/tools/fpjs2/fp2.compressed.js, line 1: WebGL warning: <Create>: WebglAllowWindowsNativeGl:false restricts context creation on this system.
JavaScript warning: https://www.pling.com/tools/fpjs2/fp2.compressed.js, line 1: Failed to create WebGL context: WebGL creation failed: 
* WebglAllowWindowsNativeGl:false restricts context creation on this system. ()
* Exhausted GL driver options. (FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS)
console.warn: LoginRecipes: "Falling back to a synchronous message for: https://www.pling.com."
Extension error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowUtils.addSheet]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone :: line 68"  data: no] undefined 68
[[Exception stack
runSafeSyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:68:12
inject/cssPromise<@resource://gre/modules/ExtensionContent.jsm:529:36
Current stack
runSafeSyncWithoutClone@resource://gre/modules/ExtensionCommon.jsm:74:9
inject/cssPromise<@resource://gre/modules/ExtensionContent.jsm:529:36
]]
JavaScript error: moz-extension://32a49c4b-0a37-48fc-95c3-3ff17d6fa611/js/contentscript.js, line 206: NS_ERROR_NOT_INITIALIZED: 
JavaScript error: resource://gre/modules/ConduitsChild.jsm, line 67: InvalidStateError: JSWindowActorChild.sendAsyncMessage: JSWindowActorChild cannot send at the moment
JavaScript error: moz-extension://32a49c4b-0a37-48fc-95c3-3ff17d6fa611/js/vapi-client.js, line 230: InvalidStateError: An exception was thrown
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
See Also: → 1762443

Update: have switched to sway-git since my previous comment (~5-6 days) and haven't experienced any random exits even after hours of usage. It could be that I just haven't stumbled upon such a site yet (I also keep js disabled), but I think we can rule out any wayland/nvidia relation to that hypothetical bug.

Seems to be happening again with nvidia 515.76 and firefox 105.0, not sure which one broke it since both were updated at the same time. Will investigate.

Sorry for an extra comment, forgot to add this detail in the original. I'm referring to the bug where firefox freezes when using an extension like bitwarden, not the workspace bug.

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