Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

['Elad Alon' via blink-dev]

This is shipping in m105.

On Thursday, June 23, 2022 at 10:28:26 AM UTC+2 Elad Alon wrote:

> Thanks you all!
>
> On Tuesday, June 21, 2022 at 6:45:57 PM UTC+2 Chris Harrelson wrote:
>
>> LGTM3
>>
>> On Thu, Jun 16, 2022 at 5:12 AM Mike Taylor  wrote:
>>
>>> LGTM2
>>>
>>> On 6/16/22 9:42 AM, Yoav Weiss wrote:
>>>
>>> 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.
>>>
>>> On Thu, Jun 16, 2022 at 9:27 AM Elad Alon  wrote:
>>>
 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

 On Wednesday, June 8, 2022 at 5:47:49 PM UTC+2 sligh...@chromium.org 
 wrote:

> Thanks Harald and Elad. 
>
> On Thursday, June 2, 2022 at 5:19:17 AM UTC-7 Harald Alvestrand wrote:
>
>> 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  
>> wrote:
>>
>>> 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
>>>
>>>
>>> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>>>
 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.

 On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss  
 wrote:

> Let's give them 1 more week to respond.
>
> On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  
> wrote:
>
>> 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?
>>
>> On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> 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 (
 

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

['Elad Alon' via blink-dev]

Thanks you all!

On Tuesday, June 21, 2022 at 6:45:57 PM UTC+2 Chris Harrelson wrote:

> LGTM3
>
> On Thu, Jun 16, 2022 at 5:12 AM Mike Taylor  wrote:
>
>> LGTM2
>>
>> On 6/16/22 9:42 AM, Yoav Weiss wrote:
>>
>> 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.
>>
>> On Thu, Jun 16, 2022 at 9:27 AM Elad Alon  wrote:
>>
>>> 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
>>>
>>> On Wednesday, June 8, 2022 at 5:47:49 PM UTC+2 sligh...@chromium.org 
>>> wrote:
>>>
 Thanks Harald and Elad. 

 On Thursday, June 2, 2022 at 5:19:17 AM UTC-7 Harald Alvestrand wrote:

> 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  
> wrote:
>
>> 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
>>
>>
>> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>>
>>> 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.
>>>
>>> On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss  
>>> wrote:
>>>
 Let's give them 1 more week to respond.

 On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  
 wrote:

> 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?
>
> On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss  
> wrote:
>
>>
>>
>> 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 

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

[Chris Harrelson]

LGTM3

On Thu, Jun 16, 2022 at 5:12 AM Mike Taylor  wrote:

> LGTM2
>
> On 6/16/22 9:42 AM, Yoav Weiss wrote:
>
> 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.
>
> On Thu, Jun 16, 2022 at 9:27 AM Elad Alon  wrote:
>
>> 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
>>
>> On Wednesday, June 8, 2022 at 5:47:49 PM UTC+2 sligh...@chromium.org
>> wrote:
>>
>>> Thanks Harald and Elad.
>>>
>>> On Thursday, June 2, 2022 at 5:19:17 AM UTC-7 Harald Alvestrand wrote:
>>>
 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 
 wrote:

> 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
>
>
> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>
>> 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.
>>
>> On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss 
>> wrote:
>>
>>> Let's give them 1 more week to respond.
>>>
>>> On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  wrote:
>>>
 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?

 On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss 
 wrote:

>
>
> 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 (

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

[Mike Taylor]

LGTM2

On 6/16/22 9:42 AM, Yoav Weiss wrote:
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.


On Thu, Jun 16, 2022 at 9:27 AM Elad Alon  wrote:

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

On Wednesday, June 8, 2022 at 5:47:49 PM UTC+2
sligh...@chromium.org wrote:

Thanks Harald and Elad.

On Thursday, June 2, 2022 at 5:19:17 AM UTC-7 Harald
Alvestrand wrote:

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
 wrote:

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


On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad
Alon wrote:

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.

On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss
 wrote:

Let's give them 1 more week to respond.

On Wed, Jun 1, 2022 at 9:21 AM Elad Alon
 wrote:

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?

On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss
 wrote:



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

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

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

On Thu, Jun 16, 2022 at 9:27 AM Elad Alon  wrote:

> 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
>
> On Wednesday, June 8, 2022 at 5:47:49 PM UTC+2 sligh...@chromium.org
> wrote:
>
>> Thanks Harald and Elad.
>>
>> On Thursday, June 2, 2022 at 5:19:17 AM UTC-7 Harald Alvestrand wrote:
>>
>>> 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 
>>> wrote:
>>>
 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


 On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:

> 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.
>
> On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss 
> wrote:
>
>> Let's give them 1 more week to respond.
>>
>> On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  wrote:
>>
>>> 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?
>>>
>>> On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss 
>>> wrote:
>>>


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

> Contact emailselad...@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 componentBlink
> 
>
> TAG reviewN/A. This is just an addition of a single flag to an
> existing dictionary, following well-known patterns.
>
> TAG review statusNot 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 

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

['Elad Alon' via blink-dev]

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

On Wednesday, June 8, 2022 at 5:47:49 PM UTC+2 sligh...@chromium.org wrote:

> Thanks Harald and Elad. 
>
> On Thursday, June 2, 2022 at 5:19:17 AM UTC-7 Harald Alvestrand wrote:
>
>> 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  
>> wrote:
>>
>>> 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
>>>
>>>
>>> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>>>
 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.

 On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss  wrote:

> Let's give them 1 more week to respond.
>
> On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  wrote:
>
>> 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?
>>
>> On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss  
>> wrote:
>>
>>>
>>>
>>> On Wednesday, May 25, 2022 at 2:38:53 PM UTC+2 Elad Alon wrote:
>>>
 Contact emailselad...@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 componentBlink 
 

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

 TAG review statusNot 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.

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

['Harald Alvestrand' via blink-dev]

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 
wrote:

> 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
>
>
> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>
>> 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.
>>
>> On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss  wrote:
>>
>>> Let's give them 1 more week to respond.
>>>
>>> On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  wrote:
>>>
 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?

 On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss 
 wrote:

>
>
> On Wednesday, May 25, 2022 at 2:38:53 PM UTC+2 Elad Alon wrote:
>
>> Contact emailselada...@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 componentBlink
>> 
>>
>> TAG reviewN/A. This is just an addition of a single flag to an
>> existing dictionary, following well-known patterns.
>>
>> TAG review statusNot 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.
>
>
>> *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 

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

['Elad Alon' via blink-dev]

>
> 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!

On Wed, Jun 1, 2022 at 7:15 PM Chris Harrelson 
wrote:

>
>
> On Wed, Jun 1, 2022 at 9:40 AM 'Elad Alon' via blink-dev <
> blink-dev@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.
>
>
>>
>> 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
>>
>> On Wed, Jun 1, 2022 at 6:13 PM Alex Russell 
>> wrote:
>>
>>> 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
>>>
>>>
>>> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>>>
 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.

 On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss 
 wrote:

> Let's give them 1 more week to respond.
>
> On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  wrote:
>
>> 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?
>>
>> On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss 
>> wrote:
>>
>>>
>>>
>>> On Wednesday, May 25, 2022 at 2:38:53 PM UTC+2 Elad Alon wrote:
>>>
 Contact emailselada...@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 componentBlink
 

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

 TAG review statusNot 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 

Re: [blink-dev] Re: Intent to Ship: DisplayMediaStreamConstraints.systemAudio

[Chris Harrelson]

On Wed, Jun 1, 2022 at 9:40 AM 'Elad Alon' via blink-dev <
blink-dev@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.


>
> 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
>
> On Wed, Jun 1, 2022 at 6:13 PM Alex Russell 
> wrote:
>
>> 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
>>
>>
>> On Wednesday, June 1, 2022 at 12:35:24 AM UTC-7 Elad Alon wrote:
>>
>>> 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.
>>>
>>> On Wed, Jun 1, 2022 at 9:29 AM Yoav Weiss 
>>> wrote:
>>>
 Let's give them 1 more week to respond.

 On Wed, Jun 1, 2022 at 9:21 AM Elad Alon  wrote:

> 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?
>
> On Wed, Jun 1, 2022 at 8:30 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Wednesday, May 25, 2022 at 2:38:53 PM UTC+2 Elad Alon wrote:
>>
>>> Contact emailselada...@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 componentBlink
>>> 
>>>
>>> TAG reviewN/A. This is just an addition of a single flag to an
>>> existing dictionary, following well-known patterns.
>>>
>>> TAG review statusNot 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.
>>
>>
>>> *Web developers*: Positive Endorsed by