W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2022

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

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Mon, 03 Jan 2022 14:52:01 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1004144861-1641221519-sysbot+gh@w3.org>
> The decision to reject can be done today based on a timer.

Yes, that's my thinking.

> The only thing is when the promise gets actually settled: either after a timer when the page remains in background or when the page gets active.

By rejecting while the page is in the background we:
* Clear some minuscule amount of memory sooner.
* Alert applications sooner to the fact that they will not, in fact, be getting mic/camera access.

Admittedly, these are but minor benefits. Are there benefits to the inverse approach?

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

Prevents unintended and surprising behavior which neither user nor application desire, like a previously inactive page asking for mic/camera permissions as soon as the user activates that page, a very long time after they had originally interacted with the page. For example, consider coming back from vacation on January and activating a tab for the first time in weeks.

> One additional downside is allowing different behaviours across browsers.

Indeed. This can be mitigated by mandating a minimum value for "reasonable time."

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 3 January 2022 14:52:02 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:55 UTC