[mediacapture-screen-share] Allow screen-captured application to influence MediaStreamTrack.label (#159)

eladalon1983 has just created a new issue for https://github.com/w3c/mediacapture-screen-share:

== Allow screen-captured application to influence MediaStreamTrack.label ==
## State of the Art
MediaStreamTrack.label is [specified](https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/label), but the standard has very little to say about the value. More specifically, nothing is said for those MediaStreamTracks which are the result of a call to `getDisplayMedia`.

Examine the label of video tracks resulting from `getDisplayMedia` in some **current implementations**, focusing mainly on window/tab capture:
* Chrome: Exposes internal Chrome state; I've filed a bug and will be fixing it soon.
* Firefox: Does not support tab-capture, but supports window capture, and uses the window's title; if the window is a Firefox window, the label is set to the active tab's title.
* Safari: Tab/window-sharing not supported.

## Problem
The value of the label for tracks received from `getDisplayMedia` is unclear if unspecified.
Using tab titles, URL.host, etc., would be all be interesting options, but it's dangerous for browsers to unilaterally decide to capture more content than before; it's better if apps opt-in to sharing more.
(One recently opened issue that would benefit from this proposal is #143.)

## Suggested Solution
Let the application choose what the label should be, through a new settable attribute called `navigator.mediaDevices.preferredLabel` (or any other name). It should only be settable by the top-level document. Applications that wish to share the title can opt-in to doing so. Applications that wish to broadcast an arbitrary message to an unknown capturing app can do so. It's opt-in!

## Expected Reservations / Questions
### This would let applications transmit information from captured app to the capturing app.
Yes. As does the video track itself via magic pixels, QR codes, text-and-OCR, or flashing the screen black/white to signal 0s and 1s. The capture itself is a one-way data channel. We just provide a more ergonomic side-channel to broadcast a text-based annotation.

### What if the user navigates the captured tab?
We recalculate the label. It is read-only, but it's not specified as immutable.
(We should add an event as a follow-up, IMHO. As this proposal provides sufficient value even before such an event, and even if we start out with an immutable label, I would propose not delaying until we've specified the event.)

### That lets the capturing app detect navigation.
True. That's not the only way, though. More importantly, I don't think that's a problem.

### What if preferredLabel is not set?
The user agent MAY use whichever label it wishes, as it can today.

Please view or discuss this issue at https://github.com/w3c/mediacapture-screen-share/issues/159 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 29 March 2021 20:00:22 UTC