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)
Tracking
()
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.
Comment 2•8 years ago
|
||
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.
Updated•8 years ago
|
Summary: getUserMedia({video: {mediaSource: "browser"}}) only works with privileged code. → getUserMedia({video: {mediaSource: "browser"}}) only works from privileged code.
Reporter | ||
Comment 3•8 years ago
|
||
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
Reporter | ||
Comment 4•8 years ago
|
||
Can a WebExtension be "privileged code"? I have had no success so far.
Comment 5•8 years ago
|
||
Dunno. AFAIK this has only been used by Firefox Hello, which is now removed.
Flags: needinfo?(jib)
Comment 6•8 years ago
|
||
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.
Comment 7•7 years ago
|
||
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•