Some bugs with the Firefox Wayland compositor integration backend

[rmader]

Please fill out the following:

• Sway Version:

  • latest master / 3bf9919

• Description:

• Firefox now has an experimental Wayland backend that defers all compositing to the Wayland compositor, instead of using an internal compositor which only submits the final result. It does so by using subsurfaces, viewports and buffer transforms. Doing so allows some interesting optimizations, including reduced blitting while scrolling, using YUV buffer formats for embedded videos and more.

• STR:

  • run a recent Firefox nightly (>= 91.0a1 (2021-06-11)) with the native Wayland backend (MOZ_ENABLE_WAYLAND=1)
  • enable compositor integration in about:config -> gfx.webrender.compositor.force-enabled:true
  • restart FF

• Observed issues

  • Rendering gets stuck after a short period of usage
    • Suspicion: FF uses a pool of (sub)surfaces that it constantly recycles. This works by detaching and reattaching subsurfaces to a parent surface, destroying and recreating the subsurface role. Maybe sway/wlroots does not yet properly support this
  • When scrolling, content areas do not get updated correctly. There is an effect of things getting updated in the opposite direction of the scrolling.
    • Suspicion: We had a similar effect in Mutter and it turned out we applied viewports and buffer transforms in the wrong order. FF uses WL_OUTPUT_TRANSFORM_FLIPPED_180 by default because it internally uses a coordinate system starting at the top-left, not bottom-left like GL does.

[emersion]

Thanks for the bug report, I'll have a look.

[rmader]

For the record: latest Firefox nightly / upcoming beta 92 appears to work perfectly fine \o/
It now uses DMABUF directly instead of EGL, thus odd subsurface reordering, buffer transforms and reattaching subsurfaces are not needed any more (or at least much less). It's probably still worth to fix these issues, but they don't block Firefox any more.

[emersion]

Good to hear! Keeping this open to track the original bugs.

[ojab]

Thought that it will be a nice workaround for https://bugzilla.mozilla.org/show_bug.cgi?id=1722767, but with gfx.webrender.compositor.force-enabled:true Fx shows a black window briefly and then crashes with Gdk-Message: 21:09:11.537: Error flushing display: Broken pipe here.

[luispabon]

@rmader current firefox nightly (92.0a1hg20210808r588154-0ubuntu0.21.04.1~umd1) has issues with extension menus - they don't display on any output (on <= FF91 they wouldn't display on unscaled outputs). Context, right-click menus sometimes don't appear on the first right click either. Other menues, like hamburger, are also hit and miss

[rmader]

@luispabon: is that specific to the native compositor backend (gfx.webrender.compositor.force-enabled:true) or generally with FF on Wayland? Because this bug is only about the former.

[luispabon]

With the native compositor backend:

[mvdan]

Rendering gets stuck after a short period of usage

After updating to Firefox v91, I've started experiencing a very similar issue. After using Firefox for a while, the UI refreshes will "lock up" - for example, switching tabs will freeze the UI until I move the mouse between displays or switch windows.

I run sway and firefox stable, and the only major things I've changed in Firefox are turning on WebRender and its wayland backend to avoid xwayland. That worked for the most part with Firefox v90, with minor bugs like #6147. This bug seems worse; whenever it happens, the browser becomes unusable, and my only option is to blindly close all tabs and restart the browser.

I do not have gfx.webrender.compositor.force-enabled turned on, though. about:support tells me WEBRENDER is "force enabled by pref", and WEBRENDER_COMPOSITOR is "disabled by default".

[rmader]

@luispabon: what you see is likely #6426 - at least if the issue also happens without gfx.webrender.compositor.force-enabled

@mvdan: if you don't have gfx.webrender.compositor.force-enabled, then it's not related to the issue here. Sounds pretty bad though. Given that we enable Webrender almost everywhere by default now, you may try disabling gfx.webrender.all.

[mvdan]

Thanks @rmader, that's fair. I'll try to eliminate other possible causes before disabling webrender altogether.

[mvdan]

Disabling webrender does seem to make it harder or impossible for me to reproduce the lock-up issue. I've opened #6432 since I'm not using the webrender compositor.

[emersion]

The second issue has been fixed. The first issue is maybe the same as #6432, but not sure yet.