1590479 - getDisplayMedia cannot succeed in Private Browsing or inside of cross-origin iframe

Status: VERIFIED FIXED

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[zachary.hittle]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

Steps to reproduce:

1. Create a [child] document with javascript invoked upon user gesture:
   navigator.mediaDevices.getDisplayMedia({video: true}).then(stream => {console.log('got stream');}).catch(error => {console.log('error getting stream');});

2. Create a [parent] document with an iframe element that points to the document in step #1, where the 2 documents are served from different origins.

3. Request/Load the parent document in Firefox 70 and invoke the action in the child document that requests getDisplayMedia.

Additional Info:

• Both pages are being served via HTTPS.
• Setting the iframe attr allow = "display-capture *" or response header Feature-Policy = "display-capture *" with the following Firefox flags has no impact on this unexpected behavior (dom.security.featurePolicy.enabled | dom.security.featurePolicy.header.enabled)
• Issue can also be replicated without a cross-origin iframe -- just load the child page in Private Browsing mode.
• This appears to be a breaking change from FF69 -> FF70 (getDisplayMedia behaves as expected on FF69 w/ cross-origin iframe and Private Browsing mode).
• Invoking getUserMedia with audio or video will succeed, allowing the user to select 'Allow' for camera and/or microphone access.
• Disabling Enhanced Tracking Protection has no impact on this behavior.
• If the iframe is same-origin, it succeeds as expected.

Actual results:

User is presented the browser screen content chooser, can select an application or screen but CANNOT click 'Allow' (disabled). User can ONLY click 'Dont Allow'.

Expected results:

User is presented the browser screen content chooser, can select an application or screen and click 'Allow' or 'Dont Allow'.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

[Tracking Requested - why for this release]: Broke screen-sharing in cross-origin iframes. Broke screen-sharing in private-browsing mode.

This is a bug in the prompt where the [Allow] button is ghosted when it shouldn't be. Shows up in release, beta and nightly.

STR (cross-origin):

1. Open https://jan-ivar.github.io/dummy/iframe_gdm_cross.html
2. Click [Screen] button.
3. Pick a window or screen in the screen-sharing prompt.

STR (private browsing):

1. Open https://jan-ivar.github.io/dummy/gdm.html
2. Pick a window or screen in the screen-sharing prompt.

Expected result:

• [Allow] button is enabled and clickable. Clicking it shares the chosen window or screen.

Actual result:

• [Allow] button is disabled (not clickable). There is no way to enable the button or proceed.

Regression range:
12:49.61 INFO: Last good revision: 281a303a0616bf69a275432008e7b55205a6efc1
12:49.61 INFO: First bad revision: 09bdee778e59a390205a1d5f2e0926130d1d0966
12:49.61 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=281a303a0616bf69a275432008e7b55205a6efc1&tochange=09bdee778e59a390205a1d5f2e0926130d1d0966
-> Bug 1580319

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

An earlier version of comment 1 misstated this does not happen in nightly. It does.

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

New regression in 70, tracking for now, maybe we can find a solution for a 70 dot release.

Comment 4

[Liz Henry (:lizzard) (relman/hg->git project)]

How common do you think this is for users to encounter, outside of private browsing?

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

The only WebRTC site I know of that would screen-share cross-origin would be Jitsi, as I understand they have clients that iframe them. Those clients' users would be unable to present in conference calls using Firefox presumably. Unfortunately, I don't have a way to test this, since I'm not familiar with such a service, and their main site is not iframed and works fine (I just tested it). Nils, do we have a Jitsi contact who could verify if this is a problem?

Apart from that, my guess is cross-origin use is rare, but it's hard to say, because getDisplayMedia barely registers in telemetry pagecounts. On beta 69, our usecounters show ~3% of getDisplayMedia calls are cross-origin, though pagecount totals are probably too low to infer anything from: they put overall usage at 0.000016% when Chrome says 0.0005%. So something is off there. Do we do telemetry on release?

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Reached out to jitsi by email.

Comment 7

[Johann Hofmann [:johannh]]

Attachment: Bug 1590479 - Reset notification UI state for PopupNotifications doorhangers without checkbox. r=nhnt11,jib

Comment 8

[saghul]

Hi there, Jitsi dev here. Yes, we do encourage users to embed Jitsi on an iframe as we provide an API for it: https://github.com/jitsi/jitsi-meet/blob/master/doc/api.md

Our main site does not run on a cross-origin iframe and since we don't track users I can't provide a number of affected users, but here are some chat services that embed Jitsi using an iframe and would be affected: Matrix, Rocket.Chat and (possibly) Zulip. That's off the top of my head.

Thanks Jan-Ivar for the heads up!

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c038deea18d6
Reset notification UI state for PopupNotifications doorhangers without checkbox. r=nhnt11

Comment 10

[Natalia Csoregi [:nataliaCs]]

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

Comment 11

[Johann Hofmann [:johannh]]

Comment on attachment 9104150 [details]
Bug 1590479 - Reset notification UI state for PopupNotifications doorhangers without checkbox. r=nhnt11,jib

Beta/Release Uplift Approval Request

• User impact if declined: Can not use screen sharing through iframes or in private windows.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small patch that adds a previously forgotten call to a function that resets some popup notification UI. Modifying this code is known to have side-effects (this bug was caused by a similar "small patch") and it's a little hard to test "all the doorhangers", but generally we're well covered with tests and it looks like a very low-risk change.
• String changes made/needed: None

Comment 12

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9104150 [details]
Bug 1590479 - Reset notification UI state for PopupNotifications doorhangers without checkbox. r=nhnt11,jib

Fix for a tracked P1 regression, has tests and was verified on nightly, uplift approved for 71 beta 5, thanks!

Comment 13

[Alin Ilea, Desktop QA]

Reproduced the initial issue using an old Beta build: 20191021164841 and an old Nightly build: 20191022094606
Verified - fixed on latest Nightly 72.0a1 (2019-10-27) (Build id: 20191027212548) on Mac OS 10.14 , Windows 10 and Ubuntu 18.04

Comment 14

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/releases/mozilla-beta/rev/469d2fd39bd0

Comment 15

[Liz Henry (:lizzard) (relman/hg->git project)]

From talking with :jib sounds like Meet/Hangouts is also impacted. Let's go ahead and take this for 70.1.

Comment 16

[Liz Henry (:lizzard) (relman/hg->git project)]

Comment on attachment 9104150 [details]
Bug 1590479 - Reset notification UI state for PopupNotifications doorhangers without checkbox. r=nhnt11,jib

Fix for regression in 70, verified in nightly. OK for uplift to m-r.

Comment 17

[Alin Ilea, Desktop QA]

Verified - fixed on latest Beta 71.0b5 (Build id: 20191028110005) on Mac OS 10.14 , Windows 10 and Ubuntu 18.04

Comment 18

[Stanislav Bayrachniy]

Could somebody please help me to find out information about release date for version 70.1?

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-release/rev/7f1ff5b34df1

Comment 20

[Alin Ilea, Desktop QA]

Verified - fixed on Release 70.0.1 (Build id: 20191029161003) on Mac OS 10.14 , Windows 10 and Ubuntu 18.04