- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Jan 2022 14:14:01 +0000
- To: public-webrtc-logs@w3.org
The application cannot currently cancel a call for gUM once it's in the pending state. That means that a call to gUM can result, several days later, in a user seeing the indicator turn on. Even if the application is wise enough to realize that it's been too long, and even if it immediately stops the capture, some damage has already been done - the user will be alarmed, and might even suspect the honest application. Preventing this would protect both user and application. We've glossed over one other possible solution, and discussed two possible solutions. 1. [Not yet discussed] Allow applications to cancel gUM calls. I think this is a tall order, and is a partial solution to boot. 2. [Discussed] Allow the UA to reject Promises once focus shifts back. 3. [Discussed] Allow the UA to reject Promises in the background. Youenn has pointed out that no2 is already spec-compliant. I am trying to argue that no3 is better for both applications and for compat, because it makes an implicit state explicit. Consider no2. User agents will likely "zombify" gUM-Promises after an internal timer elapses, meaning UAs will make the irrevocable decision to reject the Promise as soon as the page regains focus. For argument's sake, say Chrome internally decides to reject the Promise after 30min, Firefox after 60min, and Safari never. Suppose an application cares about when a Promise is zombified. They would hard-code the knowledge that Chrome/Firefox/Safari would never fulfill the Promise after 30/60/infinity minutes, respectively. This is awkward. But if the UA rejects the Promise in the background (instead of zombifying it), this would allow applications to write code that's agnostic of which UA it's running on. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/846#issuecomment-1008912235 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 January 2022 14:14:03 UTC