search

w3c / mediacapture-main

Media Capture and Streams specification (aka getUserMedia)
https://w3c.github.io/mediacapture-main/
Other
125 stars 61 forks source link

`beforeunload` prompt should display for active Media Capture sessions #1013

Open thexeos opened 1 month ago

thexeos commented 1 month ago

Feature request proposing a change to beforeunload firing behavior was filed in WHATWG repo: https://github.com/whatwg/html/issues/10627

WHATWG proposal summary: current beforeunload would not show "Are you sure you want to close this page?" dialog unless user had clicked/typed inside the Document. However, Media Capture allows getUserMedia() to succeed without such prior user activation. As a result, one could develop a web application that joins a conference call immediately upon page load, but afterwards can't prevent the user from accidentally closing the tab/window/PWA with an active call.

To facilitate correct beforeunload prompt behavior, it is likely that Media Capture amendments will be necessary.

The proposed WHATWG change would rely on detecting active Media Capture session. Furthermore, to prevent abusive beforeunload prompts a minimum Media Capture session duration should be considered (e.g., during first 15 seconds of "activationless" Media Capture, user can close the page without seeing the beforeunload prompt - note that the countdown must being from getUserMedia() resolving).

Current Media Capture specs don't expose any standard ways to determine:

  1. That an active Media Capture session is ongoing for a Document (e.g., if any of the local devices are attached to a live MediaStreamTrack in mediaDevices's relevant global object's associated Document)
  2. When MediaStreamTrack was created

Those would likely have to be specified in order to define correct 'beforeunload' prompt behavior.

Ref: https://issues.chromium.org/issues/40704936#comment9

youennf commented 1 month ago

Wrt to 1, there is https://w3c.github.io/mediacapture-main/#context-is-capturing. The main difference is that it would return false in case there are live but muted tracks. This seems actually fine to me.

Wrt 2, privacy indicators are defined at https://w3c.github.io/mediacapture-main/#privacy-indicator-requirements. They stay on for a minimum of 3 seconds (meaning that a web application that calls getUserMedia and stops the tracks immediately would have its privacy indicator on for at least 3 seconds).

Privacy indicators are usually implemented per top-level browsing context, which might align with the idea to prompt when the top-level browsing context is getting closed and either itself or one of its child is/was capturing recently.