W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

Re: [mediacapture-main] Should we allow empty string device IDs? (#551)

From: youennf via GitHub <sysbot+gh@w3.org>
Date: Tue, 15 Jan 2019 21:52:40 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-454565753-1547589159-sysbot+gh@w3.org>
> We decided sites are responsible for managing devices for users. How is a site to remember a user's choice without this?

I was thinking of the following workflow:

On first time user visit, the web site will do:
1. Call enumerateDevices to check for camera/microphone
2. Call getUserMedia and receive audio/video MediaStreamTracks
3. Store the mic/camera deviceIds attached to the MediaStreamTracks, say in IDB

On the user second visit, the website will do:
1. Retrieve the deviceIds audioDevice1 and videoDevice1 from IDB
2. Call getUserMedia({audio: {deviceId: audioDevice1}, video : {deviceId: videoDevice1})
    Browser will provide the content of the expected devices if they still do exist and if user did not remove cookies. Otherwise, default devices will be used.
3. Update IDB stored deviceIds if needed

AIUIC, during the second visit, device labels would be initially filtered out.
But, since device IDs would be persistent and exposed, the web page could easily retrieve device labels by storing them during the first visit and pairing them with device IDs on second visit.
This seems to somehow contradict label filtering.
It is true though that this would enable the possibility for a device picker early on in the web page flow, should the browser to provide a full list of devices. Safari does not plan to provide this full list though.
And I haven't seen web sites with that flow either.

What functionality would Safari proposed behavior prevent?

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/551#issuecomment-454565753 using your GitHub account
Received on Tuesday, 15 January 2019 21:52:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:54 UTC