Re: Summary of Call for Adoption: Region Capture specification

One way to resolve my opposition would be to clarify what the scope of the work is.
The options that seem to be discussed are: self capture only, any tab capture, any tab capture + getViewPortMedia.

As currently underspecified, I would not consider getViewPortMedia in scope of this work.
This can be revisited when we have a clearer definition of getViewPortMedia.

AIUI, the specification is currently targeted at self capture for getDisplayMedia.
Introducing API that only work for self capture will make applications more and more relying on ways to ensure the user selects the current tab.
So far, I think we are very hesitant to introduce a ’select the current tab’ option so I am reluctant to go with self capture only.

On the other hand, I think we are reaching consensus on allowing web applications to influence UA picker to select tabs.
Clearly defining the scope to any tab capture for getDisplayMedia would be consistent with this.

Thanks,
 Y

> On 15 Dec 2021, at 02:12, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:
> 
> A Call for Adoption (CfA) of the Region Capture specification was announced on November 30, 2021:
> https://lists.w3.org/Archives/Public/public-webrtc/2021Nov/0060.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Nov/0060.html>
> 
> The CfA ended on December 13, 2021. 
> 
> 7 individuals indicated support: 
> Elad Alon: https://lists.w3.org/Archives/Public/public-webrtc/2021Nov/0062.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Nov/0062.html>
> Harald Alvestrand: https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0000.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0000.html>
> Bernard Aboba: https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0001.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0001.html>
> Lindsay Hall: https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0003.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0003.html>
> Mark A. Foltz: https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0004.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0004.html>
> Jan-Ivar Bruaroey (concern raised): https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0027.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0027.html>
> Tim Panton: https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0029.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0029.html>
> 1 individual indicated an objection: 
> Youenn Fablet: https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0028.html <https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0028.html>
> During today's WEBRTC WG meeting, we discussed Youenn's objection and Jan-Ivar's concern.  
> 
> Elad indicated that Region Capture was in Origin Trial in Chromium M97, based on getDisplayMedia(), limited to self-Tab capture only (no screen, application or other tab capture). 
> 
> Origin Trial info is: See: https://groups.google.com/a/chromium.org/g/blink-dev/c/yFUX0KfuUlo?pli=1 <https://groups.google.com/a/chromium.org/g/blink-dev/c/yFUX0KfuUlo?pli=1>
> 
> Elad will clarify the limitations on getDisplayMedia as well as dependencies on other work and security implications (e.g. what happens when navigating to another page). 
> 
> The Chairs will discuss next steps. 
> 
> 
> Youenn's objection: 
> 
> "I think the use case is worth fixing, but I have concerns with the current API shape.
> In general, it seems to me that region capture is not needed for getViewPortMedia and requires Capture Handle for getDisplayMedia.
> Therefore, it seems better to work on:
> - getViewPortMedia: in particular how it can select the parts to capture potentially dynamically.
> - capture handle to hook up capturing and captured pages for getDisplayMedia, then on how captured page can express its preferred regions worth being cropped to.
> 
> For getViewPortMedia, dynamic capture can be done with element references, IDs or element classes so that changing the DOM or element attributes impact getViewPortMedia results.
> For getDisplayMedia, if we want to go there, it seems more meaningful to let the captured page tell the User-Agent which regions might be of interest to be cropped, possibly in advance, with origin safeguards/opt-ins... The User-Agent can then directly expose this information in the capturing page (using CaptureHandle) and let the capturing page decide which regions to select."
> 
> Jan-Ivar's concern: 
> 
> "I'd prefer if the feature was kept to getViewportMedia where it lets
> applications crop to a page it has direct control over, which makes a lot
> of sense.
> 
> It seems less of a good fit in getDisplayMedia's tab capture as currently
> implemented in most browsers, where it risks exacerbating potential user
> confusion over what's being captured: the current document as opposed to
> all navigation in the containing tab. It's really the latter that is being
> captured, and a cropping feature in this context doesn't make a lot of
> sense, and becomes overly complicated. If it's implemented there, I hope it
> will be temporary and that we can eventually move to a safer, less
> confusing model over time."