Remove navigator.getUserMedia from the spec.

[jan-ivar]

We said we'd give it two years. I think it is time.

Chrome is on the cusp of unprexing navigator.webkitGetUserMedia, effectively introducing a new navigator.getUserMedia API. but why add a _new_ legacy API?

We want people to converge around navigator.mediaDevices.getUserMedia, not this.

Firefox took a different approach ten months ago, unprefixing everything but navigator.mozGetUserMedia which we show a deprecation warning on, directing people to use navigator.mediaDevices.getUserMedia. Firefox recognized that legacy is for actual legacy code.

There is no interop reason, since all legacy code does something like this:

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

We're now feeling pressure to implement navigator.getUserMedia which would send the wrong signal.

Lets remove this for good.

[foolip]

The unprefixed navigator.getUserMedia has already shipped in Edge, and the prefixed variants are shipping in Firefox and Chrome. Not sure about Safari.

Use counters for all variants were just added to Blink by @alvestrand:

• navigator.webkitGetUserMedia (an exact alias of the below)
• navigator.getUserMedia
• navigator.mediaDevices.getUserMedia

These won't reach the stable channel until September, but one can already tell that navigator.webkitGetUserMedia has the highest usage.

It seems pretty unlikely that anyone could get away with supporting none of navigator.getUserMedia, navigator.moztGetUserMedia and navigator.webkitGetUserMedia, so the spec needs to reflect that somehow. An option is to spec only navigator.webkitGetUserMedia, but given that it's a plain alias the cost of also supporting navigator.getUserMedia is very low.

[jan-ivar]

The prefixed variants will be around for a long time, but people aren't confused by what is old and what is new with them.

I have no problem with Edge implementing navigator.getUserMedia. Edge had no established prefix, so I understand their decision, given that Chrome still hadn't moved to the new API, and Firefox hadn't yet started deprecation warnings.

But this is still a legacy API. Leave it up to Safari whether to support it. We have an opportunity to converge around navigator.mediaDevices.getUserMedia. Lets not cement legacy in specs forever.

For comparison, Chrome pulled http support just like that, and everyone jumped to update.

[jan-ivar]

I removed a comment that I changed my mind on.

[foolip]

Some specs like DOM and Geometry have gone the path of spec'ing both the unprefixed and webkit-prefixed APIs. It's pretty likely that everyone could successfully converge on that without sacrificing compat. Having only the webkit-prefixed API might also be web compatible, but then Edge has to take a risk in removing their navigator.getUserMedia.

I know of one case where we enshrined diverging behavior on navigator.vendor and friends because there seemed to be no path forward, but I think that should be a last resort.

In the Intent to implement and ship: Unprefixed getUserMedia I did test Gecko and notice the lack of support for navigator.getUserMedia, but it's only now that it's clear that you really don't want this in Firefox.

If navigator.getUserMedia reaches Chrome stable I think it's a done deal, it'll never go away. So, can you get all the implementors together to discuss and decide on this while there are still options on the table?

[jan-ivar]

That's why I'm raising this now. :)

Btw,I don't think Edge has to remove anything based on what we put in the spec. That's up to them. They can monitor its usage, add deprecation warnings, or leave it forever.

[ShijunS]

Based on our internal telemetry, the ratio between usages of navigator.getUserMedia and navigator.mediaDevices.getUserMedia in Edge is roughly 30:1. The Firefox deprecation warning mentioned by @jan-ivar might have helped some developers to move to the newer API. We have been encouraging web developers to use the promise-based approach as well. However, I expect any new browser implementation today will have to consider both options simply because of all the usages on the web. Therefore, it'd be a good reference at this point to the new implementers to keep navigator.getUserMedia in the spec.

[jan-ivar]

The numbers are not surprising, given that Chrome only added the new API a release ago, but I agree a new browser (e.g. Safari) would definitely want to implement navigator.getUserMedia (not navigator.webkitGetUserMedia which will people expect to work with old Chrome-only constraints) for quite some time.

How about we mandate browsers implement one of the three legacy ones?

[RByers]

