> 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-configReceived 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