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 16:36:44 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-1004212838-1641227803-sysbot+gh@w3.org>
> rejecting the getUserMedia request: this can be done today based on a timer/heuristic without changing the spec.

(Reordered to put this most important part first.)
What part of the spec allows that? To be clear, it is precisely this affordance that I suggest adding to the spec. If it's already there - great!

> Consistent cross-browser behavior

Rejecting when the page regains activity+focus does not provide full consistency if one browser rejects after 30min of inactivity and another browser rejects after 60min. (Let alone if another browser never rejects.)

> Also, I do not see why we should be gentle to applications calling getUserMedia on backgrounded pages.
Applications calling getUserMedia based on a user gesture should hopefully not end up into that issue.

The prose explaining focus is not terribly easy to understand, so I might easily be wrong. But as I understand, a page does not have to be backgrounded in order to not have focus. Consider side-by-side windows, like FaceTime and Safari. Let Safari have but a single tab. If the user clicks on the FaceTime window, then no document in the single tab Safari is displaying is focused, I believe...? Assuming I'm right about that - what happens if the user alt-tabs back to Safari the next day, or after lunch? I think that's an unreasonable time, and the browser should be allowed (`MAY`) to reject the Promise based on a timer.

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/846#issuecomment-1004212838 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 16:36:46 UTC

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