getDisplayMedia cannot succeed in Private Browsing or inside of cross-origin iframe  
    Categories
(Core :: WebRTC: Audio/Video, defect, P1)
Tracking
()
| 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)
| 47 bytes,
          text/x-phabricator-request         | pascalc
:
              
              approval-mozilla-beta+ lizzard
:
              
              approval-mozilla-release+ | Details | Review | 
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:
- 
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');});
- 
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. 
- 
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•6 years ago
          • | ||
[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):
- Open https://jan-ivar.github.io/dummy/iframe_gdm_cross.html
- Click [Screen] button.
- Pick a window or screen in the screen-sharing prompt.
STR (private browsing):
- Open https://jan-ivar.github.io/dummy/gdm.html
- 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
| Updated•6 years ago
           | 
| Comment 2•6 years ago
           | ||
An earlier version of comment 1 misstated this does not happen in nightly. It does.
| Assignee | ||
| Updated•6 years ago
           | 
|   | ||
| Comment 3•6 years ago
           | ||
New regression in 70, tracking for now, maybe we can find a solution for a 70 dot release.
|   | ||
| Comment 4•6 years ago
           | ||
How common do you think this is for users to encounter, outside of private browsing?
| Comment 5•6 years ago
          • | ||
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?
| Updated•6 years ago
           | 
| Assignee | ||
| Comment 7•6 years ago
           | ||
| Updated•6 years ago
           | 
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 10•6 years ago
           | ||
| bugherder | ||
| Assignee | ||
| Comment 11•6 years ago
           | ||
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
| Assignee | ||
| Updated•6 years ago
           | 
| Comment 12•6 years ago
           | ||
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•6 years ago
          • | ||
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•6 years ago
           | ||
| bugherder uplift | ||
|   | ||
| Comment 15•6 years ago
           | ||
From talking with :jib sounds like Meet/Hangouts is also impacted. Let's go ahead and take this for 70.1.
|   | ||
| Comment 16•6 years ago
           | ||
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•6 years ago
           | ||
Verified - fixed on latest Beta 71.0b5 (Build id: 20191028110005) on Mac OS 10.14 , Windows 10 and Ubuntu 18.04
| Updated•6 years ago
           | 
| Comment 18•6 years ago
           | ||
Could somebody please help me to find out information about release date for version 70.1?
| Updated•6 years ago
           | 
|   | ||
| Comment 19•6 years ago
           | ||
| bugherder uplift | ||
| Comment 20•6 years ago
           | ||
Verified - fixed on Release 70.0.1 (Build id: 20191029161003) on Mac OS 10.14 , Windows 10 and Ubuntu 18.04
| Updated•3 years ago
           | 
Description
•