1811341 - Display capture under Wayland causes double system prompting for permissions

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P1)

Description

[Nico Grunbaum [:ng, @chew:mozilla.org]]

We need to restore the behavior in which the gUM/gDM dialog prompts the user, asking if they want to select a surface to share from the system dialog.

As it is the user gets prompted by the system dialog twice: once for generating the thumbnail preview of the screen in the prompt, and once again after clicking allow.

This is annoying, confusing, and the user can select different surfaces in each prompt.

Comment 1

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug 1811341 - restore OS picker behavior under wayland for gUM;r=jib!,mjf!

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9076240166d0
restore OS picker behavior under wayland for gUM;r=jib,mjf

Comment 3

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/9076240166d0

Comment 4

[Jan Grulich]

Attachment: Bug 1811341 - fix OS picker behavior under Wayland and missing cursor

Recent WebRTC upstream changed the way xdg-desktop-portal calls are made
and while previously it always asked for both screens and windows in one
call, now it's being made separate. This resulted into making just call
requesting screens and there was no way to share an application window.
For that reason a new API addition is needed on top of WebRTC desktop
capture API. Also make use of MouseCursorMonitorPipeWire on Linux, as
with recent WebRTC the mouse cursor is no longer embedded and is sent
using PipeWire stream metadata. We also need to make sure when there is
MediaDevice that will request OS prompt, make it checked as first.

Comment 5

[Jan Grulich]

Attachment: Bug 1811341 - fix OS picker behavior under Wayland

Recent WebRTC backports and changes that are about to be backported from
upstream to Firefox breaks and will break how we work with PipWire based
desktop capturer. Currently when constructing device list, a fallback to
ScreenCapturerX11 is used, as we don't call set_allow_pipewire(), which
wouldn't make a difference anyway. In such case the only thing we need
is a placeholder for a screen that will request OS level prompt. We also
need a way to request both screens and windows in one xdg-desktop-portal
call as recent WebRTC made each type be called separately, therefore the
introduction of GenericCapturer. Lastly we need to make sure when there
is a MediaDevice requesting the OS prompt, that it will be checked as
first.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Comment 7

[Nico Grunbaum [:ng, @chew:mozilla.org]]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #6)

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Thanks bot. I am opening a new bug as clone of this bug to attach the new work to.

Comment 8

[Phabricator Automation]

Comment on attachment 9317326 [details]
Bug 1811341 - fix OS picker behavior under Wayland

Revision D169627 was moved to bug 1817263. Setting attachment 9317326 [details] to obsolete.