Intent to Ship: Navigator.mediaDevices

[Guido Urdaneta]

Intent to Ship: Navigator.mediaDevices

Contact emails

gui...@chromium.org, gru...@chromium.org, h...@chromium.org, to...@chromium.org

Spec

https://w3c.github.io/mediacapture-main/#mediadevices

Summary

Add the navigator.mediaDevices object and the navigator.mediaDevices.enumerateDevices() function.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/enumerateDevices/blink-dev/709H0911zqM/lpYDQChJx1QJ

Note that, at the time, there was an intent to implement and ship, but Intent to Ship was not approved due to API not being stable (see intent spreadsheet) and some disagreement about the permissions model. The API has stabilized and the implementation (currently behind a flag) uses the permission scheme described in the specification, which is also the same as the obsolete (but still supported) MediaStreamTrack.GetSources().

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

Yes

Demo link

https://guidou.github.io/enumdemo.html

Compatibility Risk

We believe adding this feature actually reduces compatibility problems since the spec has been stable for several months and is already implemented or planned to be implemented by other major browsers:

• Firefox: Shipped (version 39)

• Microsoft Edge: Shipped (Windows 10 preview release)

• Safari: In development

OWP launch tracking bug

https://crbug.com/504280

Entry on the feature dashboard

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

[Guido Urdaneta]

Corrections:

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

This feature is supported in all platforms except Android WebView.

The reason is that Android WebView does not support the browser-side components that enable the enumeration of media devices.

Also, the Microsoft Edge support is behind a flag.

Sorry for the inaccuracies in the original message.

[Elliott Sprehn]

On Thu, Jun 25, 2015 at 4:22 PM, Guido Urdaneta <gui...@chromium.org> wrote:

Corrections:

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

This feature is supported in all platforms except Android WebView.

The reason is that Android WebView does not support the browser-side components that enable the enumeration of media devices.

Is there a plan to fix WebView?

[Guido]

On Thursday, June 25, 2015 at 11:59:42 PM UTC+2, Elliott Sprehn wrote:

On Thu, Jun 25, 2015 at 4:22 PM, Guido Urdaneta <gui...@chromium.org> wrote:

Corrections:

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

This feature is supported in all platforms except Android WebView.

The reason is that Android WebView does not support the browser-side components that enable the enumeration of media devices.

Is there a plan to fix WebView?

After further checking, it turns out that this feature does work (at least partially) on Android WebView.

The problem is that the permissions model on which the feature is based is not supported in WebView. As a result,  the list of devices reported by enumerateDevices() does not include the device labels as it does in the other platforms, but the devices are actually enumerated. 

Without proper permissions to access the devices, the returned enumeration is not going to be of much use, but I would say that the corresponding fix is not in the context of this Intent to Ship.

 

[Philip Jägenstedt]

LGTM, but is there any extra security review required, or has that already taken place?

It would be nice to sort out the WebView problem, do you think it's still worth shipping the API on WebView with that problem unresolved?

 

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

[Anton Vayvod]

+Torne for the WebView question

[Torne (Richard Coles)]

We want WebView to be a first class platform for chromium; it would be nice if features worked on it :) It's not entirely clear to me what the problem is from this thread. If this is something that can be fixed without webview API changes then we'd definitely prefer that it get fixed on webview before shipping it. If it's going to require changing the webview API we'll have to talk about that happening in a future android release, though.

[Chris Harrelson]

LGTM2

[Guido]

The spec says the following about enumerateDevices:

9.2.3 Access control model

The algorithm described above means that the access to media device information depends on whether or not permission has been granted to the page's origin to use media devices.

If no such access has been granted, the MediaDeviceInfo dictionary will contain the deviceId, kind, and groupId.

If access has been granted for a media device, the MediaDeviceInfo dictionary will contain the deviceId, kind, label, and groupId.

What happens on WebView is that it apparently does not support granting permissions to use media devices.

As a result, the returned enumeration contains deviceId, kind, and groupId, but no label.

I am not familiar enough with WebView to know which changes are required to make this work, but enumerateDevices is not the only feature affected by this permissions issue. For example, none of the demos at https://webrtc.github.io/samples/ work with WebView. In WebView, they behave the same as in other platforms when the user refuses to grant permissions.

 

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

[Torne (Richard Coles)]

WebRTC does work in WebView, and there is a supported permissions flow for media permissions. What are you using to test it? The embedding application has to implement the permission callbacks; WebView does not itself have a UI to prompt for permissions.

 

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

[Torne (Richard Coles)]

Guido and I chatted/experimented with this and it turns out the problem is http://crbug.com/489454 - the WebView doesn't currently have a real implemetation of PermissionManager::GetPermissionStatus because we currently just delegate permission requests directly to the embedding app and don't have a corresponding "get status, but don't actually request" callback. The mediaDevices API doesn't request audio/video permissions, it just checks with GetPermissionStatus and includes the device identifiers if it has the permission already, or omits them if it doesn't.

I think it's okay to ship mediaDevices with this limitation. Once we work out what to do with the webview permission API this will start working properly on webview; until then, the devices can be enumerated but just lack identifiers, which may already be the case anyway so developers should be able to handle this.

[Dimitri Glazkov]

LGTM3.

:DG<

[Guido]

This feature has been put back behind a flag in M45 due to a regression caused by Navigator.mediaDevices.getUserMedia(), which is an extension to Navigator.mediaDevices and currently shares the flag with enumerateDevices().

In M46 we plan to use a different flag for each feature.

[gui...@google.com]

The flag change landed recently (for M47). 

Now mediaDevices.getUserMedia() is behind the GetUserMedia flag, and mediaDevices.enumerateDevices() is exposed by default.

The new MediaDevices flag can be used to disable both.

The old EnumerateDevices flag no longer exists.