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

Steps to reproduce:

1. Go to google meet
2. Click on "present now" > "window"

Actual results:

This is a regression on FF 84. Worked correctly on FF <= 83 when running Firefox in native wayland mode.

No windows are shown on the selector for screen sharing under Sway. Before, all Xwayland windows were available to share. From FF 84, only an empty option with no text and "entire screen" are on that list.

Expected results:

All Xwayland windows are selectable.

Just to clarify, I realise proper screen sharing in Wayland is not yet entirely functional and requires pipewire and all sorts of things that aren't quite aligning properly yet. This bug report is not about that.

This refers to Firefox not offering any non wayland window to screen share, which worked fine when running Firefox with the wayland backend on versions 83 and earlier.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Firefox 84.0.2 (64-bit)

Me too.

Using GNOME in Debian 10 (under Wayland) previously to the early December 2020 release (presumably Firefox 83) I was able to share Firefox and XWayland Windows when using WebRTC apps such as Google Meet, Jitsi Meet, etc. This now no longer works. When attempting to screen share, the dialog box that normally prompts the window to share consists of a blank menu item and "Entire screen". Neither of these have any effect when selected.

I'm afraid this is a wont-fix, sorry. Making use of X11 is an explicit anti-goal for the Wayland backend. Screen sharing on Wayland is supposed to work via the appropriate APIs, in this case xdg-desktop-portal[1] with it's respective backends xdg-desktop-portal-gtk[2] or xdg-desktop-portal-wlr[3].

