Open Bug 1297987 Opened 8 years ago Updated 2 years ago

getUserMedia({video: {mediaSource: "browser"}}) only works from privileged code.

Categories

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

48 Branch
defect

Tracking

()

Tracking Status
firefox48 --- affected
firefox49 --- affected
firefox50 --- affected
firefox51 --- affected

People

(Reporter: pehrsons, Unassigned)

References

Details

To reproduce: 1. Go to a URL that is in the screensharing whitelist (media.getusermedia.screensharing.allowed_domains), e.g., mozilla.github.io in Firefox 51 2. Open the devtools console 3. Enter `p = navigator.mediaDevices.getUserMedia({video: {mediaSource: "browser"}}).then(s => console.info(s)).catch(e => console.error(e))` Expected result: A chrome dialog the lets you select which tab to share Actual result: A chrome dialog asking you to select a screen but with an empty list 4. Click "Share selected items" Expected result: The gUM call resolving with a MediaStream Actual result: The gUM doesn't resolve or reject, and the dialog is gone. No user action can let the page recover from this state.
jib, do you have clues here?
Rank: 25
Flags: needinfo?(jib)
We don't have a dialog for a choosing tab, never did. The "browser" constraint is only aimed at privileged code like Firefox Hello atm, which also has access to outer window ids to pass into the browserWindow constraint used to select tab (Firefox Hello always followed the active tab). The browserWindow constraint defaults to the current tab, so you can see the underlying code working here https://jsfiddle.net/uax4gom5/ provided you set media.navigator.permission.disabled=true first.
Flags: needinfo?(jib)
Summary: getUserMedia({video: {mediaSource: "browser"}}) is broken → getUserMedia({video: {mediaSource: "browser"}}) only works with privileged code.
Summary: getUserMedia({video: {mediaSource: "browser"}}) only works with privileged code. → getUserMedia({video: {mediaSource: "browser"}}) only works from privileged code.
How easily can we make these gUM requests be rejected when we know they aren't gonna work? Seems expected from a user point of view. Degrading since this was never supported.
Rank: 25 → 35
Flags: needinfo?(jib)
Priority: P2 → P3
Can a WebExtension be "privileged code"? I have had no success so far.
Dunno. AFAIK this has only been used by Firefox Hello, which is now removed.
Flags: needinfo?(jib)
And Firefox Hello had special excemption to be treated as "privileged" in MediaManager. (In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #3) > How easily can we make these gUM requests be rejected when we know they > aren't gonna work? Seems expected from a user point of view. It's already rejected with NotAllowedError in the typical case, that is, without your domain added to media.getusermedia.screensharing.allowed_domains. It used to be that you needed *both* your domain in allowed_domains *and* set media.navigator.permission.disabled=true, but we changed that a while back, I think for testing reasons, but I could be wrong about the reason. We should probably change that back before the whitelist disappears.
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.