Should getUserMedia promise be resolved only on pages that have focus

[youennf]

Safari currently does not resolve/reject a getUserMedia promise until the view is visible.
This allows to start capture on a page that the user has access to.
Should this be mandated in the spec?
The same question might apply to enumerateDevices.

[jan-ivar]

Firefox has this behavior as well. Turning on camera/mic from a background tab is creepy.

This might even be something that could go in the permissions spec.

Having prompts appear from background tabs is generally a UX security issue.

enumerateDevices() does not require permission, so I'd treat that as a separate issue I think.

[youennf]

Having prompts appear from background tabs is generally a UX security issue.

Right, Safari is not resolving getUserMedia promise even in the case where no prompt will be shown to user (say user granted persistent access to this website).

One could think of relaxing this rule in case the device is already capturing.
But that can probably be emulated with clone+applyConstraints so I am not sure this is worth optimizing.

I guess the idea would be to postpone the whole getUserMedia process starting at step 6 until page has focus.

[jan-ivar]

Safari is not resolving getUserMedia promise even in the case where no prompt will be shown to user (say user granted persistent access to this website).

Firefox has the same behavior. Testing with this fiddle in two tabs, Chrome and (early) Edge do not. @alvestrand @henbos @aboba thoughts?

relaxing this rule in case the device is already capturing. [ = clone+applyConstraints]

I agree. (Too hard).

I guess the idea would be to postpone the whole getUserMedia process starting at step 6 until page has focus.

I can submit a PR for discussion. Then we can argue over MAY, SHOULD or MUST, if we like this.