[mediacapture-output] Why prompt for a subset of stored speakers or speakers setSinkId already accepts? (#142)

jan-ivar has just created a new issue for https://github.com/w3c/mediacapture-output:

== Why prompt for a subset of stored speakers or speakers setSinkId already accepts? ==
In https://github.com/w3c/mediacapture-output/issues/116#issuecomment-754478397 @youennf explains the model well:
> The model is as follow:
> a. If enumerateDevices is exposing audiooutput devices, deviceId can be used by setSinkId.

...so why should [selectAudioOutput({deviceId})](https://w3c.github.io/mediacapture-output/#dom-mediadevices-selectaudiooutput) prompt? _"If deviceId is not `""` and matches an id previously exposed by [selectAudioOutput](https://w3c.github.io/mediacapture-output/#dom-mediadevices-selectaudiooutput) in an earlier browsing session, the user agent MAY [skip the prompt]"_

This forces apps who already have transient activation to vet their stored ids through enumerateDevices to conditionally skip selectAudioOutput to avoid a needless prompt.

> b. If the application knows of a deviceId used in the past but enumerateDevices is not exposing it, the application is expected to call selectAudioOutput with the corresponding deviceId.
> ...
> Case b. can happen for deviceId previously revealed by selectAudioOutput or getUserMedia.

Except case b will prompt for deviceIds revealed by getUserMedia. This seems surprising.

This seems like it could be streamlined. User agents should be allowed to bypass the prompt for deviceIds that are good to go.

Please view or discuss this issue at https://github.com/w3c/mediacapture-output/issues/142 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 13 July 2024 00:01:39 UTC