Initial draft of getViewportMedia()

[jan-ivar]

Fixes #1.

I've tried to reflect my understanding of consensus as best I can. We never discussed audio, but since this is in large parts a cut'n'paste from getDisplayMedia, I've kept it in for parity with getDisplayMedia. Open to discuss that if others disagree.

@eladalon1983, @youennf, @alvestrand, @annevk PTAL.

---

Preview | Diff

[dontcallmedom]

we need to define in this spec the said document policy "configuration point"

[jan-ivar]

Thanks! I'll look into it.

[jan-ivar]

I'll address this in a followup.

[dontcallmedom]

instead of copying the content of screen capture, it would be better to make that algorithm re-usable there.

[jan-ivar]

The algorithms are different so that doesn't work:

- Prompt the user to choose a display device, for a PermissionDescriptor with its name set
- to "display-capture", resulting in a set of provided media.
+ Request permission to use viewport capture, for a PermissionDescriptor with its name set
+ to "viewport-capture", resulting in a set of provided media.

- The provided media MUST include precisely one video track.
+ The provided media MUST include precisely one video track, which MUST be a live-capture
+ of the browser display surface of the relevant settings object's responsible document's
+ top-level browsing context's viewport.

- The devices chosen MUST be the ones determined by the user. Once selected, the source of a
- MediaStreamTrack MUST NOT change, unless the user permits it through their interaction with
- the user agent.
+ The source of a MediaStreamTrack MUST NOT change.

- User agents are encouraged to warn users against sharing browser display devices as well as
- monitor display devices where browser windows are visible, or otherwise try to discourage
- their selection on the basis that these represent a significantly higher risk when shared.
+ 

- The provided media MUST include at most one audio track. This audio track MUST NOT be
- included if audio was not specified in requestedMediaTypes, or if it was specified as false.
+ The provided media MUST include at most one audio track, which, if provided, MUST be the
+ combined audio produced by the sum of documents that consist of the relevant settings object's
+ responsible document's top-level browsing context's active document, and all active documents
+ in nested browsing contexts of the relevant settings object's responsible document's top-level
+ browsing context.

- For the newly created MediaStreamTrack, the user agent MUST NOT capture the prompt that
- was shown to the user.
- 
- Information that is not currently rendered to the screen SHOULD be obscured in captures unless
- the application has been specifically authorized to access that content (e.g. through means such
- as elevated permissions).
+ 

- The user agent MUST NOT share audio without active user consent, for example if the capture of
- the video of a window is accompanied by capture of the audio of the entire system, including
- applications unrelated to that window.
+ The user agent MUST NOT share the audio other than audio emitted from the captured tab,
+ and MUST NOT share audio of the entire system.

There's also a precedent here in w3c/mediacapture-screen-share#73.

[dontcallmedom]

it still feels that an algorithm with parameters could handle both; but maybe that's an unneeded optimization; I worry about improvements being brought in one place and missed in the other.

[jan-ivar]

@eladalon1983 and I discussed this this morning and we both prefer to keep the algorithms separate.

We need to worry either way (whether improvements were meant for both or just one or the other), and WPT tests still need to be written for both, so we don't see it as a big savings for us as editors.

[alvestrand]

Editors can integrate. The status should be "UD" (Unofficial Draft) until we have had a Call for Adoption.