Support unprefixed navigator.getUserMedia()
Categories
(Core :: WebRTC: Audio/Video, task, P3)
Tracking
()
People
(Reporter: foolip, Unassigned, NeedInfo)
References
Details
(Keywords: site-compat)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36
Steps to reproduce:
Try using navigator.getUserMedia({audio:true}).
Actual results:
The method is not implemented, so an exception is thrown.
Expected results:
https://bugzilla.mozilla.org/show_bug.cgi?id=729522 is marked as fixed, but only mozGetUserMedia is supported. The unprefixed variant should also be there. Only 3 arguments though:
https://w3c.github.io/mediacapture-main/getusermedia.html#navigatorusermedia-interface-extensions
|
||
Comment 1•8 years ago
|
||
Afaik we have no plans to unprefix this legacy API. I draw this conclusion from the fact that we unprefixed all WebRTC methods in Firefox 44, except this one. Our thinking then was that it doesn't make sense to introduce NEW legacy apis, and we wanted instead to drive convergence around navigator.mediaDevices.getUserMedia.
|
|
||
Updated•8 years ago
|
|
Reporter | |
Comment 2•8 years ago
|
||
It is in the spec, if you have no plans to support it can you raise a spec issue to figure out a path to interop here?
|
|
||
Comment 3•8 years ago
|
||
OK I've filed https://github.com/w3c/mediacapture-main/issues/368. Note that there is no *legacy* interop issue here. The only issue would be people writing *new* code only using this new legacy API, forgoing the interop dance: navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia;
| Comment hidden (obsolete) |
|
|
||
Comment 5•5 years ago
|
||
We finally have proper use counters—that count pageloads—for
Even though these are overall miniscule numbers, they suggest a solid 21% of all gUM calls are still callback based, which is sad. This isn't even accounting for people failing to do the prefix dance in comment 3.
Caveat: we still only have beta numbers, not release numbers, and there's a suspicion a number of gUM calls may be from fingerprinting libraries, which tend to favor old APIs for broadest impact.
But at some point, instead of moving people to use the navigator.mediaDevices.getUserMedia promise version, our approach here may actually entrench people to stick with prefixes—or confuse them about their necessity—hindering bug 1531812.
I see two ways to read these numbers:
- 21% is high enough that we should bite the bullet and implement the callback-based
navigator.getUserMedialike the spec says. - 0.003% is low enough that we could simply remove
navigator.mozGetUserMediaand suffer the consequences.
The only reason to take option 2 would be to take a web compat hit in hopes of forcing people to switch to using promises. A noble action, though perhaps not an effective one. A product decision perhaps?
|
||
Updated•5 years ago
|
|
|
||
Comment 6•5 years ago
|
||
Actually, there are more reasons to support 2:
- We have company: Safari does not support
navigator.getUserMediaeither. - It's listed under Legacy Interface Extensions with a note saying "there is ongoing discussion as to a) whether it still belongs in the specification", and I can't find a wpt test for it.
|
|
||
Comment 7•5 years ago
|
||
Given comment 6, which I had forgotten, I'm going to reverse myself and suggest we keep an eye on this for a while longer.
The navigator.mozGetUserMedia number may drop further once bug 1528031 lands, since it removes navigator.mozGetUserMedia in http (trading 68's NotAllowedError for TypeError on http access, i.e. no longer triggering telemetry.)
Just leaving a record that I had this conversation with myself. 😉
|
|
||
Comment 8•5 years ago
|
||
Unfortunately, the navigator.mozGetUserMedia insecure use counter is not showing up in the UX, so we don't know what that drop will be. The underlying telemetry seems missing. Nico, any idea why this might be?
|
|
||
Updated•5 years ago
|
|
||
Comment 9•5 years ago
|
||
jib, nico, please followup on this when you have time. I see there is the site-compat keyword, but I don't know if this is really a compat issue.
|
|
||
Comment 10•5 years ago
|
||
See bug 1609254.
Description
•