(In reply to luis.pabon from comment #1)

Just to clarify, I realise proper screen sharing in Wayland is not yet entirely functional and requires pipewire and all sorts of things that aren't quite aligning properly yet. This bug report is not about that.

This refers to Firefox not offering any non wayland window to screen share, which worked fine when running Firefox with the wayland backend on versions 83 and earlier.

The fact that not all DEs (or older versions, in case of Buster) are ready for that is one reason (among others of course) why the Wayland backend is still experimental. We do not plan to support such backward compatibility, partly because we miss the people-power to do so.

TL;DR: please use Xwayland if your DE does not (yet) support the required features for the Wayland backend. Sorry :(

P.S.: if you have some time left, I'm sure wlroots devs would appreciate some helping hands for their portal work :)

1: https://github.com/flatpak/xdg-desktop-portal
2: https://github.com/flatpak/xdg-desktop-portal-gtk
3: https://github.com/emersion/xdg-desktop-portal-wlr

I understand the reasoning, but unfortunately this means screen sharing is now completely broken under Wayland on Ubuntu 20.04. It won't be adding in pipewire until 21.04. Isn't there anything that can be done at all?

I don't know how to force it to use Xwayland, or that doesn't work as a workaround.

I tried running "GDK_BACKEND=x11 firefox" but I still cannot share any windows. Same with "MOZ_ENABLE_WAYLAND=0 firefox".

(In reply to luis.pabon from comment #5)

I understand the reasoning, but unfortunately this means screen sharing is now completely broken under Wayland on Ubuntu 20.04. It won't be adding in pipewire until 21.04. Isn't there anything that can be done at all?

Hm, IIUC it should be available in 20.04[1] - and I hope the API stayed compatible, not exactly sure. Can you try? Otherwise it would work at least from 20.10 on. Ubuntu doesn't support Wayland officially yet, so well, Ubuntu LTS it probably the wrong distro to run experimental tech on without expecting some breakage :(

I don't know how to force it to use Xwayland, or that doesn't work as a workaround.
I tried running "GDK_BACKEND=x11 firefox" but I still cannot share any windows. Same with "MOZ_ENABLE_WAYLAND=0 firefox".

The Wayland backend is not used by default yet (apart from Fedora+Gnome) - so actually you shouldn't be using it if you don't set any env variables explicitely. You can also unset it via MOZ_ENABLE_WAYLAND= firefox

Can you check the Window Protocol field in about:support? If you are on Xwayland and it still doesn't work - then we have a different bug that we definitely should fix :)
While on it, it would be great if you could also check nighly - it might be fixed already.

1: https://packages.ubuntu.com/search?suite=focal&searchon=names&keywords=pipewire

Linux 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
Version 84.0.2
Build ID 20210105180113
Window Protocol wayland
Desktop Environment gnome

"MOZ_ENABLE_WAYLAND= ./firefox" still comes up as Wayland.

(In reply to Peter from comment #8)

Linux 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
Version 84.0.2
Build ID 20210105180113
Window Protocol wayland
Desktop Environment gnome

"MOZ_ENABLE_WAYLAND= ./firefox" still comes up as Wayland.

You need to unset MOZ_ENABLE_WAYLAND to run Firefox in X11 mode. See Bug 1588129.

I think we can provide a pref value to force enable/disable pipewire.

Thank you for that, that would absolutely hit the spot 👍

(In reply to Martin Stránský [:stransky] from comment #9)

(In reply to Peter from comment #8)

Linux 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
Version 84.0.2
Build ID 20210105180113
Window Protocol wayland
Desktop Environment gnome

"MOZ_ENABLE_WAYLAND= ./firefox" still comes up as Wayland.

You need to unset MOZ_ENABLE_WAYLAND to run Firefox in X11 mode. See Bug 1588129.

That doesn't actually work. If I run it without MOZ_ENABLE_WAYLAND defined, it starts under wayland. If I run it with MOZ_ENABLE_WAYLAND blank, it starts under wayland. If I run it with MOZ_ENABLE_WAYLAND=0 it starts under wayland.

The proposed MOZ_DISABLE_PIPEWIRE patch looks promising, I assume that means it falls back on X11 capture?

(In reply to Peter from comment #13)

(In reply to Martin Stránský [:stransky] from comment #9)

(In reply to Peter from comment #8)

Linux 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
Version 84.0.2
Build ID 20210105180113
Window Protocol wayland
Desktop Environment gnome

"MOZ_ENABLE_WAYLAND= ./firefox" still comes up as Wayland.

You need to unset MOZ_ENABLE_WAYLAND to run Firefox in X11 mode. See Bug 1588129.

That doesn't actually work. If I run it without MOZ_ENABLE_WAYLAND defined, it starts under wayland. If I run it with MOZ_ENABLE_WAYLAND blank, it starts under wayland. If I run it with MOZ_ENABLE_WAYLAND=0 it starts under wayland.

Please try upstream nightly or upstream release binary which uses X11 by default. Maybe your distro sets MOZ_ENABLE_WAYLAND in Firefox launch script so you can't remove it from command line.

The proposed MOZ_DISABLE_PIPEWIRE patch looks promising, I assume that means it falls back on X11 capture?

MOZ_DISABLE_PIPEWIRE is useful on XWayland only, i.e. Firefox is running on X11 in Wayland environment.

We also need that for testing, when we test Firefox in X11 mode while Wayland session is active.

Hello there, any news getting MOZ_DISABLE_PIPEWIRE to work?

We need to remove the FF sharing dialog entirely when portal is used and utilize only the system one. There's no point to ask user twice for the same thing.

That would be great actually, when using sway and xdg-desktop-portal-wlr there's already a selection mechanism. The current status quo of having to select "operating system settings" on the dialog is confusing and cumbersome. Skipping that would be amazing.

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

We need to remove the FF sharing dialog entirely when portal is used and utilize only the system one. There's no point to ask user twice for the same thing.

I think I disagree here. The system dialog is usually way more intrusive and can not as easily provide context about e.g. which concrete Website is asking for it. With bug 1728749 landed today, the workflow just got less cumbersome, requiring only one click to start the system dialog instead of three - that's equivalent to clicking on the selector dropdown. So IMO we should keep that one.

(In reply to Robert Mader [:rmader] from comment #20)

I think I disagree here. The system dialog is usually way more intrusive and can not as easily provide context about e.g. which concrete Website is asking for it. With bug 1728749 landed today, the workflow just got less cumbersome, requiring only one click to start the system dialog instead of three - that's equivalent to clicking on the selector dropdown. So IMO we should keep that one.

I mean to remove the firefox dialog (which was polished by Bug 1728749). It doesn't add any value - you need to allow sharing there and then you need to allow it (or disable) again in the XDG portal sharing dialog.

But we need to report disabled sharing (from XDG portal) back to Firefox to update UI about that.

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

I mean to remove the firefox dialog (which was polished by Bug 1728749). It doesn't add any value - you need to allow sharing there and then you need to allow it (or disable) again in the XDG portal sharing dialog.

Yes I understand, but I currently see one major issue here: the portal currently does not provide extra context about which website asks for sharing permission. AFAIK, currently any open tab (or even embedded frame?) could ask for this permission at any time, and there would be no way for a user to guess that it's not the website in focus which did this. So the existing Firefox dialog IMO does provide value here, by making sure no malicious website tricks a user into sharing their screen unintentionally (note: the Firefox dialog explicitly states from which source the request comes).

If the portal gets extended to provide such extra information, than we could maybe remove the Firefox dialog, but IMO not before that. (I'm not sure if such a changed would get accepted though - I see a good chance that this is seen as application business).

Okay, fair enough.

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

Okay, fair enough.

Oh, and there's another feature of the Firefox dialog which the system portal can't easily provide: "Always block" - on a website base. The system dialog could probably also provide a "Always block" option - but only for the whole app, not a website. So well, I think we'll have to live with a two-dialog system.
We could consider something like a "Always allow" or "Remember" option, which would directly spawn the system dialog when previously allowed on that site.

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Screen sharing works well with pipewire now and this bug is no longer relevant.