Intent to Implement and Ship: Promise-based getUserMedia()

[Harald Alvestrand]

Contact emails

h...@google.com

Spec

http://w3c.github.io/mediacapture-main/getusermedia.html#idl-def-MediaStream

This spec has currently passed W3C Last Call and is being prepared for CR publication once Last Call comments have been addressed.

Summary

Add the promise-based getUserMedia() function, as specified

(in addition to the current callback-based one).

Motivation

There's consensus that this is the more attractive way of getting this functionality.

(There is no such consensus to remove the previous one.)

Compatibility Risk

Low. Firefox and Edge aldready do this.

We already support shimming this in adapter.js.

The basic functionality is already available and well tested.

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://code.google.com/p/chromium/issues/detail?id=503227

Link to entry on the feature dashboard

Don't think it needs one.

Requesting approval to ship?

Yes.

[PhistucK]

The specification link directs to a different part of the specification.

Did you intend to link to this one?

http://w3c.github.io/mediacapture-main/getusermedia.html#mediadevices-interface-extensions

So this is going to be a Promise based navigator.mediaDevices.getUserMedia(...) and navigator.webkitGetUserMedia(...) will stay intact (until it is deprecated and removed). Right?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Harald Alvestrand]

Yes, you're right (both the link and my intent).

[TAMURA, Kent]

LGTM.

--

TAMURA Kent
Software Engineer, Google

[Alex Russell]

Glad to see this change! Can't LGTM it, but would if I could = )

[Philip Jägenstedt]

The API owners met to discuss this yesterday. How does this relate to the previous intent? I take it this intent covers only adding the navigator.mediaDevices.getUserMedia() method, and not involving Blink-in-JS?

Since the existing method is navigator.webkitGetUserMedia() and isn't promise-based, it sounds like we'll have to wait until virtually all WebRTC code in the wild has been converted to the new API, making it pretty hard to remove the prefixed API. I don't have a solution for this, but we should add a use counter for navigator.webkitGetUserMedia() and then deprecate it unless usage is already hopelessly high.

[Alex Russell]

As with nearly all transitions of legacy APIs to be promise-based, this isn't as hard as it looks: the API can continue to support callbacks as positional parameters while also returning a Promise which can be used to register additional handlers.

It's the first time I've ever been grateful that WebIDL encourages void return values ;-)

[Harald Alvestrand]

The nice thing about this particular API is that it is an *additional* API, not a change to an API. There's no technical issue with supporting both at the same time (apart from API clutter).

Formalistically, the previous intent was for the WebRTC PeerConnection object's overloaded functions (which expose a couple of interesting issues); this one is strictly for the Navigator.mediaDevices.getUserMedia function (which does not change the navigator.getUserMedia function at all).

On Wed, Jun 24, 2015 at 10:12 AM, Philip Jägenstedt <phi...@opera.com> wrote:

The API owners met to discuss this yesterday. How does this relate to the previous intent? I take it this intent covers only adding the navigator.mediaDevices.getUserMedia() method, and not involving Blink-in-JS?

Since the existing method is navigator.webkitGetUserMedia() and isn't promise-based, it sounds like we'll have to wait until virtually all WebRTC code in the wild has been converted to the new API, making it pretty hard to remove the prefixed API.

I don't understand this comment.... we'll have to use-count the prefixed API, naturally. For full conformance, we should also support the non-prefixed old API, since this is specified in the standard (and use-count that).

A huge number of the code in the wild is using the "getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia" pattern, so if we implement the old API unprefixed, the use count for webkitGetUserMedia should drop pretty fast.

