Intent to Extend Experiment: Capture Handle

[Elad Alon]

Contact emails

elad...@chromium.org

Explainer

https://github.com/WICG/capture-handle/blob/main/README.md

Specification

https://wicg.github.io/capture-handle/

Summary

We introduce a mechanism that allows an application to opt-in to exposing certain information to other applications which are video-capturing it. This allows collaboration between capturing and captured applications. For example, a VC application that's video-capturing a tab where a presentation application lives, could expose user-facing controls in the VC tab for navigating the presentation in the captured tab.

Blink component

Blink>GetUserMedia>Tab

TAG review

https://github.com/w3ctag/design-reviews/issues/645

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Reason this experiment is being extended

Enthusiastic support for the feature: https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354 Efforts to build useful features on top of this new API are still ongoing.

Request extension m95-m97 (three months).

Debuggability

No DevTools support is needed.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Supported on all Desktop platforms. Not supported on any Mobile platform.

Is this feature fully tested by web-platform-tests?

No

Flag name

CaptureHandle

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1200910

Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1200907

Estimated milestones

OriginTrial desktop first	92
OriginTrial desktop last	94

Request extension m95-m97 (three months).

Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/4854125411958784

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/yLTykllpNmI
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/RKONugfoGwM/m/mpFizHPxAwAJ

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Mon, Aug 16, 2021 at 11:42 PM 'Elad Alon' via blink-dev <blin...@chromium.org> wrote:

Contact emails

elad...@chromium.org

Explainer

https://github.com/WICG/capture-handle/blob/main/README.md

Specification

https://wicg.github.io/capture-handle/

Summary

We introduce a mechanism that allows an application to opt-in to exposing certain information to other applications which are video-capturing it. This allows collaboration between capturing and captured applications. For example, a VC application that's video-capturing a tab where a presentation application lives, could expose user-facing controls in the VC tab for navigating the presentation in the captured tab.

Blink component

Blink>GetUserMedia>Tab

TAG review

https://github.com/w3ctag/design-reviews/issues/645

TAG review status

Pending

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Have we reached out? https://bit.ly/blink-signals is not required for an experiment, but may be good to reach out nevertheless.

Web developers: No signals

I'd say https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354/ gives you a strong positive signal..

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDOMkgjL_HUMohx4hk7tbC__M53aX3NEiGxeTPfw8nJUHw%40mail.gmail.com.

[Elad Alon]

Thanks, Yoav.

Yes, I intend to formally reach out to Mozilla and Apple soon.

Agreed about strong positive signals from developers.

[Yoav Weiss]

LGTM to continue experimenting.

Note that it might be worthwhile to stop the experiment at some point, as that could "reset the clock" in terms of burn-in risk, and enable an overall longer experimentation period.

[Elad Alon]

Thank you, Yoav, for this suggestion about resetting the clock. We would like to now do just that, pausing the experiment 2021-11-01 to 2021-11-21, and restarting it again on 2021-11-22. We would like to experiment for 4 milestones (96 to 99, inclusive). However, if it's possible to also have the experiment active for older milestones during this time, that would be nice, too.

[Elad Alon]

If 2021-11-01 is too short-notice by now, we could also do 2021-08 to 2021-11-28.

[Yoav Weiss]

LGTM to break the experiment 2021-11-08 to 2021-11-28 (I'm guessing it's to late to aim for the 1st, apologies for not responding earlier).

Also LGTM to experiment for 4 milestones after that, till M99, inclusive.

On Thursday, October 28, 2021 at 11:38:49 PM UTC+3 Elad Alon wrote:

If 2021-11-01 is too short-notice by now, we could also do 2021-08 to 2021-11-28.

On Wednesday, October 27, 2021 at 4:08:38 PM UTC+2 Elad Alon wrote:

Thank you, Yoav, for this suggestion about resetting the clock. We would like to now do just that, pausing the experiment 2021-11-01 to 2021-11-21, and restarting it again on 2021-11-22. We would like to experiment for 4 milestones (96 to 99, inclusive). However, if it's possible to also have the experiment active for older milestones during this time, that would be nice, too.

Can you clarify what you mean by "during this time"? During the break, or after it?

[Elad Alon]

After the break. If code could work not only for m96-m99, but rather for m92-m99, during the calendar time of m96-m99, that would be nice. But it's not critical. I am just thinking that the OT process is probably intended to look more at time than actual milestones, so possibly we could tweak the rules to reflect that? But this might be a larger discussion to be had elsewhere, and not specifically to this feature. Up to you!

[Yoav Weiss]

If the current status quo is that OTs are exposed on older milestones during the time they are enabled (e.g. for users that haven't updated their browser), then from my perspective, the break in the OT's availability should not change that. (I think that's the case ATM, but not sure).

If it isn't the case, changing it merits a broader discussion.

[Jason Chase]

Currently, origin trials are time-bound, not version-bound. That is, trial tokens contain an expiry date that applies regardless of the Chrome version.

In this case, the break in availability would be done by remote update that disables the trial. We can target that update to specific Chrome versions. So, it is possible to leave the trial enabled on older versions, while newer versions have the break enforced, and then have the trial re-enabled on all versions.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ecba514a-77be-4f6a-b3a2-faeb56ecc7f2n%40chromium.org.

[Yoav Weiss]

Thanks! I think it's important to have the trial break in all versions, so the current default OT configuration you described SGTM

[Elad Alon]

The "old" versions (m92-m95) are the only versions that are currently out, so breaking for anything else would be breaking in theory only. What I am asking for is:

• Break 2021-11-08 to 2021-11-28, all versions.
• Re-enable on 2021-11-29 for m92-m99. (Using m92 instead of m96 as the lower-bound is the "special" part of my request here.)
  

Jason, Yoav, wdyt?

[Yoav Weiss]

LGTM

[Jason Chase]

Yes, that works for deploying the OT updates.