Re: getThisTabMedia

No worries Elad - something wasn't quite right with the list it seems

Issue is here -
https://github.com/w3c/mediacapture-screen-share/issues/105#issuecomment-698793665
- I haven't found the time to go make issues in the relevant trackers.
Theres also a twitter thread where we talk about it -
https://twitter.com/arnaudbud/status/1309937885844389888?s=20

Completely agree on region-capture being another topic of conversation - on
the face of it, region capture is easy when it comes to getDisplayMedia, as
I'd expect the browser to enable selection of a portion of the
window/display statically... but when you get into say, capturing an
element within a tab/window.... that becomes more complex.

Tim, I need to think about how that would be implemented some more before
replying.

On Mon, Oct 5, 2020 at 9:40 AM T H Panton <thp@westhawk.co.uk> wrote:

> I think you are missing a significant trick here.
>
> This API surface belongs in the Service Worker.
>
> The service worker should be able to return a media stream to any of the
> pages it is serving, which represents
> a region of any page it is serving.
>
> The user just has to agree.
>
> The advantage here is that it solves both Dan and Silvia's usecases, and
> enforces same-origin in a natural way.
> What's more the stream can survive user navigation - which your current
> proposal can't.
>
> T.
>
> On 2 Oct 2020, at 15:35, 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.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
>
>
>