Full-Screen Firefox Freeze Workaround No Longer Works

[biergaizi]

Qubes OS release

Qubes 4.2

Brief summary

Under some circumstances (such as accidentally entering full-screen mode), Firefox can get stuck in a state that Qubes' window manager is unable to handle. This is a well-known issue, and the current FAQ documents the workaround at https://www.qubes-os.org/faq/:

Q: Fullscreen Firefox is frozen.

A: Press F11 twice.

Unfortunately, after upgrading to Qubes 4.2, Fedora 38, and Firefox 116.0.3. I found that the this workaround no longer seems to work. If possible, the window manager in Qubes' agent process should be updated to handle the new problem. If the problem is WONTFIX, it should still be seen as a documentation bug, and the FAQ should at least be updated with a new workaround to get out of the situation...

Steps to reproduce

1. Press F11 twice.

Expected behavior

Firefox should become responsive.

Actual behavior

Firefox freezes immediately, the navbars and tabs are no longer responsive.

[marmarek]

I cannot reproduce the issue on up to date Fedora 38 (which has Firefox 118.0.2). Maybe update will fix this for you?

[biergaizi]

I can still reproduce the problem with a near-fresh template with Firefox 118.0.2. I have no idea about how to troubleshoot it further.

[jamke]

I can still reproduce the problem with a near-fresh template with Firefox 118.0.2. I have no idea about how to troubleshoot it further.

You may try:

• to turn on/off Compositor in Window Manager Tweaks settings,
• add custom global shortcut of XFCE to toggle window fullscreen and check if it affects FF in this state,
• modify allowed fullscreen policy of qubes, maybe it will do something.

Those are not solutions, just things I would check if I had this issue.

[jmickelin]

Is it possible you're using i3? It's a common problem that Firefox fullscreen (and that of some other programs!) is broken when using a WM that doesn't properly implement the EWMH hints for requesting fullscreen, creating a state where Firefox waits for the window manager to resize its window but it never happens, which effectively freezes the Firefox GUI: https://bugzilla.mozilla.org/show_bug.cgi?id=1189622

I've worked around this in the past by adding a keybinding in the window manager for fullscreening the active window. Pressing this after it freezes kicks the GUI back to life as if the fullscreen request had succeeded as normal. In i3, this can be done with a key binding like

bindsym $mod+g fullscreen

According to the bug report cited above, another workaround is to set the option full-screen-api.ignore-widgets to false in Firefox's about:config. This causes it to not even attempt to send a request to get resized for fullscreen (causing the window to be "fullscreened" to a window/tile).

As for why i3 has this problem under Qubes when it doesn't on a bare metal machine (as far as I can recall?), maybe the request doesn't get propagated from the AppVM to the GuiVM, or there is a mismatch between the xprops of the Firefox window in the AppVM (which Firefox apparently uses to determine what to do when fullscreening) and the ones of the GuiVM. No idea.

[biergaizi]

Is it possible you're using i3?

No. I'm using the default XFCE window manager. I replicated the problem on both AMD GPU and Nouveau (if I recall correctly, with the modesetting DDX driver), with or without the XFCE compositor enabled. "Firefox getting stuck in full-screen mode" has always been a problem (clicking the "full screen" button on YouTube is a quick way of triggering that) because the full-screen status is not propagated from DomU's window manager to Dom0 properly (Qubes didn't implement full-screen until recently, and I haven't enabled it), but the "double F11" trick worked fine all the time.

Another unusual thing I've noticed is that the performance of some webpages has slowed down dramatically after upgrading Fedora, I'm getting 1 frame per second with difficulties on typing text in some some 2D webpages just with a bit of animation that didn't have any problem in the past. I suspect it's due to the change in the Firefox rendering backend which makes more use of GPU acceleration, thus stressing the LLVMpipe software renderer fallback. But I don't have time to investigate it further at this moment.

[DemiMarie]

Another unusual thing I've noticed is that the performance of some webpages has slowed down dramatically after upgrading Fedora, I'm getting 1 frame per second with difficulties on typing text in some some 2D webpages just with a bit of animation that didn't have any problem in the past. I suspect it's due to the change in the Firefox rendering backend which makes more use of GPU acceleration, thus stressing the LLVMpipe software renderer fallback. But I don't have time to investigate it further at this moment.

Which websites are these?

[biergaizi]

Upon further experimentation, I noticed the problem doesn't always occur. If Firefox is opened at the default position without additional touches to the window, hitting F11 doesn't freeze the browser and works as expected. But if the window is maximized in Qubes before hitting F11, it immediately causes the window to stuck in a broken state with unresponsive tab and menu bars. In the past, hitting F11 to re-entering and quitting full-screen mode several times usually fixes that, but it no longer works.

Which websites are these?

My current observations of Firefox 118.0.2 in Fedora 38 as compared to Firefox 94.0 in an ancient Fedora 33 template are:

1. Even smooth scrolling (a default-enabled feature) animation on both templates has slowed down. In Fedora 33 / Firefox 94.0, smooth scrolling feels relatively responsive, but there can be screen tearing. In Fedora 38 / Firefox 118.0.2, the screen tearing no longer seems to exist, but the scrolling animation also became slower. It feel as if the animations are rendered more frequently, making them slower.

2. In Fedora 38 / Firefox 118.0.2, there are some performance problems in animation-heavy websites. The simplest reproducer I can find is https://firefish.social. It's a social media front-end with heavy use of animation. In Fedora 38 / Firefox 118.0.2, just by clicking the "sign-in" or "sign up" button, the window pop-up animation takes several seconds to complete rendering at roughly 1 FPS and 100% CPU usage, with difficulties to enter text in the textboxes. In Fedora 33 / Firefox 94.0, the window pop-up animations only takes roughly 1 second to complete without text entering problems.

I've already confirmed both findings using fresh Firefox profiles. There can still possibly be user configuration differences here, as I don't have time to try a complete refresh template and profile right now to rule them out.

[andrewdavidwong]

Qubes didn't implement full-screen until recently

Qubes has had support for fullscreen mode for over 10 years (see, e.g., https://github.com/QubesOS/qubes-doc/commit/d1a090cfab2aafed62d02ca87490d942907f3501).

[TommyTran732]

So I am experiencing the exact same issue. The workaround to fix all of the problems with maximizing videos is to just set full-screen-api.ignore-widgets in about:config to true

[dimlev]

I am having the same issue on Qubes 4.2.4 with:

• Fedora 41 + LibreWolf 139.0.4-1
• Debian 12 + Firefox ESR.

Also note:

• This only happens in appvms that do not allow fullscreen mode.
• The compositor is off
• Not using i3

@TommyTran732 your workaround seems to be working but i just set both

full-screen-api.enabled to false

and

full-screen-api.ignore-widgets to true