Bugzilla

(In reply to Rafael Gawenda from comment #7)
> I've just found the source of the issue, I open the WebSocket at the navigator.mediaDevices.enumerateDevices() promise resolution. Promise does only resolve when asked in foreground, in Firefox. I couldn't find the point of this requirement in the [standard spec](https://w3c.github.io/mediacapture-main/#device-information-exposure)

It says: _"To perform a [device enumeration can proceed](https://w3c.github.io/mediacapture-main/#device-enumeration-can-proceed) check, given mediaDevices, run the following steps:_

 1. _The User Agent MAY return true if [device information can be exposed](https://w3c.github.io/mediacapture-main/#device-information-can-be-exposed) on mediaDevices._
 2. _Return the result of [is in view](https://w3c.github.io/mediacapture-main/#dfn-is-in-view) with mediaDevices._
 3. _Return false."_

Step 2 is a foreground check, which means Firefox is following the spec when it only resolves the promise in the foreground.

This should satisfy most applications, since device enumeration exists primarily to assist code calling `getUserMedia` which also requires foreground (_and_ focus). Without more information, I'd say comment 0 seems solved by not blocking the WebSocket connection on device enumeration, as these two things seem unrelated. Please let me know if that is not a solution.

If it helps, applications that wish to detect if they'll get blocked are supposed to be able to write:
```js
if (document.visibilityState == "visible") {
  devices = await navigator.mediaDevices.enumerateDevices(); // won't block on hidden thanks to if
}
```
However, if you attempt this, you may run into bug 1818588. So instead of closing this as invalid, I'll mark it as a dup of that bug to up-prioritize it.

Hope that helps.

(In reply to Rafael Gawenda from comment #7)
> I've just found the source of the issue, I open the WebSocket at the navigator.mediaDevices.enumerateDevices() promise resolution. Promise does only resolve when asked in foreground, in Firefox. I couldn't find the point of this requirement in the [standard spec](https://w3c.github.io/mediacapture-main/#device-information-exposure)

It says: _"To perform a [device enumeration can proceed](https://w3c.github.io/mediacapture-main/#device-enumeration-can-proceed) check, given mediaDevices, run the following steps:_

 1. _The User Agent MAY return true if [device information can be exposed](https://w3c.github.io/mediacapture-main/#device-information-can-be-exposed) on mediaDevices._
 2. _Return the result of [is in view](https://w3c.github.io/mediacapture-main/#dfn-is-in-view) with mediaDevices._

Step 2 is a foreground check, which means Firefox is following the spec when it only resolves the promise in the foreground.

This should satisfy most applications, since device enumeration exists primarily to assist code calling `getUserMedia` which also requires foreground (_and_ focus). Without more information, I'd say comment 0 seems solved by not blocking the WebSocket connection on device enumeration, as these two things seem unrelated. Please let me know if that is not a solution.

If it helps, applications that wish to detect if they'll get blocked are supposed to be able to write:
```js
if (document.visibilityState == "visible") {
  devices = await navigator.mediaDevices.enumerateDevices(); // won't block on hidden thanks to if
}
```
However, if you attempt this, you may run into bug 1818588. So instead of closing this as invalid, I'll mark it as a dup of that bug to up-prioritize it.

Hope that helps.