Re: getThisTabMedia

There has been a few use-cases from this discussion:
- Only allow user to share same-origin tabs
- Only allow user to share same tab
- Only allow user to share part of the same tab

I could see all use cases be included in getDisplayMedia (though the 3rd use case is a bit of stretch, something like a new method to reduce the shared view to specific DOM objects).
We decided to not allow a web page to restrain user selection in getDisplayMedia, but the situation of same origin tabs is somehow different so this should be fine.
So I do not see real blockers to try extending getDisplayMedia.

A new method might be fine too but has a cost. Current proposal seems to be limited to 2 only (though I guess we could try to stretch it for covering 3 as well).
How do people think about not optimising use case 1?

In general, it would be valuable to evaluate the pros and cons of reusing getDisplayMedia vs. introducing a new method.
Some related thoughts:

1. My first reaction is that it seems like a web page could use two different APIs to get the same result, which does not seem super great.
Adding a new API will not fix the potential getDisplayMedia security and privacy issues.
Can we think of having better prompts with better defaults, and maybe some page provided hints? 

2. From what I am hearing, a new method has benefits in terms of extensibility.
Can we list these more specifically? Are there other benefits?

3. If we think we should introduce new permissions and feature policies, a new method might be worthwhile.
For instance, is there a case where a top level page would like to delegate same-tab sharing but not screen sharing? Or the reverse?

4. In MacOS Safari, there is UI to allow/deny/ask for camera, microphone and screen sharing.
I am for instance wondering how we would present this new capability in that context.

> On 6 Oct 2020, at 11:29, Henrik Boström <hbos@google.com <mailto:hbos@google.com>> wrote:
> 
> With regards to security and privacy, I think having an API where screen sharing is limited to only the browsing context of interest is great for reducing the risk of accidentally sharing the wrong window or tab which can easily happen when sharing "entire screen" for example.
> 
> On Tue, Oct 6, 2020 at 9:25 AM Henrik Boström <hbos@google.com <mailto:hbos@google.com>> wrote:
> 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 <mailto: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 <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