Closed Bug 1590479 Opened 1 year ago Closed 1 year ago

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

Categories

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

70 Branch
Unspecified
All
defect

Tracking

()

VERIFIED FIXED
mozilla72
Tracking Status
firefox-esr68 --- unaffected
firefox67 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 + verified
firefox71 + verified
firefox72 + verified

People

(Reporter: zachary.hittle, Assigned: johannh)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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'.

Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core

[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

Severity: normal → critical
Flags: needinfo?(jhofmann)
OS: Unspecified → All
Priority: -- → P1
Regressed by: 1580319
Status: UNCONFIRMED → NEW
Ever confirmed: true

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

Assignee: nobody → jhofmann
Status: NEW → ASSIGNED
Flags: needinfo?(jhofmann)

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

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

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?

Flags: needinfo?(drno)

Reached out to jitsi by email.

Flags: needinfo?(drno)

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!

Pushed by jhofmann@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c038deea18d6
Reset notification UI state for PopupNotifications doorhangers without checkbox. r=nhnt11
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

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
Attachment #9104150 - Flags: approval-mozilla-release?
Attachment #9104150 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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!

Attachment #9104150 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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

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

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.

Attachment #9104150 - Flags: approval-mozilla-release? → approval-mozilla-release+

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

QA Whiteboard: [qa-triaged]

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

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

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Duplicate of this bug: 1592695
You need to log in before you can comment on or make changes to this bug.