This is shipping in m109.

On Wednesday, June 22, 2022 at 7:20:42 PM UTC+2 Elad Alon wrote:

> When I have an exact date, I will update ChromeStatus and ping this thread 
> with the target. Currently, I only know that it will be before EoY, but no 
> earlier than August.
>
> On Wed, Jun 22, 2022 at 7:16 PM Joe Medley <[email protected]> wrote:
>
>> When do you hope to ship this?
>> Joe Medley | Technical Writer, Chrome DevRel | [email protected] | 
>> 816-678-7195 <(816)%20678-7195>
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Wed, Jun 22, 2022 at 9:14 AM Daniel Bratell <[email protected]> wrote:
>>
>>> LGTM3
>>>
>>> /Daniel
>>> On 2022-06-22 17:42, Yoav Weiss wrote:
>>>
>>> LGTM2
>>>
>>> On Wednesday, June 22, 2022 at 5:41:51 PM UTC+2 Chris Harrelson wrote:
>>>
>>>> LGTM1
>>>>
>>>> On Tue, Jun 14, 2022 at 4:11 AM 'Andy Paicu' via blink-dev <
>>>> [email protected]> wrote:
>>>>
>>>>> Sounds good, thank you for the clarifications. 
>>>>>
>>>>> Kind Regards, 
>>>>> Andy Paicu
>>>>>
>>>>>
>>>>> On Mon, Jun 13, 2022 at 8:18 PM Elad Alon <[email protected]> wrote:
>>>>>
>>>>>> Hi Andy,
>>>>>>
>>>>>> How does the capturing web app (i.e. Meet) know what I want to do 
>>>>>>> with audio?
>>>>>>
>>>>>>  
>>>>>> The capturing application might know that you're in a physical room 
>>>>>> and "presenting" to the equipment there. 
>>>>>>
>>>>>>    - You use a special user-journey to trigger sharing to a room. 
>>>>>>    - The application could be "watermarking" audio coming in through 
>>>>>>    the room's speakers. 
>>>>>>    - You might have indicated a desire to suppress-local-audio 
>>>>>>    through in-content controls the application exposes. 
>>>>>>
>>>>>> In either case, it is extremely likely that you only want to hear the 
>>>>>> audio only through one set of speakers. The application would be saving 
>>>>>> you 
>>>>>> effort by muting one set of speakers for you.
>>>>>>
>>>>>> This seems like it would be better under the control of the user
>>>>>>
>>>>>>
>>>>>> Users can mute tabs manually. This new API surface will not prevent 
>>>>>> this.
>>>>>>
>>>>>> i.e. Meet
>>>>>>
>>>>>>
>>>>>> It bears mentioning that Meet is currently using screen-sharing 
>>>>>> through an API which I am trying to deprecate. That API already 
>>>>>> hard-codes 
>>>>>> to *always* suppress-local-audio on a captured tab. The present new 
>>>>>> API surface improves on the state of the art by (i) making this 
>>>>>> conditional 
>>>>>> and (ii) exposing it to the Web at large.
>>>>>>
>>>>>> Thanks,
>>>>>> Elad
>>>>>>
>>>>>> On Mon, Jun 13, 2022 at 8:02 PM Andy Paicu <[email protected]> 
>>>>>> wrote:
>>>>>>
>>>>>>> A question came up when reviewing this, I'm hoping you can help 
>>>>>>> clarify: 
>>>>>>>
>>>>>>> How does the capturing web app (i.e. Meet) know what I want to do 
>>>>>>> with audio? Would I not be able to achieve the same result by simply 
>>>>>>> muting 
>>>>>>> the tab or even just muting the device (since it seems unlikely that 
>>>>>>> there 
>>>>>>> are other sounds wanted from the local device when sharing a tab with 
>>>>>>> audio)?
>>>>>>>
>>>>>>> This seems like it would be better under the control of the user 
>>>>>>> instead of being a decision made by the application especially since I 
>>>>>>> don't see a mention of how this would be presented to the user and/or 
>>>>>>> potentially reverted by them.
>>>>>>>
>>>>>>> Kind Regards,
>>>>>>> Andy Paicu
>>>>>>>
>>>>>>> On Wednesday, June 1, 2022 at 9:40:02 AM UTC+2 Elad Alon wrote:
>>>>>>>
>>>>>>>> Similar to other intents, this doesn't count as an official 
>>>>>>>>> positive signal. Let's wait a few days to see if one emerges.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks. I've set a reminder to ping this thread in one week, as 
>>>>>>>> suggested in the other intent thread.
>>>>>>>>
>>>>>>>> On Wed, Jun 1, 2022 at 8:42 AM Yoav Weiss <[email protected]> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wednesday, May 25, 2022 at 2:44:01 PM UTC+2 Elad Alon wrote:
>>>>>>>>>
>>>>>>>>>> Contact emails [email protected]
>>>>>>>>>>
>>>>>>>>>> Explainer 
>>>>>>>>>> https://docs.google.com/document/d/1OmuV1W4f2UvToeNxUVGHv8NcFuL63r94gWwz9i_-VBc/edit?usp=sharing
>>>>>>>>>>
>>>>>>>>>> Specification 
>>>>>>>>>> https://github.com/w3c/mediacapture-screen-share/pull/164/files
>>>>>>>>>>
>>>>>>>>>> Summary 
>>>>>>>>>>
>>>>>>>>>> Consider a Web application APP which is display-capturing a tab 
>>>>>>>>>> TAB. We add a mechanism by which APP may control whether the audio 
>>>>>>>>>> playing 
>>>>>>>>>> in TAB would be played out of the user’s local speakers. 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Blink component Blink 
>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=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/641) 
>>>>>>>>>> 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/032252.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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Similar to other intents, this doesn't count as an official 
>>>>>>>>> positive signal. Let's wait a few days to see if one emerges.
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Web developers*: Positive
>>>>>>>>>>
>>>>>>>>>>    - This was requested by multiple Web-dev teams inside of 
>>>>>>>>>>    Google. 
>>>>>>>>>>    - External developers have asked for a different change in 
>>>>>>>>>>    Chrome, which we'll be able to uncontroversially affect only once 
>>>>>>>>>> this API 
>>>>>>>>>>    surface is shipped - see crbug.com/1317964 for some details. 
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> That's encouraging!
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Other signals*:
>>>>>>>>>>
>>>>>>>>>> WebView application risks 
>>>>>>>>>>
>>>>>>>>>> N/A
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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 
>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>>>>>>>> ? No
>>>>>>>>>>
>>>>>>>>>> Estimated milestones 
>>>>>>>>>>
>>>>>>>>>> No milestones specified
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Link to entry on the Chrome Platform Status 
>>>>>>>>>> https://chromestatus.com/feature/5201258309746688
>>>>>>>>>>
>>>>>>>>>> Links to previous Intent discussions Intent to prototype: 
>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/cANVKeNMHyE
>>>>>>>>>>
>>>>>>>>>> This intent message was generated by Chrome Platform Status 
>>>>>>>>>> <https://chromestatus.com/>.
>>>>>>>>>>
>>>>>>>>> -- 
>>>>> 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 [email protected].
>>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACnmqYiUCZ_En3oei9xgn9T5CH9t%3D4FNb50RzHDdg%3DE69mL62A%40mail.gmail.com
>>>>>  
>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACnmqYiUCZ_En3oei9xgn9T5CH9t%3D4FNb50RzHDdg%3DE69mL62A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> -- 
>>> 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 [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05fcc18f-d8e7-426a-a04e-d636433cd01en%40chromium.org
>>>  
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05fcc18f-d8e7-426a-a04e-d636433cd01en%40chromium.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> -- 
>>> 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 [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a5ad483c-7ad9-7412-df6f-e25be1c15f86%40gmail.com
>>>  
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a5ad483c-7ad9-7412-df6f-e25be1c15f86%40gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b4f67af0-16ef-436f-b184-90b7064c5a1bn%40chromium.org.

Reply via email to