Open Bug 1762443 Opened 3 years ago Updated 7 months ago

[NVIDIA] Wayland window freezes when another window with a form is open

Categories

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

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 100
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: gtpepi, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 obsolete file)

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

Steps to reproduce:

OS: Arch Linux
Kernel: 5.17.1-zen-1-1-zen
Env:
__GLX_VENDOR_LIBRARY_NAME=nvidia
GDMSESSION=gnome
GBM_BACKEND=nvidia-drm
MOZ_ENABLE_WAYLAND=1

Scaling Factor applied = 1 (100%);
Font Scaling Factor = 2.5

Open a normal window, with one or more tabs.
On a website that has one of these, click to open a HTML form that open as a new window.

Actual results:

After being opened, the previous window will freeze. Alt+tab may unfreeze it after a few tries. The error eventually happens again when you switch from form window to normal browser window.
Even though it is frozen, the window responds to commands/inputs, it just doesn't display them until you alt+tab

Firefox stable + Firefox nightly show the same behavior

Doesn't log any kernel messages.

Expected results:

Freezing shouldn't happen on Wayland, and doesn't happen on Xorg

Freezing doesn't seem to happen when the 2 windows are side by side. Only when the form window draws over the browser window.

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

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core
Component: DOM: Core & HTML → Widget: Gtk

Hi!

I'm experiencing the same issue and will try to include some more information.

Steps to reproduce:

  1. Start Firefox and make sure it is running in full screen.
  2. Open up a new Firefox window.
  3. The newly opened window has frozen and a prompt to force quit Firefox will pop up after a couple of seconds.

Video example: https://webmshare.com/y1wYW

System information
I'm running Fedora 36 on GNOME/Wayland with the NVIDIA proprietary driver.

Fedora release 36 (Thirty Six)
Kernel: 5.18.5-200.fc36.x86_64
Firefox version: firefox-101.0.1-5.fc36.x86_64
NVIDIA version: akmod-nvidia-510.68.02-2.fc36.x86_64
GNOME version: gnome-shell-42.2-1.fc36.x86_64

about:support: https://pastebin.com/raw/YG9DBn7r

Profiler
I'm not exactly sure what the gecko profiler is, but I followed the instructions on profiler.firefox.com and ran it while forcing the issue.

https://profiler.firefox.com/public/p09b963e0cntbmq6r7vnq44aab02yamd2f3e4yr/calltree/?globalTrackOrder=0&localTrackOrderByPid=65816-10&thread=0&timelineType=cpu-category&v=6

A few things that I found out:

  • This issue does not happen if the new window does not open in full screen. So it works fine if your main window is not full screen when you open up a new window since the new window seems to keep the same size.
  • You can usually "save" the freeze by pressing Win+Arrow keys to resize the Window and alt+tab. Does not always work.
  • Creating a new profile or disabling all add-ons does not help.
  • I don't have this issue if I change WebRender to software (gfx.webrender.software = true) or start with firefox-x11 launcher on Fedora.
  • I downloaded the latest Firefox binary from the web page. I have the same issue if I start Firefox with MOZ_ENABLE_WAYLAND=1 ./firefox.
  • If I use the -no-remote launch option (suggested on the debug Firefox page you linked) on the Fedora packaged Firefox I am unable to open up a new window on any profile (Firefox is already running...). If I use it on the binary downloaded from Mozilla webpage (MOZ_ENABLE_WAYLAND=1 ./firefox -ProfileManager -no-remote) and select a profile that is not my default I am able to open up a new window and the window does not freeze. I don't know what the option actually do so not sure if that could be relevant at all.

If you need some more information or want me to try something else just ask. Thanks for the help!
/Daniel

Thanks for testing Daniel.
Can you please test latest nightly? There's a fix for fullscreen there.
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Flags: needinfo?(jagardaniel)

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

Thanks for testing Daniel.
Can you please test latest nightly? There's a fix for fullscreen there.
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Testing_Mozilla_binaries
Thanks.

Hi Martin. Thanks for the reply!

I tried the nightly binary but I'm still experiencing the same problem.

Steps to reproduce:

  1. Start the nightly binary with MOZ_ENABLE_WAYLAND=1 ./firefox -ProfileManager -no-remote
  2. Select a profile (does not seem to matter which)
  3. Open up a new window in some kind of way.
  4. The new window freezes until you resize it.

Screen recording: https://webmshare.com/nQdVa

Profiler
I opened up mozilla.org in a new window, waited around 10 seconds and then started dragging the window in the top bar to resize it (and make it "load/render").
https://share.firefox.dev/3ujkUPR

About support from nightly: https://pastebin.com/raw/tGAMuNNT

/Daniel

Flags: needinfo?(jagardaniel)

Yes, Thanks. I have similar reports on NVIDIA unfortunately I don't have such hardware.

Blocks: wayland
Priority: -- → P3
Summary: Wayland window freezes when another window with a form is open → [NVIDIA] Wayland window freezes when another window with a form is open

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

Can you try to disable WebRender?
https://fedoraproject.org/wiki/How_to_debug_Firefox_problems#Check_WebRender_state_(Hardware_acceleration)

Yes, it works if I disable WebRender. It also works under Xorg with WebRender enabled. So this issue only happens with WebRender enabled and on Wayland with MOZ_ENABLE_WAYLAND=1.

Flags: needinfo?(jagardaniel)

I guess is some NVIDIA/Wayland bug here.

Hi again. Some good news! I don't experience this issue anymore and I can now open new windows in full screen just fine both on Firefox Stable (102.0) and Nightly under Wayland (GNOME) with NVIDIA drivers (515.57). I haven't used my Linux install for a while so I can't pinpoint exactly which change solved the issue. It would be great if the reporter or someone else could confirm this as well.

about:support output now that it works: https://pastebin.com/raw/uAMFDSze

/Daniel

I'm (still) having the same issue, which has existed for me since Wayland GBM became available on NVIDIA with GNOME. I'm using the proprietary NVIDIA drivers on version 515.65.01 with Firefox 104.1, and GNOME 42.

Daniel has already kindly provided most of the relevant information. I myself can reproduce it as follows:

  1. Open Firefox. Ensure the main window is fullscreen.
  2. Open a second, incognito, window. Make it fullscreen.
  3. Alt-backtick in GNOME to focus the other window.
  4. Alt-backtick again to focus the second window again.
  5. The second window is now frozen and unresponsive.

It can indeed be "fixed" by making the window smaller, so it is not fullscreen any more.

It might be better/fixed with next egl-wayland release.

See Also: → 1752717

It might be better/fixed with next egl-wayland release.

FWIW, I'm currently on egl-wayland 1.1.11 released 11 days ago (at the time of writing), but the issue persists.

I had the same issue, then it stopped happening around a month ago. I didn't record the versions of the Nvidia driver and Firefox, sadly.

After a recent upgrade, the situation became even worse. The freezes now happen with a single window opened. Using Firefox Nightly 108.0a1 (2022-10-20) and nvidia/nvidia-utils 520.56.06.

No freezes yet on Firefox Nightly 108.0a1 (2022-10-21). I think, that's the only relevant thing that I upgraded today.

Redirect a needinfo that is pending on an inactive user to the triage owner.
:stransky, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gtpepi) → needinfo?(stransky)
Attachment #9383739 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: