Intent to Ship: Navigator.mediaDevices

843 views
Skip to first unread message

Guido Urdaneta

unread,
Jun 25, 2015, 11:18:50 AM6/25/15
to blink-dev

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:


OWP launch tracking bug

https://crbug.com/504280


Entry on the feature dashboard

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


Guido Urdaneta

unread,
Jun 25, 2015, 5:22:35 PM6/25/15
to blink-dev
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

unread,
Jun 25, 2015, 5:59:42 PM6/25/15
to Guido Urdaneta, blink-dev
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

unread,
Jun 26, 2015, 11:06:58 AM6/26/15
to blin...@chromium.org, esp...@chromium.org, gui...@chromium.org
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

unread,
Jun 29, 2015, 8:25:54 AM6/29/15
to Guido, blink-dev, Elliott Sprehn
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

unread,
Jun 29, 2015, 9:41:35 AM6/29/15
to Philip Jägenstedt, Guido, blink-dev, Elliott Sprehn, to...@chromium.org
+Torne for the WebView question

Torne (Richard Coles)

unread,
Jun 29, 2015, 9:44:43 AM6/29/15
to ava...@chromium.org, Philip Jägenstedt, Guido, blink-dev, Elliott Sprehn
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

unread,
Jun 29, 2015, 12:47:55 PM6/29/15
to Torne (Richard Coles), Anton Vayvod, Philip Jägenstedt, Guido, blink-dev, Elliott Sprehn
LGTM2

Guido

unread,
Jul 1, 2015, 5:27:10 AM7/1/15
to blin...@chromium.org, to...@chromium.org, gui...@chromium.org, esp...@chromium.org, phi...@opera.com, ava...@chromium.org

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)

unread,
Jul 1, 2015, 5:28:31 AM7/1/15
to Guido, blin...@chromium.org, esp...@chromium.org, phi...@opera.com, ava...@chromium.org
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)

unread,
Jul 1, 2015, 9:40:49 AM7/1/15
to Guido, blin...@chromium.org, esp...@chromium.org, phi...@opera.com, ava...@chromium.org
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

unread,
Jul 1, 2015, 2:02:45 PM7/1/15
to Torne (Richard Coles), Guido, blink-dev, Elliott Sprehn, Philip Jägenstedt, Anton Vayvod
LGTM3.

:DG<

Guido

unread,
Jul 30, 2015, 10:19:22 AM7/30/15
to blink-dev, dgla...@chromium.org, to...@chromium.org, esp...@chromium.org, phi...@opera.com, ava...@chromium.org, dgla...@chromium.org
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

unread,
Aug 28, 2015, 10:45:07 AM8/28/15
to blink-dev, dgla...@chromium.org, to...@chromium.org, esp...@chromium.org, phi...@opera.com, ava...@chromium.org
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.
Reply all
Reply to author
Forward
0 new messages