Intent to implement and ship: Unprefixed getUserMedia

[Harald Alvestrand]

Contact emails

h...@chromium.org, to...@chromium.org

Spec

https://w3c.github.io/mediacapture-main/getusermedia.html#local-content

Summary

Ship unprefixed versions of the long-established webkitGetUserMedia function, and

add the new promise-based navigator.mediaDevices.getUserMedia interface.

Motivation

This API shipped with a prefix, and an incompatible "constraints" parameter.

The "constraints" parameter is now updated to standards compliance.

Interoperability and Compatibility Risk

Low. The interface already ships in Firefox.

Much of the Web uses tools (getUserMedia = navigator.getUserMedia | navigator.webkitGetUserMedia) that will make the change invisible to them.

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

OWP launch tracking bug

https://crbug.com/607439

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5755699816562688

Requesting approval to ship?

Yes

[PhistucK]

On Fri, Jun 10, 2016 at 1:07 PM, 'Harald Alvestrand' via blink-dev <blin...@chromium.org> wrote:

Low. The interface already ships in Firefox.

​And in Edge, right?

https://developer.microsoft.com/en-us/microsoft-edge/platform/documentation/apireference/interfaces/MediaDevices/​

☆PhistucK

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Harald Alvestrand]

Note that the promise-based getUserMedia was the subject of an intent-to-ship thread a year ago:

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/qUOfAge9qnk

This time, we're shipping both versions (and with the new constraints).

[Philip Jägenstedt]

In some ad-hoc testing and reading of IDL files I found:

Gecko supports navigator.mediaDevices.getUserMedia, but not navigator.getUserMedia. Also, navigator.mediaDevices.getUserMedia has an optional argument in Gecko, although if it is omitted it results in a promise rejected with "NotSupportedError: audio and/or video is required", so it's not a real issue.

Edge supports both navigator.mediaDevices.getUserMedia and navigator.getUserMedia. Somewhat odd is that passing no argument to navigator.mediaDevices.getUserMedia throws an exception instead of rejecting a promise. That's likely a general bindings bug and not specific to getUserMedia, though.

Desktop Safari doesn't seem to support any variant here, but navigator.mediaDevices.getUserMedia is in the WebKit source.

Is there any testing, ad-hoc or otherwise, on the interoperability of the new constraints dictionary?

[Philip Jägenstedt]

Sorry, I am forgetful. Rick reminded me that the constraints testing was already discussed in https://groups.google.com/a/chromium.org/d/msg/blink-dev/ANta5sQXoGA/G-NraQ32BAAJ

LGTM2, I will file issues on Gecko and Edge for the missing argument.

[Rick Byers]

LGTM3

[Philip Jägenstedt]

I have filed two Gecko bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=1279933

https://bugzilla.mozilla.org/show_bug.cgi?id=1279936

Harald, can you poke the appropriate person at Mozilla so that these end up in the right product/component?

I didn't file a bug for Edge yet.

Philip

[Boris Zbarsky]

On 6/13/16 4:33 PM, Philip Jägenstedt wrote:
> Also, navigator.mediaDevices.getUserMedia has an
> optional argument in Gecko

It has to, per Web IDL spec: dictionaries in trailing position that have
no required arguments must be optional arguments in terms of IDL
argument processing.

See https://heycam.github.io/webidl/#dfn-optional-argument-default-value
the paragraph after the "Warning" box.

If that's not what the spec says, it's a bug in the spec's IDL.

-Boris

[Harald Alvestrand]

There's a weakness in WebIDL in this area: The requirement on this dictionary is that one of the members MUST be present, but none of the members are themselves mandatory.

This results in a situation where TypeError is a correct response to an empty dictionary, but since it's not possible to make official WebIDL state that the dictionary can't be empty, we' have to raise the TypeError (by rejecting the promise) from C++ code, not from the WebIDL binding code when the "bug" allowing this behavior in the Chrome WebIDL compiler is fixed.

[Harald Alvestrand]

I've filed https://github.com/w3c/mediacapture-main/issues/366 on fixing the getusermedia spec.

I also filed https://github.com/heycam/webidl/issues/130 because in this particular (unusual) case, the WebIDL rule doesn't make sense.

[Boris Zbarsky]

On 6/14/16 8:04 AM, Harald Alvestrand wrote:
> There's a weakness in WebIDL in this area: The requirement on this
> dictionary is that one of the members MUST be present, but none of the
> members are themselves mandatory.

It's not a weakness. It's a conscious decision to prevent bad API
designs. See
https://github.com/heycam/webidl/issues/130#issuecomment-225856439 for
details.

> This results in a situation where TypeError is a correct response to an
> empty dictionary, but since it's not possible to make official WebIDL
> state that the dictionary can't be empty, we' have to raise the
> TypeError (by rejecting the promise) from C++ code

