Browser Docks on Wayland: is this still just a matter of time, or actually stuck?

[Ezriveal]

Hey all,

I wanted to bring this up again because I think it's becoming more urgent.
Right now, Browser Docks (Custom Browser Docks, Service Integration, chat
overlays, etc.) are disabled on Linux whenever you're running Wayland.
Browser Sources still work fine, it's specifically the docks/panels that
get blocked (this goes back to obsproject/obs-browser#284, due to a
CEF/Wayland compatibility issue at the time).

The thing is, Wayland isn't really "the alternative" anymore, it's fast
becoming the only option. GNOME 50 is dropping the X11 session outright,
and a bunch of other DEs and distros have already gone Wayland-only by
default. So for a lot of us, the only way to get docks working at all is
forcing XWayland with QT_QPA_PLATFORM=xcb, which feels more like a hack
than something we should have to rely on, especially once X11 support
starts disappearing for real.

What's got me hopeful is that this isn't necessarily as broken as it
seems. There's a report (#9369) where someone just
reverted the commit that disabled docks and launched OBS through
XWayland, and it worked. That makes me think the current block might be
more conservative than it needs to be, rather than docks being
fundamentally impossible under Wayland right now.

I saw the CEF/browser roadmap thread (#3853) tracks
CEF version bumps, but I couldn't tell from it where things actually
stand on native Wayland dock support specifically.

So a few things I'd love to hear from the maintainers or anyone with more
context on:

• Is this still blocked purely on upstream CEF, or is there OBS-side work
  that could unblock it sooner?
• Would it make sense to officially support the XWayland route as a
  documented fallback, instead of leaving it as something users have to
  discover on forums, at least until CEF has proper native Wayland support?
• Given how fast X11 is getting phased out, is this something that could
  get bumped up in priority?

Happy to test builds, pull logs, whatever's useful. Just don't want this
to become one of those things that quietly turns into a bigger problem
once X11 isn't around as a fallback anymore.

[mihawk90]

• Is this still blocked purely on upstream CEF

Yes this is still blocked. Give #3853 a read.

• Would it make sense to officially support the XWayland route as a documented fallback

No, because it leads to unpredictable behaviour and issues. Just because it works for some users doesn't make it a generally viable solution. Users are free to run it, but if there are issues don't be surprised to be asked to test without it.

• Given how fast X11 is getting phased out, is this something that could get bumped up in priority?

There is nothing for OBS to prioritise because it's not in OBS' hands.

---

Side note on this point:

which feels more like a hack than something we should have to rely on, especially once X11 support starts disappearing for real.

XWayland isn't going anywhere anytime soon. X11 session support has nothing to do with XWayland support. Just because the sessions are going away doesn't mean XWayland will. XWayland is a new(ish) implementation of an X server on top of Wayland specifically to be able to drop X session support while retaining application compatibility.

There's a report (#9369) where someone just reverted the commit that disabled docks and launched OBS through XWayland, and it worked.

This report made no sense at the time, see also the comments. As you noted yourself, running on top of XWayland is possible without reverting the commit. The commit this is reverting only has an effect when run natively under Wayland. When you're forcing XWayland, that codepath is never reached.
And besides that, reverting that commit alone doesn't do anything because they didn't update the submodule for OBS, so their revert is never pulled.

[WizardCM]

Is this still blocked purely on upstream CEF, or is there OBS-side work that could unblock it sooner?

This is primarily blocked on the Chromium/CEF end, yes. See chromiumembedded/cef#2804 (comment) - there's practically nothing we can do until then

Secondarily, once we've merged updated Chromium support (hopefully for OBS 33.0), I will begin work on integrating the Views framework, which will likely be a requirement for CEF Wayland functionality from the above link. A quick summary can be found here WizardCM/obs-browser@1706e9f . I will fully document the work required here in an OBS Browser Plans update after we merge (and/or release) updated CEF.

Eventually, once we have Views framework and CEF has proper Wayland support, we will have to integrate. We currently have no idea what that will look like.

Would it make sense to officially support the XWayland route

Based on my limited understanding, XWayland is likely not built for the complexity involved in embedded CEF windows. It may work, it may cause issues we don't have any bandwidth to deal with. Per past discussions, XWayland breaks screen capture capabilities in various ways, and is incompatible with Nvidia hardware.

is this something that could get bumped up in priority?

Nothing we can do on that front, it's up to people who know their way around Chromium's and CEF's code.