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

88 views
Skip to first unread message

Harald Alvestrand

unread,
Jun 22, 2015, 3:18:48 PM6/22/15
to blink-dev
Contact emails

Spec


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

Link to entry on the feature dashboard

Don't think it needs one.

Requesting approval to ship?

Yes.

PhistucK

unread,
Jun 22, 2015, 4:19:55 PM6/22/15
to Harald Alvestrand, blink-dev
The specification link directs to a different part of the specification.
Did you intend to link to this one?

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

unread,
Jun 22, 2015, 4:22:50 PM6/22/15
to PhistucK, blink-dev
Yes, you're right (both the link and my intent).

TAMURA, Kent

unread,
Jun 22, 2015, 7:20:49 PM6/22/15
to Harald Alvestrand, blink-dev
LGTM.

--
TAMURA Kent
Software Engineer, Google


Alex Russell

unread,
Jun 23, 2015, 12:12:20 AM6/23/15
to TAMURA, Kent, Harald Alvestrand, blink-dev
Glad to see this change! Can't LGTM it, but would if I could = )

Philip Jägenstedt

unread,
Jun 24, 2015, 4:13:00 AM6/24/15
to Alex Russell, TAMURA, Kent, Harald Alvestrand, blink-dev
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

unread,
Jun 24, 2015, 4:23:06 AM6/24/15
to Philip Jägenstedt, TAMURA, Kent, Harald Alvestrand, blink-dev
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

unread,
Jun 24, 2015, 4:36:43 AM6/24/15
to Philip Jägenstedt, Alex Russell, TAMURA, Kent, blink-dev
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

unread,
Jun 24, 2015, 11:01:06 AM6/24/15
to Harald Alvestrand, Alex Russell, TAMURA, Kent, blink-dev
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.)

Boris Zbarsky

unread,
Jun 24, 2015, 11:18:03 AM6/24/15
to Alex Russell, Philip Jägenstedt, TAMURA, Kent, Harald Alvestrand, blink-dev
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

unread,
Jul 1, 2015, 1:57:17 PM7/1/15
to Philip Jägenstedt, Harald Alvestrand, Alex Russell, TAMURA, Kent, blink-dev
LGTM3

:DG<

Guido

unread,
Jul 30, 2015, 10:08:26 AM7/30/15
to blink-dev, dgla...@chromium.org, phi...@opera.com, h...@google.com, sligh...@google.com, tk...@chromium.org, dgla...@chromium.org
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.
Reply all
Reply to author
Forward
0 new messages