Summary of Call for Adoption: Region Capture specification

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."