Intent to Ship: Make CaptureController derive from the EventTarget interface

[Frédéric Wang]

Contact emails

fw...@chromium.org

Explainer

None

Specification

https://w3c.github.io/mediacapture-screen-share/#dom-capturecontroller

Summary

The CaptureController interface enables further manipulation of a screen capture session. In the future, it is expected that the events related to a capture session are dispatched on that controller. To be able to manage listeners for such events, the EventTarget methods are made available on CaptureController.

Blink component

Blink>GetDisplayMedia

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/screen-share/mouse-events/issues/1)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Debuggability

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

Yes

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

Yes

Flag name on chrome://flags

Finch feature name

Non-finch justification

Small IDL change that don't affect existing use cases of CaptureController.

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop

117

Shipping on Android

117

Shipping on WebView

117

Shipping on WebView

117

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5139210809376768

Links to previous Intent discussions

This intent message was generated by Chrome Platform Status.

-- 
Frédéric Wang

[Frédéric Wang]

Hello,

To elaborate a bit more on this, it's a small IDL change to make the CaptureController interface derive from the EventTarget interface:

https://github.com/w3c/mediacapture-screen-share/issues/268
https://docs.google.com/presentation/d/1lti3-GFsJ1iU2pXFjfSzeK8xyKj6Ohng9D6HndPNPLc/edit#slide=id.g2547a9cc7f2_1_15

The main use case is to implement CapturedMouseEvent, but that extra inheritance cannot be controlled by a runtime flag.

https://groups.google.com/a/chromium.org/g/blink-dev/c/DYb5fXICJvo

This change was discussed in today's WebRTC WG meeting (with other potential use cases mentioned) and approved, with PR pending to be merged:
https://docs.google.com/presentation/d/1lti3-GFsJ1iU2pXFjfSzeK8xyKj6Ohng9D6HndPNPLc/edit#slide=id.g2547a9cc7f2_1_15
https://github.com/w3c/mediacapture-screen-share/pull/269
https://github.com/w3c/mediacapture-screen-share/issues/268

In general Web developers from the Screen Capture CG are supportive of this and interested in related future applications. Some members of Mozilla and Apple were also present in W3C meetings where this was discussed and they OK'ed the change. However, since I didn't open a Mozilla/Apple position to get official stance for such a small feature, I left "No Signal".

Chromium's CL is https://chromium-review.googlesource.com/c/chromium/src/+/4542243/12

Thanks,

--
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/b6bbda72-2f28-b04c-dbed-a02da71b7cb5%40igalia.com.

-- 
Frédéric Wang

[Yoav Weiss]

LGTM1 after the PR lands.

Thanks for the extra context!!

This is a tiny change, with extremely low compat risk (developers would have to explicitly check for CaptureController's inheritance for this change to break existing code) and which the WG seems to be on board with.

As such, one can argue that this isn't really web-exposed (despite the IDL changes). At the same time, the lack of a technical way for us to gate IDL inheritance behind a flag raises the risk a bit, so maybe this merits an intent. I'd love other API owners' opinions on that..

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b6bbda72-2f28-b04c-dbed-a02da71b7cb5%40igalia.com.

-- 
Frédéric Wang

[Chris Harrelson]

LGTM2

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/b6bbda72-2f28-b04c-dbed-a02da71b7cb5%40igalia.com.

-- 
Frédéric Wang

--
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/b85deb0d-3928-4230-97bb-80f3fbf97711n%40chromium.org.

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9M32goMMUS7%3D72mbodRFgG0wn0LLveudU1sUJBZopyKg%40mail.gmail.com.