You need this anyway to handle `{ noSuchPropInThisDictionary: 1 }` being
passed in, yes?

That is, you (the mediacapture spec) have a complicated interdepency
requirement on the options provided in the options object, and
expressing that sort of interdependency explicitly in prose (aka browser
implementation code, not binding code) does not seem unreasonable.

-Boris

[Harald Alvestrand]

If webidl gave me a "this dictionary must not be empty" marker, I could express in syntax what is now expressed in prose.

A dictionary of {nonsense:1} is empty by webidl definitions.

[Philip Jägenstedt]

Unless some pretty elaborate annotations are added to WebIDL, passing in {audio: false, video: false} would still have to be handled in prose, right?

[Rick Byers]

How does this design affect forwards compatibility?  Eg. imagine in the future you want to add a new type of constraint, what would we want the behavior to be in browsers that didn't yet support that constraint for code which didn't explicitly feature detect for it?  I can see an argument for not throwing - just behaving as if none of the constraints could be satisfied.

[Boris Zbarsky]

On 6/14/16 12:52 PM, Harald Alvestrand wrote:
> If webidl gave me a "this dictionary must not be empty" marker, I could
> express in syntax what is now expressed in prose.

In this special case, that's true. And if you added one more member to
the dictionary, suddenly you could not.

If there appear more use cases with this exact constraint, we should
indeed consider adding it to IDL. But so far this is the only case
where it's come up (unlike "required" for a single attribute, which had
multiple specs asking for it, iirc).

-Boris

[Boris Zbarsky]

On 6/14/16 12:58 PM, Philip Jägenstedt wrote:
> Unless some pretty elaborate annotations are added to WebIDL, passing in
> {audio: false, video: false} would still have to be handled in prose, right?

Ah, good catch. Yes, it would. I forgot that in this case there are
possible values the members can take which in combination are still not
considered OK. So this is a much more complicated constraint from "both
members must be present"....

-Boris

[Philip Jägenstedt]

It turns out that there's some resistance to navigator.getUserMedia (the callback-based API):

https://github.com/w3c/mediacapture-main/issues/368

It seems implausible to me that navigator.webkitGetUserMedia can be removed, but it's not a given that we have to support navigator.getUserMedia. Given that Edge has already shipped navigator.getUserMedia I lean towards thinking that having both forever is probably the least bad outcome.

I hope that the relevant implementors will get together on the issue, but thoughts on how Blink should proceed?

[win...@gmail.com]

To reiterate it here, I would like to request that Blink not unprefix navigator.getUserMedia at this point in time, as it constitutes a new legacy api that is not needed for any true legacy support.

I recommend leaving it as navigator.webkitGetUserMedia and drive people to use the modern navigator.mediaDevices.getUserMedia (this matches what Firefox does i.e. navigator.mozGetUserMedia). Edge had no choice, but we do.

Typical legacy code:

 navigator.getUserMedia = navigator.getUserMedia ||
                          navigator.webkitGetUserMedia ||
                          navigator.mozGetUserMedia;

.: Jan-Ivar :.

[Harald Alvestrand]

Jan-Ivar,

I'd ask that you have some respect for the standardization process in which you've been a very active participant.

The W3C WG came to consensus to:

a) standardize both the promises version and the callback version of getUserMedia

b) NOT standardize the prefix version.

I'll also remind you that we heard strong voices raised by colleagues of yours in favor of retaining the callback version of getUserMedia in the specification - these people formed part of the consensus to retain.

The place to revisit this issue is not on a Blink intent-to-ship thread.

If you want to revisit what the standards discussion ended up doing, the right forum is the standards group.

I know that you know where to find it.

Harald

[Jan-Ivar Bruaroey]

Harald, I did raise it there. It was your colleague who brought it here. Sorry about the wrong forum and timing, but I agree with your colleague that once this reaches stable, that's pretty much it, so I was trying to buy time. In any case, following up in https://github.com/w3c/mediacapture-main/issues/368 rather than here is a good idea.

Sorry for the intrusion,

.: Jan-Ivar :.

--
.: Jan-Ivar :.

[Rick Byers]

FWIW I agree that blink implementation should proceed along whatever the consensus of the WG is here (as indicated by the spec).  It does seem concerning to be shipping a new "legacy" API, but today browser engineers and web developers will expect it to be there as spec'd (which is why even Philip's earlier realization that Firefox was missing this API didn't raise any concerns here).  If br

Of course if the WG can reach consensus quickly to change something here, we still have some time to update blink to match before compat concerns tie our hands.

There's a complex set of trade-offs and I appreciate Philip and Jan-Ivar raising the issue here (we don't generally follow specs when they disagree with implementations <grin>) - no harm done at all.  But in this case I agree with Harald that it's really a decision for the WG.  I'll follow (and perhaps chime in on) the discussion on the GitHub issue.

Thanks!

  Rick