1817263 - Display capture under Wayland should use a unified picker for any type of capture

Status: VERIFIED FIXED

(Core :: WebRTC, defect, P2)

Description

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

(From original bug)

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 1

[Jan Grulich]

Attachment: Bug 1817263 - 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.

In order to use unmodified libwebrtc, Firefox would need to rework the
OS picker to request each type (screens and windows) separately so we
can just use regular ScreenCapturer and WindowCapturer. This should be
done ideally the way Chromium does it, where users can actually see
even the preview of what they picked over xdg-desktop-portal before it
is actually shared with requesting web page and they also have option
to make the request again in case they picked a wrong window or screen.

Comment 2

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

Set release status flags based on info from the regressing bug 1811341

Comment 3

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

Once landed, I would like to nominate this for Beta uplift.

Comment 4

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

Try build: https://treeherder.mozilla.org/jobs?repo=try&revision=6fc742e0d8c3ad0175e5360bf3fc278ec2c55deb

Comment 6

[Byron Campen [:bwc]]

Is this a dupe of bug 1817446?

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/acd626664295
fix OS picker behavior under Wayland r=ng,jib,stransky

Comment 9

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/acd626664295

Comment 10

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

The patch landed in nightly and beta is affected.
:grulja, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox111 to wontfix.

For more information, please visit auto_nag documentation.

Comment 11

[Jan Grulich]

Beta/Release Uplift Approval Request

• User impact if declined: Users will not be able to share application windows, or potentially anything when XWayland is not running. Also they were hit by two xdg-desktop-portal dialogs, which is quite annoying issue.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Try to share a screen on Wayland. You should get presented with "Use operating system settings" option only in the picker and you should not see "Screen x" or anything else. Also upon confirmation you should get a dialog where you can share either a screen or a window, while previously only screens were possible and you shouldn't get the same dialog again once you pick something in the xdg-desktop-portal-dialog.
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This change introduces a slightly different behavior specifically for Wayland screen sharing when PipeWire is used and doesn't affect anything else.
• String changes made/needed: No

Comment 12

[Donal Meehan [:dmeehan]]

Comment on attachment 9318221 [details]
Bug 1817263 - fix OS picker behavior under Wayland

Adding approval request on the attachment so it appears in relman uplift queries
See Comment 11

Comment 13

[Donal Meehan [:dmeehan]]

Comment on attachment 9318221 [details]
Bug 1817263 - fix OS picker behavior under Wayland

Approved for 111.0b6

Comment 14

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/58403f4370c3

Comment 15

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I was able to reproduce the issue on Firefox 112.0a1 (2023-02-16) on Ubuntu 22.04 Wayland where multiple prompts were shown initially.

The issue is fixed on Firefox 111.0b6 and Firefox 112.0a1 (2023-02-26) and only one prompt is shown from Firefox then the xdg one and the screenshare starts. Tests were performed on the same Ubuntu 22.04 Wayland system.

Comment 17

[Jan Grulich]

Attachment: Bug 1817263 - update additional WebRTC desktop capturer API to upstream version r=jib

This was a change we introduced for Firefox and we didn't backport it to
WebRTC, however, it has been now requested also by Electron so this API
additon is now also part of WebRTC with just minor changes. This change
makes it on par with the WebRTC version so the next time we do WebRTC
rebase, we don't need to cherry-pick it and resolve conflicts.

WebRTC change: 0e9556a90cec52c2375c9250269f3abc21e8ca0c

Comment 18

[Michael Froman [:mjf]]

I just noticed the new patch here never landed. Does it need to be landed?

Comment 19

[Jan Grulich]

(In reply to Michael Froman [:mjf] from comment #18)

I just noticed the new patch here never landed. Does it need to be landed?

Yes, please.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5682fe537451
update additional WebRTC desktop capturer API to upstream version r=jib,webrtc-reviewers

Comment 21

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/5682fe537451