Re: getThisTabMedia

You wouldn't share the current tab - the current tab is the one where the
video call is taking place. You'd typically want to share one of the other
open tabs as a screenshare. That's how I understand it at least.

On Sun, Oct 4, 2020 at 9:58 PM Dan Jenkins <dan@nimblea.pe> 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
>>>
>>