- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Jan 2020 00:05:03 +0000
- To: public-webrtc-logs@w3.org
> if they already have device ID stored somehow, shouldn't they just specify it right in the GUM call?
@q-alex-zhao Yes, and if they specify `{deviceId: {exact: id}}` then there's no difference.
The concern is whether it's common to use `{deviceId: id}` on revisit to mean _"use device from last time if available, or the default device if not"_. https://github.com/w3c/mediacapture-main/pull/644 would change that to _"if user has > 1 cams/mics always show picker with device from last time as the default choice, **even if you have permission**"_.
Those are incompatible semantics.
Same with `{facingMode: "user"}` instead of `{facingMode: {exact: "user"}}`.
We also got anecdotal feedback yesterday of _"sites calling getUserMedia all over the place"_, using the _constraints_ object as a lazy handle, which today won't prompt while live tracks are in use (not actually guaranteed by the spec, but works in all browsers). If widespread, this may mean even more redundant prompts from this change.
I suppose opinions vary on whether this counts as "breaking the web" or merely nudging sites toward better patterns...
> I'm not sure how the application should choose which API to use
1. Use `{chosen: true}` to replace your in-content device selection code.
1. Inital gUM prompt: `{chosen: true}` = picker like Firefox. `false` = user agent chooses.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/656#issuecomment-574915401 using your GitHub account
Received on Thursday, 16 January 2020 00:05:05 UTC