(The ones that use our webrtc/adapter solution will actually use the promise-based function for clients that call our helper function that shims promises if they aren't in the platform.)

But only measurement will show what happens.

 

I don't have a solution for this, but we should add a use counter for navigator.webkitGetUserMedia() and then deprecate it unless usage is already hopelessly high.

There is already an use-counter on navigator.webkitGetUserMedia(). I'll note that we need an use counter for navigator.mediaDevices.getUserMedia too.

(Note: The reason for the timing of the intent-to-implement is that as part of figuring out whether to use blink-in-JS, v8-extra or just C++ code, I implemented this particular function in C++, and it worked. It would be nice to get this code submitted before I go on vacation, so that it's in the codebase.)

[Philip Jägenstedt]

Thanks for clarifying, obviously LGTM2 to implement and ship navigator.mediaDevices.getUserMedia(). More inline:

On Wed, Jun 24, 2015 at 10:36 AM, Harald Alvestrand <h...@google.com> wrote:

The nice thing about this particular API is that it is an *additional* API, not a change to an API. There's no technical issue with supporting both at the same time (apart from API clutter).

Formalistically, the previous intent was for the WebRTC PeerConnection object's overloaded functions (which expose a couple of interesting issues); this one is strictly for the Navigator.mediaDevices.getUserMedia function (which does not change the navigator.getUserMedia function at all).

On Wed, Jun 24, 2015 at 10:12 AM, Philip Jägenstedt <phi...@opera.com> wrote:

The API owners met to discuss this yesterday. How does this relate to the previous intent? I take it this intent covers only adding the navigator.mediaDevices.getUserMedia() method, and not involving Blink-in-JS?

Since the existing method is navigator.webkitGetUserMedia() and isn't promise-based, it sounds like we'll have to wait until virtually all WebRTC code in the wild has been converted to the new API, making it pretty hard to remove the prefixed API.

I don't understand this comment.... we'll have to use-count the prefixed API, naturally. For full conformance, we should also support the non-prefixed old API, since this is specified in the standard (and use-count that).

A huge number of the code in the wild is using the "getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia" pattern, so if we implement the old API unprefixed, the use count for webkitGetUserMedia should drop pretty fast.

(The ones that use our webrtc/adapter solution will actually use the promise-based function for clients that call our helper function that shims promises if they aren't in the platform.)

But only measurement will show what happens.

I just meant that because this API is different from the current prefixed one, existing promise-unaware code like "getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia" will still use the prefixed API, making the road to removal longer than in some cases where the prefixed and unprefixed APIs are identical.

Whether it makes sense to also support the unprefixed navigator.getUserMedia() I suppose depends on what the usage of the prefixed API turns out to be after this ships.

I don't have a solution for this, but we should add a use counter for navigator.webkitGetUserMedia() and then deprecate it unless usage is already hopelessly high.

There is already an use-counter on navigator.webkitGetUserMedia(). I'll note that we need an use counter for navigator.mediaDevices.getUserMedia too.

(Note: The reason for the timing of the intent-to-implement is that as part of figuring out whether to use blink-in-JS, v8-extra or just C++ code, I implemented this particular function in C++, and it worked. It would be nice to get this code submitted before I go on vacation, so that it's in the codebase.)

Oh, right you are:

https://www.chromestatus.com/metrics/feature/timeline/popularity/666

https://www.chromestatus.com/metrics/feature/timeline/popularity/667

(I just looked for [Measure] or [MeasureAs] in the IDL file.)

Philip 

[Boris Zbarsky]

On 6/24/15 1:22 AM, 'Alex Russell' via blink-dev wrote:
> As with nearly all transitions of legacy APIs to be promise-based, this
> isn't as hard as it looks: the API can continue to support callbacks as

> positional parameters while /also/ returning a Promise which can be used
> to register additional handlers.

This last part is unclear. In Gecko, I think the returned promise is
simply ignored if the callback positional arguments are passed in (as
in, it's never resolved or rejected in that case). Of course in a sane
world the spec would actually define the behavior here one way or another...

-Boris

[Dimitri Glazkov]

LGTM3

:DG<

[Guido]

This feature has been put back behind a flag due to some regressions caused by getUserMedia() not supporting a new style of constraints according to spec. See crbug.com/511082.

We will try to ship again once support for constraints is complete.