Re: [mediacapture-main] getUserMedia "hanging" indefinitely (#846)

> Step 6.3.7 states that: based on a previously-established user preference, for security reasons, or due to platform limitations, jump to the step labeled Permission Failure below.

Thanks. You're right that, modulo not resolving the Promise until regaining focus, this part of the spec allows the UA to reject on the user's behalf. If we decide that waiting until focus is regained is the right thing, then this is indeed sufficient.

> I am unsure what the benefit of rejecting sooner (aka triggering some JS execution in a background page) might be.

Otherwise, application cannot tell if the Promise is alive and well (might be fulfilled in the future) or a "zombie" (pending but could never be fulfilled; might still be rejected, though). If this is an important issue for the application, it might try to determine that by checking the browser name+version against a list of known expiration times - awkward. But if all UAs reject when+if they determine it's been too long, then there is no work required by the application, and also compat issue. (This assertion of no compat issue stands even if some UAs never impose a limit.)

> Not rejecting a promise isn't "hanging", it's more like not firing an event or never calling a callback, which seems fine.

I agree. That's why I used [Dr. Evil's air quotes](https://i.imgflip.com/60fvvh.jpg) around "hanging." 😉

> but B seems a bit harder. The site would basically have to request gUM while in the background (without a user trigger), or the user tabbed away in the sometimes >1 second time window between gUM call and success.

1. That does happen.
2. Sites sometimes spawn new tabs. If the user leaves the computer before tabbing back, they enter this state.
3. An application might call both getUserMedia() and getDisplayMedia() in response to a single click ("join and present"), either immediately or sequentially. Calls to getDisplayMedia() can result in activation of the tab the user chooses to share.

By the way, even if the application is quite sophisticated and user-friendly, and decides to monitor how long it took for the user to approve gUM and immediately kill the capture if it's been too long, the user might still be alarmed that their camera's indicator light flashed briefly.

-- 
GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/846#issuecomment-1007813167 using your GitHub account


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

Received on Friday, 7 January 2022 23:17:25 UTC