Re: getThisTabMedia

Since we're capturing a top level browsing context (HTML spec never uses 
the word "tab" except in explanatory text), perhaps 
GetCurrentBrowsingContextMedia is reasonable?

But since HTML spec uses the term "browsing context" for both iframes 
and tabs, that points out that we need to consider how this new function 
behaves with nested browsing contexts (aka iframes).

My immediate reaction would be to say "no" until we've got a) a need and 
b) some solid thinking about it.


On 10/4/20 12:58 PM, Dan Jenkins wrote:
> Isn't it just the current tab - there is no selecting done by the user 
> - a better name would likely be getCurrentViewportMedia or something 
> along those lines
>
> On Sun, 4 Oct 2020, 02:44 Silvia Pfeiffer, <silviapfeiffer1@gmail.com 
> <mailto:silviapfeiffer1@gmail.com>> wrote:
>
>     I love the idea.
>
>     How do you suggest the application would be able to identify the
>     "tab" without the user selecting it?
>     Would it be based on a text filter, e.g.
>     getTabDisplayMedia("Screen Capture") would then identify the
>     "Screen Capture" tab because of its naming?
>     Would it automatically pick the first such available or would it
>     bring up a picker dialog again if there are several matching ones?
>
>     Cheers,
>     Silvia.
>
>
>     On Sat, Oct 3, 2020 at 12:40 AM Elad Alon <eladalon@google.com
>     <mailto:eladalon@google.com>> wrote:
>
>         Hello all,
>
>         We're proposing an API that would be very similar to
>         navigator..mediaDevices.getDisplayMedia
>         <https://www.w3.org/TR/screen-capture/#dom-mediadevices-getdisplaymedia>,
>         but which only will be able to initiate capturing of the tab
>         from which it is called (rather than provide the much wider
>         selection of share-sources that getDisplayMedia has).
>
>         In the case of getDisplayMedia, the Screen Capture TR
>         <https://www.w3.org/TR/screen-capture/> says (bold-emphasis mine):
>
>             The user agent MUST let the end-user choose which display
>             surface to share *out of all available choices* every
>             time, and MUST NOT use constraints to limit that choice.
>
>
>         This will be true for getThisTabMedia too, but there, the only
>         “available choice” is the surface from which it is called
>         (specifically, the browser tab). We’ll be sending a PR similar
>         to this one
>         <https://github.com/eladalon1983/mediacapture-screen-share/pull/3>
>         against the Screen Capture TR fairly soon.
>
>         The *main benefit* of this new API is that a simple
>         accept/reject dialog can be presented to the user, rather than
>         a complex picker (screen/window/tab).
>
>         _Contrast getDisplayMedia picker in Chrome:_
>         image.png
>         _Potential dialog-box for getThisTabMedia:_
>         image.png
>
>         We think that the security properties of own-tab capture are
>         no worse than the version that goes via the picker. We note
>         that the application will have control over the surface that
>         is being displayed, and that can cause some sharing of
>         information that would otherwise be inaccessible, such as
>         colors on visited links, or content of embedded frames, but we
>         think that the risks are no bigger than for regular sharing,
>         and that the proposed, simple, prompt is good enough to
>         mitigate this concern.
>
>         Your feedback is hereby solicited. :-)
>
>         Thanks,
>         Elad Alon
>