Re: getThisTabMedia

I think this is a good idea. At first I thought this could be achieved with
a constraint on getDisplayMedia (by allowing this particular constraining
on sources), but we may want to add more features in the future that can
take the fact that this is tab-only into account, so for extensibility I
think a separate API for this use case could be beneficial.

If we do introduce a tab-only API, it is worth discussing whether the API
should be "share this tab only" (as proposed) or if we should extend the
API to be a broader "share a tab" API, where we achieve the "this tab only"
use case through a constraint.
I'm thinking about the fact that in Google Meet screen sharing, there is a
"share a tab" button that achieves this effect, which is not possible to
achieve with the spec-compliant getDisplayMedia. And if a new API will have
benefits relating to tab sharing, then perhaps we want to get those
benefits both in the case of sharing "this tab" and "other tabs". Just a
thought.

In any case, I support an API like this.

On Mon, Oct 5, 2020 at 10:21 AM Harald Alvestrand <harald@alvestrand.no>
wrote:

> 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>
> 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> 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: image.png]
>>> *Potential dialog-box for getThisTabMedia:*
>>> [image: 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
>>>
>>