This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Forked from https://www.w3.org/Bugs/Public/show_bug.cgi?id=23263. The idea here is to have a callback that apps can register for to learn when a new device becomes available (or is removed). The main use case here is for a Bluetooth headset - if one shows up, the app may want to display a button indicating the call can be transferred to the headset, and remove that button if the headset disappears. Currently this would require the app poll the getMediaDevices API on a regular basis, which is inefficient at best. I suggest the name navigator.onmediadeviceschange for this API.
When this was last discussed, it was deemed that it was sufficient to poll for new devices.
Agreed, but after actually working with the API I think that polling is clumsy; to get the behavior described below, you would have to poll the API about every second for the entire lifetime of the call.
Implementations like navigator.geolocation.watchPosition makes sense when there is a continuous update as in case of location co-ordinates(ex: travelling in a car). Also, these attributes have wide range of values. In case of WebRTC calls, you have limited no. of media input/output devices and they are either plugged or unplugged. Polling mechanism in this scenario will be a burden on overall system. Callback mechanism should be fine.
Discussed at the Media Capture TF on May 19. Consensus that this is needed. Suggestion (made later in the meeting): Create a Navigator.mediaDeviceHandler object that can hold the ondevicechange handler event, as well as a possible getUnderstoodConstraintNames function that was suggested in another context. A concrete proposal is expected.
Here's a proposal. Regarding the name, I don't think the -handler or -manager suffixes add much. The sibling object for geolocation is simply called "geolocation" so I suggest MediaDevices, UserMedia or something. partial interface NavigatorUserMedia { // kept for legacy purposes void getUserMedia (MediaStreamConstraints? constraints, NavigatorUserMediaSuccessCallback successCallback, NavigatorUserMediaErrorCallback errorCallback); readonly attribute UserMedia userMedia; }; Navigator implements NavigatorUserMedia; interface UserMedia : EventTarget { // this belongs there void getUserMedia (MediaStreamConstraints? constraints, NavigatorUserMediaSuccessCallback successCallback, NavigatorUserMediaErrorCallback errorCallback); attribute EventHandler? ondevicechange; void enumerateDevices (MediaDeviceInfoCallback resultCallback); // place future function for constraint name probing here }; MediaDeviceInfoCallback is already in the spec. The function enumerateDevices() replaces the current async getMediaDevices() function. The new function could be synchronous (as in Martins proposal) if we do the work of preparing the return value in advance every time the device list changes. I don't have a strong opinion about it. We don't need a new event type since the event only notifies that there's new info available elsewhere (accessed by querying an other function). If the app wants to know about changes, it has to keep a reference to an old list and compare. Once we have settled for a first version name, I think we can start editing this into the spec.
Proposed fix: https://github.com/fluffy/webrtc-w3c/commit/de3bdaf83d2cc1350cc3be970baf1d11219add1d