Open Bug 1727815 Opened 1 year ago Updated 5 months ago

[Wayland] Firefox becomes unresponsive if the wayland compositor refuses a fullscreen request

Categories

(Core :: Widget: Gtk, defect)

defect

Tracking

()

UNCONFIRMED

People

(Reporter: alexander, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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

Steps to reproduce:

Run firefox under a wayland compositor that does not make firefox fullscreen in response to xdg-shell fullscreen requests. Compositors with this behaviour include:

Try to make firefox fullscreen by clicking "View->Full Screen" or pressing F11.

I reproduced this under firefox 91.0.1 and nightly, under both sway and vivarium as above.

Actual results:

Firefox does not transition to fullscreen and the firefox UI components become unresponsive, but it remains possible to interact with the currently-visible webpage. Firefox's non-visible state is still changing though, e.g. clicking the new tab button has no visual effect but the firefox window title changes to indicate the new tab page is showing.

Some actions cause the gui to refresh, showing e.g. popup menus that have been clicked on but did not previously appear.

Expected results:

Firefox should have gone into fullscreen view mode.

I think I understand what is wrong - GTK makes an xdg-shell request to go fullscreen, which is denied, but then firefox never receives/acts-on any event that would trigger completion of the fullscreen transition. It remains stuck in what is supposed to be a transitional state.

I believe the correct behaviour would be for firefox to wait for a fullscreen event, then transition anyway if it doesn't receive one within a short timeout. This is because the xdg-shell fullscreen state is places very specific requirements on the compositor, and in practice the firefox window may be fullscreen in a reasonable sense even if the xdg-shell requirements are not met. Specifically, xdg-shell says:

If the surface doesn't cover the whole output, the compositor will position the surface in the center of the output and compensate with with border fill covering the rest of the output. The content of the border fill is undefined, but should be assumed to be in some way that attempts to blend into the surrounding area (e.g. solid black).

If the fullscreened surface is not opaque, the compositor must make sure that other screen content not part of the same surface tree (made up of subsurfaces, popups or similarly coupled surfaces) are not visible below the fullscreened surface.

Wayland compositors may make the window fullscreen in some reasonable sense (e.g. filling a workspace even though there are multiple workspaces displayed on an output) even if they don't meet the xdg-shell requirements, so firefox should still go fullscreen internally to support this.

I have a code fix to propose that would fix the issue in this way.

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
Summary: Firefox becomes unresponsive if the wayland compositor refuses a fullscreen request → [wayland] Firefox becomes unresponsive if the wayland compositor refuses a fullscreen request
Summary: [wayland] Firefox becomes unresponsive if the wayland compositor refuses a fullscreen request → [Wayland] Firefox becomes unresponsive if the wayland compositor refuses a fullscreen request
Attachment #9238259 - Attachment description: WIP: Bug 1727815 Toggle internal fullscreen even if window widget fullscreen not achieved → Bug 1727815 Toggle internal fullscreen even if window widget fullscreen not achieved
Assignee: nobody → alexander
Attachment #9238259 - Attachment description: Bug 1727815 Toggle internal fullscreen even if window widget fullscreen not achieved → Bug 1727815 Toggle internal fullscreen even if window widget fullscreen not achieved r=stransky
Attachment #9238259 - Attachment description: Bug 1727815 Toggle internal fullscreen even if window widget fullscreen not achieved r=stransky → Bug 1727815 Toggle internal fullscreen even if window widget fullscreen not achieved r=emilio

This may also help with Bug 1636168

Attachment #9238259 - Attachment description: Bug 1727815 Toggle internal fullscreen even if window widget fullscreen not achieved r=emilio → Bug 1727815 Toggle internal fullscreen even if window widget fullscreen not achieved r=emilio,stransky

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:alexander, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(stransky)
Flags: needinfo?(alexander)

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:alexander, could you have a look please?

I'm not sure what I'm supposed to do now to progress this, so I have asked on the phabricator review.

Flags: needinfo?(alexander)
Flags: needinfo?(stransky)
Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/da5a7c4478d9
Toggle internal fullscreen even if window widget fullscreen not achieved r=stransky

The assertion that has failed is now out of date and should probably be removed, I will confirm and update the patch. I'll also work out how to test more thoroughly with DEBUG enabled, I didn't realise I didn't have that already (which would have hit the assert and caught the issue sooner).

Flags: needinfo?(alexander)

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: alexander → nobody
You need to log in before you can comment on or make changes to this bug.