- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Tue, 28 Apr 2020 08:53:48 +0000
- To: public-webrtc-logs@w3.org
> Expecting web devs to do more than that seems ambitious. I think there will be some adoption needed whatever proposal we come up with. I know some websites that identify insertion of devices and seem to work fine in Safari. I haven't looked what is done for that purpose. Maybe the algorithm you quoted is being used with two fixes: - Also include a device.kind check to at least fix pre-gum case - Call the same snippet at getUserMedia resolution time / reinitialise 'old' with all information (including deviceIds, labels and capabilities) > That would be a silly thing to do when _enumerateDevices_ already buffers (see [storedDeviceList](https://w3c.github.io/mediacapture-main/getusermedia.html#ref-for-dfn-storeddevicelist-3)). The web app needs to buffer the list of devices to detect new devices, the only question is whether the web app will use this list for other purposes. I do not see why that would be silly to do. Let's say we implement either of these proposals. The above code snippet would still break in some cases: - User has a builtin camera and a USB camera - User grants getUserMedia access and uses the builtin camera - User removes the USB camera as it is not used - A devicechange event fires, web app is falsely made aware of a new device, the built-in camera given it has now a non empty deviceId. That does not mean Safari behavior cannot change. Reducing the number of events to fire is a good thing in general. It seems a good plan for browsers that have not yet shipped the filtering to try not firing the event at first getUserMedia resolution. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/688#issuecomment-620473015 using your GitHub account
Received on Tuesday, 28 April 2020 08:53:50 UTC