If Safari (and Edge) could implement just getUserMedia without webkitGetUserMedia then chances are that blink could just drop the webkit version in favor of it too, right?

Note that there's also some precedent for defining APIs as legacy in W3C specs - recognizing the necessity for web compat while discouraging people (and perhaps new implementations) from using them. Eg. see Document.createTouch in TouchEvents.

[foolip]

@ShijunS, do you know if you've had any compat issues related to navigator.webkitGetUserMedia but resisted adding it for some reason? For something that has been prefixed-only for so long, I would half expect that some code out there either omits the unprefixed method as a fallback, or has a typo that breaks the site.

If nothing special comes to light, then I think aiming for interop on navigator.getUserMedia seems like a good plan A, but given that navigator.webkitGetUserMedia is just an alias I think the slightest sign of trouble in an attempted removal should be enough to have it spec'd instead.

[alvestrand]

The WG discussed this before, and landed on a decision not to start standardizing vendor prefixes.
I hear from @foolip that other specs have since gone down that route, but I think it takes a consensus of the WG to change that decision at this point.

In a month or two, we'll have numbers to argue from.

[jan-ivar]

@RByers @foolip Note: navigator.getUserMedia is incompatible with navigator.webkitGetUserMedia because the latter supports a Chrome-only constraints syntax (@alvestrand correct me if I'm wrong) . So Edge couldn't have used it.

Legacy compat is quite messy, and Chrome's new navigator.getUserMedia does more harm than good:

The only compat I see it fixing is a site not using the newer navigator.mediaDevices.getUserMedia, yet at the same time using modern spec constraints, and never testing their page in Chrome. Given marketshare, I find that hard to believe. (Firefox docs and warnings are heavily pushing navigator.mediaDevices.getUserMedia).

On the flipside, I'm surprised Google isn't more worried about this going to release, given that it looks to break a lot of users who depend on their old constraints format. Specifically, if they did this:

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

Then their constraints are now broken. But if they did this:

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

then it is not.

[alvestrand]

Jan-Ivar, you're speculating. And your speculation is wrong.

We (Chrome) are releasing a version that supports both old and new format constraints on all 3 getUserMedia versions. So anything that depends on the browser being Chrome will still depend on the browser being Chrome; anything that depends on getUserMedia (unprefixed) parsing new constraints will Just Work (modulo bugs in the new constraints).

The fact that there were users being broken by this not working for navigator.mediaDevices.getUserMedia was the reason we withdrew the shipping of that last year.

The one category left out in the cold at the moment is the category of those that put in both old and new format into their constraints, expecting Chrome to parse one and Firefox to parse the other. You will find the count of such users here:

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

These scripts will get a TypeError callback / rejected promise.

The count of conformant (new-syntax) constraint users is here:

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

And the count of old-style constraint users is here:

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

The numbers are as expected given that it's only been unflagged last week. Once the second counter is significantly larger than the third counter, we'll consider removing support for the old-style constraints. At the moment, the Right Choice is obvious.

[jan-ivar]

@alvestrand Thanks for correcting me. My mistake, and I'm glad to hear I was wrong, as what you describe sounds like a good solution. Sorry for speculating.

So I'm glad there's no harm, but back to benefits, I still don't see many (except the marginal one I mentioned).

There really isn't an existing old coherent legacy population helped by navigator.getUserMedia becoming available. Your point about _TypeError_ing on mixed constraints I think illustrates this: Any working legacy code out there using constraints has to be using feature detection:

if ("webkitGetUserMedia" in navigator) {
    navigator.webkitGetUserMedia(chromeConstraints, y, n);
} else {
    (navigator.getUserMedia || navigator.mozGetUserMedia) (specConstraints, y, n);
}

Yes that's quite horrible, but we already have a solution established two years ago:

navigator.mediaDevice.getUserMedia(specConstraints).then(y, n);

so why do we need another solution?

My concern here is convergence, as navigator.getUserMedia has the better name (less typing).

[elagerway]

The chairs are not seeing consensus needed to proceed on this one, closing for now.