Intent to Ship: DisplayMediaStreamConstraints.systemAudio

[Elad Alon]

Contact emails

elad...@chromium.org

Explainer

https://docs.google.com/document/d/1q3oGy7hLJmdQA4ZK7QG7DnwgtcpL6oB2pqLQJ6MP1tY/edit?usp=sharing

Specification

https://github.com/w3c/mediacapture-screen-share/pull/222/files

Summary

Hint indicating to the user agent whether the application, upon calling getDisplayMedia() with {audio: true} or similar, wishes *system audio* to be offered to the user. (If not - only offer tab-audio.)

Blink component

Blink

TAG review

N/A. This is just an addition of a single flag to an existing dictionary, following well-known patterns.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/638) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered.

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2022-May/032247.html) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered.

Web developers: Positive Endorsed by Google Meet.

Security

This feature can only be used by Web applications to REDUCE the amount of private information they obtain from the user. As such, this is a net security gain.

Debuggability

N/A

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

No. Supported on all platforms that support getDisplayMedia. (Namely, all desktop platforms.)

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

No

Tracking bug

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

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4649448880734208

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/zUJh3aXAC3k

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

On Wednesday, May 25, 2022 at 2:38:53 PM UTC+2 Elad Alon wrote:

Contact emails

elad...@chromium.org

Explainer

https://docs.google.com/document/d/1q3oGy7hLJmdQA4ZK7QG7DnwgtcpL6oB2pqLQJ6MP1tY/edit?usp=sharing

Specification

https://github.com/w3c/mediacapture-screen-share/pull/222/files

Summary

Hint indicating to the user agent whether the application, upon calling getDisplayMedia() with {audio: true} or similar, wishes *system audio* to be offered to the user. (If not - only offer tab-audio.)

Blink component

Blink

TAG review

N/A. This is just an addition of a single flag to an existing dictionary, following well-known patterns.

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/638) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered.

WebKit: Positive (https://lists.webkit.org/pipermail/webkit-dev/2022-May/032247.html) Jan-Ivar Bruaroey from Mozilla, and Youenn Fablet from Apple, have both collaborated with us closely in shaping this PR. They have then approved merging this PR into w3c/mediacapture-screen-share. This is implicit support, so I'd consider it POSITIVE even though, as of the time of this writing, the official request for position has not yet been answered.

While encouraging, neither counts as a positive position based on https://bit.ly/blink-signals

It might be good to give them a few more days to chime in.

[Elad Alon]

Okay, will do. (I've also sent a personal email on the day the intent went out.)

When shall I ping this thread if no response is received?

[Yoav Weiss]

Let's give them 1 more week to respond.

[Elad Alon]

I've set my alarm.

I'll implicitly assume the same period is intended for the other three intents-to-ship sent at roughly the same time.

[Alex Russell]

Hey Elad,

This is a pretty simple design, and it's great to see the progress here. That said, this group of intents (systemAudio, suppressLocalAudioPlayback, and selfBrowserSurface) would benefit from a joint explainer with considered alternatives outlined. The TAG might not have much to say about small changes, but our process asks teams to at least send them an FYI for non-controversial updates so that they can consider how parts fit together in future.

Given that the WebRTC group has a history of trying to skip TAG review, it doesn't seem right for this set of features to launch without some intentional design review. Can you file a request with them or get several of the current and former TAG members (Rossen, David, Alice, myself, or Domenic) in the project to review the design directly?

Thanks

[Elad Alon]

Hi Alex,

Yes, I can initiate TAG review. Would it work for you if I initiated one TAG review-request that referenced all four intents? Or alternatively, four TAG requests? My own feeling is that a joint explainer might be a bit confusing, since the four surfaces are not very closely related. I don't feel strongly about this, however, and I can set up a joint explainer if you don't think it would lead to confusion.

Full disclosure: There's also a fifth one in the pipeline which I've not yet sent because the PR has not yet been merged.

Thanks,

Elad

[Chris Harrelson]

On Wed, Jun 1, 2022 at 9:40 AM 'Elad Alon' via blink-dev <blin...@chromium.org> wrote:

Hi Alex,

Yes, I can initiate TAG review. Would it work for you if I initiated one TAG review-request that referenced all four intents? Or alternatively, four TAG requests?

I think one TAG review would be ok. All of these intents look to be hints presented to the UA to help the UA's UI be easier for the user to navigate/avoid pitfalls. Is that accurate?

If so, they also seem quite low risk and simple to review as well.

 

My own feeling is that a joint explainer might be a bit confusing, since the four surfaces are not very closely related. I don't feel strongly about this, however, and I can set up a joint explainer if you don't think it would lead to confusion.

I personally thought your explainers were quite readable and nice, and agree with you that they make sense when read individually.

 

--
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/CAMO6jDPLm8t5xKe4qX_OL-%2BRitdmad0S0HKBmDXrkYznDkZOWQ%40mail.gmail.com.

[Elad Alon]

Is that accurate?

Yes.

I think one TAG review would be ok.

One TAG review requested. 

I personally thought your explainers were quite readable and nice

Thanks! 

[Harald Alvestrand]

re webrtc trying to skip TAG review ... we were told at one point (a few years back, I think) that we were sending too many TAG reviews; I believe that at that point, something like 1/3 of the outstanding TAG reviews were on relatively small WebRTC features. I guess we scaled back too forcefully .... thanks for pointing out the desire to course-correct.

On Wed, Jun 1, 2022 at 6:13 PM Alex Russell <sligh...@chromium.org> wrote:

--

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/1dc008bf-e1f9-4d73-8b29-287cbf2e6f1fn%40chromium.org.

[Alex Russell]

Thanks Harald and Elad. 

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

[Elad Alon]

Hello Blink owners,

I am working to align getDisplayMedia() and the Extension API, to the point that deprecating the Hangouts Extension would be possible. It's going to be a gradual process with multiple changes required. Shipping this one particular API surface (systemAudio) in the next Chrome release would greatly expedite projected timelines, as it would unblock some other work.

I've spoken to Sangwhan (CCed), and it seems like TAG review is expected end-of-July - a significant delay. I am therefore asking that, out of the four intents recently sent, this one intent be approved without waiting for TAG. Wdys?

Thanks,
Elad

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

[Yoav Weiss]

LGTM1 to ship this without waiting on TAG feedback. Please add a feature flag just in case, and follow up on any TAG feedback in future milestones.

[Mike Taylor]

LGTM2

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

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4c6480fc-4f2b-6c66-0cda-ee54d32d0d29%40chromium.org.

[Elad Alon]

Thanks you all!

[Elad Alon]

This is shipping in m105.