Re: Summary of Call for Adoption: Region Capture specification

I there's benefit in choosing an API shape that (i) works well for
getDisplayMedia-self-capture, (ii) is trivially expandable to
getViewportMedia when the time comes without introducing a new API, and
(iii) can be generalized to getDisplayMedia-any-tab-capture when the time
comes. The current proposal gives us that.

Youenn, if I understand your last email correctly, you would withdraw your
objection if the proposal is expanded to work for getDisplayMedia-any-tab.
While that was my intention
<https://eladalon1983.github.io/region-capture/#future-extensions> all
along, it's unclear to me that this is a productive way to layer the work.
What if someone else then changes their initial yay to a nay because they
do not (yet) like the way we address other-tab-cropping? The way to move
forward, IMHO, is to start small, adopt the document and iterate. That
said, if Bernard and Jan-Ivar are OK with increasing the initial scope to
any-tab-capture off the bat, and you withdraw your objection based on that,
of course I'd be very happy to do so. But please clarify whether that would
be enough to resolve your objection.

On Wed, Dec 15, 2021 at 6:00 PM Youenn Fablet <youenn@apple.com> wrote:

> 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
>
> The CfA ended on December 13, 2021.
>
> 7 individuals indicated support:
>
>    - Elad Alon:
>    https://lists.w3.org/Archives/Public/public-webrtc/2021Nov/0062.html
>    - Harald Alvestrand:
>    https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0000.html
>    - Bernard Aboba:
>    https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0001.html
>    - Lindsay Hall:
>    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
>    - Jan-Ivar Bruaroey (concern raised):
>    https://lists.w3.org/Archives/Public/public-webrtc/2021Dec/0027.html
>    - Tim Panton:
>    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
>
> 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
>
> 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."
>
>
>