Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

['Harald Alvestrand' via blink-dev]

Do we have trackable statistics on the usage of corporate policies?
ie if nobody uses the policy in 2 milestones, can we detect that and decide
that it is not needed and delete it, or will we be as unsure as we are now?


On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor  wrote:

> We don't know what we don't know, but it's not hard to imagine an in-house
> enterprise WebRTC application that is using "stats" or "track". Twilio is
> the breakage we know about (because a developer took the time to report a
> bug). Having a policy so an app continues to work while a fix is made is a
> good thing - and comes with the nice side effect of appearing on the
> Enterprise release notes, increasing awareness.
>
> On 2/4/23 3:28 AM, Harald Alvestrand wrote:
>
> What's the imagined scenario in which an enterprise policy would be
> useful?
>
> The only place I could imagine it being relevant is if there exists a
> WebRTC application that is only used within a single enterprise (neither
> hosting nor usage exists outside the enterprise), and that WebRTC
> application depends on non-upgraded Twilio libraries.
>
> I don't know that we have evidence that such applications exist.
>
>
>
> On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor  wrote:
>
>> I agree with Johnny that an enterprise policy would be useful, at least
>> for a few milestones.
>>
>> On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:
>>
>> I'm not sure an enterprise policy is appropriate - I see the same problem
>> with sunsetting the policy as with sunsetting the stat in general, and
>> usage of enterprise policies is (as far as I know) far more opaque to us
>> than origin trials or Finch feature usage.
>>
>>
>> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström 
>> wrote:
>>
>>>
>>>
>>> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
>>> Is there an enterprise policy in place for this deprecation already? If
>>> not, adding one seems appropriate given the challenges of rolling out even
>>> simple fixes in some enterprise environments.
>>>
>>> One does not exist at the moment but I can add one
>>> 
>>> .
>>>
>>>
>>> Thanks,
>>> Johnny
>>>
>>> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström 
>>> wrote:
>>> Delaying the enabled-by-default to M112 is fine by me but I'll wait for
>>> a resolution here before taking action. Currently it is enabled-by-default
>>> in Canary.
>>>
>>> On Friday, January 27, 2023 at 12:41:23 PM UTC+1
>>> philipp...@googlemail.com wrote:
>>> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
>>> h...@chromium.org>:
>>> *Contact emails*
>>> h...@chromium.org, h...@chromium.org
>>>
>>> *Background*
>>> I attempted to remove this feature before but had forgotten to file an
>>> intent to deprecate, background here
>>> .
>>>
>>> *Specification*
>>> The getStats() API spec is here  and
>>> it contains all the metrics. The deprecated metrics are also listed, but in
>>> the obsolete section
>>> .
>>> There's an open issue to remove obsolete metrics from the spec as soon as
>>> they are unshipped from modern browsers. This is considered a blocker for
>>> the document to reach Proposed Recommendation status.
>>>
>>> *Summary*
>>> WebRTC is a set of JavaScript APIs (spec
>>> ) that allow real-time communication
>>> between browsers. For the relevant metrics being removed, we're only
>>> talking about the WebRTC use case that is sending or receiving audio or
>>> video (typically Video Conferencing use cases), not the data channel use
>>> cases that is a popular WebRTC use case, since data channel only use cases
>>> would never have any tracks/streams.
>>>
>>> RTCPeerConnection.getStats() returns a map of string-to-objects, where
>>> each object is one of the dictionaries defined in the stats spec. The
>>> reason an app calls getStats() is mostly to report quality metrics (send
>>> and receive resolutions, bitrates, glitches, video QP, etc) which can be
>>> important for A/B experimentation. It can also be used in a way that
>>> impacts app logic or even UX inside the app. Most common use case I can
>>> think of: poll getStats() at 10 Hz and render volume bars for each
>>> participant based on volume levels from stats objects.
>>>
>>> The deprecation in question is to remove some stats objects that were
>>> made obsolete several years ago: all metrics on the "track" dictionary have
>>> been moved to non-obsolete objects ("inbound-rtp", "outbound-rtp",
>>> "media-source"). Reasons for wanting to deprecate include:
>>>
>>>- Spec-compliance: needed for browser implementations to align and
>>>for the spec to become Proposed Recommendation.
>>>- Web compat: Firefox never implement "track" or "steam"
>>>
>>> 

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Henrik Boström]

I have the same concern as Harald regarding corporate policies. Why not a 
Deprecation Origin Trial in that case for list of users and more concrete 
timeline?

On Tuesday, February 7, 2023 at 9:10:40 AM UTC+1 Harald Alvestrand wrote:

> Do we have trackable statistics on the usage of corporate policies?
> ie if nobody uses the policy in 2 milestones, can we detect that and 
> decide that it is not needed and delete it, or will we be as unsure as we 
> are now?
>
>
> On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor  wrote:
>
>> We don't know what we don't know, but it's not hard to imagine an 
>> in-house enterprise WebRTC application that is using "stats" or "track". 
>> Twilio is the breakage we know about (because a developer took the time to 
>> report a bug). Having a policy so an app continues to work while a fix is 
>> made is a good thing - and comes with the nice side effect of appearing on 
>> the Enterprise release notes, increasing awareness.
>>
>> On 2/4/23 3:28 AM, Harald Alvestrand wrote:
>>
>> What's the imagined scenario in which an enterprise policy would be 
>> useful? 
>>
>> The only place I could imagine it being relevant is if there exists a 
>> WebRTC application that is only used within a single enterprise (neither 
>> hosting nor usage exists outside the enterprise), and that WebRTC 
>> application depends on non-upgraded Twilio libraries.
>>
>> I don't know that we have evidence that such applications exist.
>>
>>
>>
>> On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor  
>> wrote:
>>
>>> I agree with Johnny that an enterprise policy would be useful, at least 
>>> for a few milestones.
>>>
>>> On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:
>>>
>>> I'm not sure an enterprise policy is appropriate - I see the same 
>>> problem with sunsetting the policy as with sunsetting the stat in general, 
>>> and usage of enterprise policies is (as far as I know) far more opaque to 
>>> us than origin trials or Finch feature usage. 
>>>
>>>
>>> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  
>>> wrote:
>>>


 On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
 Is there an enterprise policy in place for this deprecation already? If 
 not, adding one seems appropriate given the challenges of rolling out even 
 simple fixes in some enterprise environments.

 One does not exist at the moment but I can add one 
 
 .


 Thanks,
 Johnny

 On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  
 wrote:
 Delaying the enabled-by-default to M112 is fine by me but I'll wait for 
 a resolution here before taking action. Currently it is enabled-by-default 
 in Canary.

 On Friday, January 27, 2023 at 12:41:23 PM UTC+1 
 philipp...@googlemail.com wrote:
 Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
 h...@chromium.org>:
 *Contact emails* 
 h...@chromium.org, h...@chromium.org

 *Background*
 I attempted to remove this feature before but had forgotten to file an 
 intent to deprecate, background here 
 .

 *Specification*
 The getStats() API spec is here  and 
 it contains all the metrics. The deprecated metrics are also listed, but 
 in 
 the obsolete section 
 .
  
 There's an open issue to remove obsolete metrics from the spec as soon as 
 they are unshipped from modern browsers. This is considered a blocker for 
 the document to reach Proposed Recommendation status.

 *Summary*
 WebRTC is a set of JavaScript APIs (spec 
 ) that allow real-time communication 
 between browsers. For the relevant metrics being removed, we're only 
 talking about the WebRTC use case that is sending or receiving audio or 
 video (typically Video Conferencing use cases), not the data channel use 
 cases that is a popular WebRTC use case, since data channel only use cases 
 would never have any tracks/streams.

 RTCPeerConnection.getStats() returns a map of string-to-objects, where 
 each object is one of the dictionaries defined in the stats spec. The 
 reason an app calls getStats() is mostly to report quality metrics (send 
 and receive resolutions, bitrates, glitches, video QP, etc) which can be 
 important for A/B experimentation. It can also be used in a way that 
 impacts app logic or even UX inside the app. Most common use case I can 
 think of: poll getStats() at 10 Hz and render volume bars for each 
 participant based on volume levels from stats objects.

 The deprecation in question is to remove some stats objects that were 
 made obsol

[blink-dev] Intent to Prototype: CSS headline balancing (`text-wrap: balance`)

[Koji Ishii]

Contact emailsko...@chromium.org

ExplainerNone

Specification
https://w3c.github.io/csswg-drafts/css-text-4/#valdef-text-wrap-balance

Summary

Enables the lengths of lines in a paragraph balanced, for better
readability and to prevent typographic widows. This feature is often used
in headlines.


Blink componentBlink>Layout>Inline


Motivation



Initial public proposal

TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility



*Gecko*: No signal

*WebKit*: No signal

*Web developers*: Positive (
https://twitter.com/jensimmons/status/1542264788029423616)

*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



Is this feature fully tested by web-platform-tests

?Yes

Flag name

Requires code in //chrome?False

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5196960707903488

This intent message was generated by Chrome Platform Status
.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dLq4OOXCNoYEWOnmb%3D6oxbSw1urndHj%3Dmb8JtowhRyBvQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebGPU

[Corentin Wallez]

Hey Rego,

The WebGPU CTS is meant to be exportable into a WPT subdirectory, see
https://github.com/gpuweb/cts/blob/main/docs/build.md. However I don't know
that there's a specific plan to integrate into WPT proper since development
uses a lot of combination testing and Typescript, which is not something
WPT support (the export step creates individual HTML pages for each test
case and compiles the Typescript to Javascript). +Kai Ninomiya
, feel free to correct me if I missed something.

Cheers,

Corentin

On Mon, Feb 6, 2023 at 5:55 PM Manuel Rego Casasnovas 
wrote:

>
>
> On 14/12/2022 18:02, Corentin Wallez wrote:
> > The WebGPU Conformance Test Suite is being built
> > at https://github.com/gpuweb/cts  and can
> > be integrated as a subdirectory of WPT. Coverage is still incomplete due
> > to the complexity of the API but progressing quickly. We expect to ship
> > with coverage holes, but with most important and risky aspects of
> > interoperability well tested.
>
> Any plans about integrating the test suite into WPT?
>
> Thanks,
>   Rego
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGdfWNMGYvc1PGpO6v5kH_kfpajjdPErP96U-HnrzR_CDQ-4EA%40mail.gmail.com.

Re: [blink-dev] Intent to Implement & Ship: User-Agent Reduction Phase 5 (platform and OsCpu reduction)

[Victor Tan]

Hi blink-dev,
UA Reduction Phase 5  is currently ramping up to 100% of the stable release 
population. 

Thanks.
Victor

On Monday, January 23, 2023 at 4:13:15 PM UTC-5 Victor Tan wrote:

> Hi blink-dev,
> UA Reduction Phase 5  is currently ramping up to 50% of the stable release 
> population. 
>
> Thanks.
> Victor
>
> On Monday, January 9, 2023 at 2:31:08 PM UTC-5 Victor Tan wrote:
>
>> Hi blink-dev,
>> UA Reduction Phase 5  is currently ramping up to 10% of the stable 
>> release population. We will monitor the change has any impacts. 
>>
>> Thanks.
>> Victor
>>
>> On Wednesday, December 7, 2022 at 4:56:18 PM UTC-5 Victor Tan wrote:
>>
>>> Hi blink-dev,
>>> UA Reduction Phase 5  is currently ramping up to 5% of the stable 
>>> release population. We will monitor the change has any impacts. 
>>>
>>> Thanks.
>>> Victor
>>>
>>> On Thursday, December 1, 2022 at 3:55:50 PM UTC-5 Mike Taylor wrote:
>>>
 Thanks Ziling. We're unlikely to make the change just ahead of the 
 weekend, but will ping this thread early next week once the move to 5% is 
 submitted.

 On 12/1/22 1:36 PM, Ziling Zhao wrote:

 Hey Mike, 

 I think moving to 5% early sounds good for YouTube. The 1% doesn't seem 
 to be giving us consistent data and we would want to get more traffic as 
 soon as possible. If we were to move forward, would this re-roll the 
 experiment or just expand? How soon would we be able to roll this out?

 Thanks!

 On Mon, Nov 28, 2022 at 3:33 PM Mike Taylor  
 wrote:

> Hi Ziling,
>
> (forgive the delay in replying, I took some time off and managed to 
> not check my email)
>
> Based on the other feedback we've received both internally and 
> externally (and the lack of any negative impact thus far), I don't think 
> we 
> want to add an additional month to our rollout schedule before hitting 
> 100%. Another possible option would be to move to 5% sooner, at least 1 
> month ahead of Jan 9th, ideally with enough time to observe metrics ahead 
> of the Finch freeze on Dec 16th, in case something scary happens that 
> would 
> warrant a rollback.
>
> Would that work for YouTube?
>
> thanks,
> Mike
>
> On 11/17/22 7:12 PM, Ziling Zhao wrote:
>
> Hello, 
>
> YouTube -- and various other Google properties -- have been analyzing 
> the results of this 1% experiment. We're concerned that the 1% may not 
> provide enough data especially due to the amount of slicing (modern 
> chrome, 
> non windows vs. legacy windows, etc.). On YT, we are seeing significant 
> metrics impact on, and given the holidays, there's a short amount of time 
> available for us to iterate and debug issues before we rollout to 10%.
>
> We'd like to propose:
>
>- An intermediate state of 5% on January 9th rather than jumping 
>directly to 10%. 
>- The 5% should hold for at least a month, enough for us to do a 
>few rounds of experimental analysis and debugging. 
>
>
> Thanks.
>
> On Wednesday, November 2, 2022 at 4:32:02 PM UTC-7 
> mike...@chromium.org wrote:
>
>> Howdy blink-dev,
>>
>> Phase 5 of UA Reduction is currently ramping up to 1% of the stable 
>> release population. No changes will occur between now and January 9th, 
>> pending site compatibility feedback.
>>
>> thanks,
>> Mike
>>
>> On 9/7/22 12:16 PM, Victor Tan wrote:
>>
>> Thanks all. I just realized there are some date typos for the roll 
>> out plan. Update as follows:  
>>
>> Stage
>>
>> Time
>>
>> Date
>>
>> Stable 1% (M107+)
>>
>> Canary/Dev/Beta 100%
>>
>> M107 stable release is shipping to 100% (a best guess)
>>
>> Nov 1, 2022
>>
>> Stable 10% (M107/M108/M109)
>>
>> ~10 weeks after previous stage
>>
>> Jan 9, *2023*
>>
>> Stable 50%
>>
>> (M107/M108/M109)
>>
>> ~2 weeks
>>
>> Jan 23, *2023* 
>>
>> TOT Default (M111)
>>
>> ~2 weeks after previous stage
>>
>> Feb 7, *2023*
>>
>> Stable 100% (M107=>M111)
>>
>> ~ Same business day as previous stage
>>
>> Feb 7, *2023*
>>
>> Bests,
>> Victor
>>
>> On Wed, Sep 7, 2022 at 11:59 AM Yoav Weiss  
>> wrote:
>>
>>> LGTM3
>>>
>>> On Wed, Sep 7, 2022 at 5:51 PM Daniel Bratell  
>>> wrote:
>>>
 LGTM2

 /Daniel
 On 2022-09-07 17:50, Chris Harrelson wrote:

 LGTM1. If any issues come up during this rollout that affect the 
 plan, please bring them back to this thread for our consideration.

 On Thu, Sep 1, 2022 at 11:29 AM Victor Tan  
 wrote:

> Contact emails 
>
> mike...@chromium.org, vict...@chromium.org

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

['Manjesh Malavalli' via blink-dev]

Hi Team,

Enabling the removal of track and stream stats by default starting from 
M112 gives our customers time to migrate to the latest version of the 
Twilio Video SDK which stops depending on the removed stats.
Thank you very much for agreeing to postpone the rollout.

Manjesh

On Tuesday, February 7, 2023 at 2:36:43 AM UTC-8 Henrik Boström wrote:

> I have the same concern as Harald regarding corporate policies. Why not a 
> Deprecation Origin Trial in that case for list of users and more concrete 
> timeline?
>
> On Tuesday, February 7, 2023 at 9:10:40 AM UTC+1 Harald Alvestrand wrote:
>
>> Do we have trackable statistics on the usage of corporate policies?
>> ie if nobody uses the policy in 2 milestones, can we detect that and 
>> decide that it is not needed and delete it, or will we be as unsure as we 
>> are now?
>>
>>
>> On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor  wrote:
>>
> We don't know what we don't know, but it's not hard to imagine an in-house 
>>> enterprise WebRTC application that is using "stats" or "track". Twilio is 
>>> the breakage we know about (because a developer took the time to report a 
>>> bug). Having a policy so an app continues to work while a fix is made is a 
>>> good thing - and comes with the nice side effect of appearing on the 
>>> Enterprise release notes, increasing awareness.
>>>
>>> On 2/4/23 3:28 AM, Harald Alvestrand wrote:
>>>
>> What's the imagined scenario in which an enterprise policy would be 
>>> useful? 
>>>
>>> The only place I could imagine it being relevant is if there exists a 
>>> WebRTC application that is only used within a single enterprise (neither 
>>> hosting nor usage exists outside the enterprise), and that WebRTC 
>>> application depends on non-upgraded Twilio libraries.
>>>
>>> I don't know that we have evidence that such applications exist.
>>>
>>>
>>>
>>> On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor  wrote:
>>>
>>> I agree with Johnny that an enterprise policy would be useful, at least 
 for a few milestones.

 On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:

>>> I'm not sure an enterprise policy is appropriate - I see the same 
 problem with sunsetting the policy as with sunsetting the stat in general, 
 and usage of enterprise policies is (as far as I know) far more opaque to 
 us than origin trials or Finch feature usage. 


 On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  
 wrote:

>
>
> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
> Is there an enterprise policy in place for this deprecation already? 
> If not, adding one seems appropriate given the challenges of rolling out 
> even simple fixes in some enterprise environments.
>
> One does not exist at the moment but I can add one 
> 
> .
>
>
> Thanks,
> Johnny
>
> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  
> wrote:
> Delaying the enabled-by-default to M112 is fine by me but I'll wait 
> for a resolution here before taking action. Currently it is 
> enabled-by-default in Canary.
>
> On Friday, January 27, 2023 at 12:41:23 PM UTC+1 
> philipp...@googlemail.com wrote:
> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
> hb...@chromium.org>:
> *Contact emails* 
> hb...@chromium.org, h...@chromium.org
>
> *Background*
> I attempted to remove this feature before but had forgotten to file an 
> intent to deprecate, background here 
> .
>
> *Specification*
> The getStats() API spec is here  and 
> it contains all the metrics. The deprecated metrics are also listed, but 
> in 
> the obsolete section 
> .
>  
> There's an open issue to remove obsolete metrics from the spec as soon as 
> they are unshipped from modern browsers. This is considered a blocker for 
> the document to reach Proposed Recommendation status.
>
> *Summary*
> WebRTC is a set of JavaScript APIs (spec 
> ) that allow real-time 
> communication between browsers. For the relevant metrics being removed, 
> we're only talking about the WebRTC use case that is sending or receiving 
> audio or video (typically Video Conferencing use cases), not the data 
> channel use cases that is a popular WebRTC use case, since data channel 
> only use cases would never have any tracks/streams.
>
> RTCPeerConnection.getStats() returns a map of string-to-objects, where 
> each object is one of the dictionaries defined in the stats spec. The 
> reason an app calls getStats() is mostly to report quality metrics (send 
>>

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

['Manjesh Malavalli' via blink-dev]

Hi team,

Thank you for postponing the rollout to M112. This gives our customers some 
time to migrate to the newest version of the Twilio Video SDK, which does 
not depend on the removed stats. We will do an internal post-mortem 
regarding why our tests did not catch this sooner and make the necessary 
corrections on our end.

Thanks,

Manjesh

On Tuesday, February 7, 2023 at 2:36:43 AM UTC-8 Henrik Boström wrote:

> I have the same concern as Harald regarding corporate policies. Why not a 
> Deprecation Origin Trial in that case for list of users and more concrete 
> timeline?
>
> On Tuesday, February 7, 2023 at 9:10:40 AM UTC+1 Harald Alvestrand wrote:
>
>> Do we have trackable statistics on the usage of corporate policies?
>> ie if nobody uses the policy in 2 milestones, can we detect that and 
>> decide that it is not needed and delete it, or will we be as unsure as we 
>> are now?
>>
>>
>> On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor  wrote:
>>
> We don't know what we don't know, but it's not hard to imagine an in-house 
>>> enterprise WebRTC application that is using "stats" or "track". Twilio is 
>>> the breakage we know about (because a developer took the time to report a 
>>> bug). Having a policy so an app continues to work while a fix is made is a 
>>> good thing - and comes with the nice side effect of appearing on the 
>>> Enterprise release notes, increasing awareness.
>>>
>>> On 2/4/23 3:28 AM, Harald Alvestrand wrote:
>>>
>> What's the imagined scenario in which an enterprise policy would be 
>>> useful? 
>>>
>>> The only place I could imagine it being relevant is if there exists a 
>>> WebRTC application that is only used within a single enterprise (neither 
>>> hosting nor usage exists outside the enterprise), and that WebRTC 
>>> application depends on non-upgraded Twilio libraries.
>>>
>>> I don't know that we have evidence that such applications exist.
>>>
>>>
>>>
>>> On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor  wrote:
>>>
>>> I agree with Johnny that an enterprise policy would be useful, at least 
 for a few milestones.

 On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:

>>> I'm not sure an enterprise policy is appropriate - I see the same 
 problem with sunsetting the policy as with sunsetting the stat in general, 
 and usage of enterprise policies is (as far as I know) far more opaque to 
 us than origin trials or Finch feature usage. 


 On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström  
 wrote:

>
>
> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
> Is there an enterprise policy in place for this deprecation already? 
> If not, adding one seems appropriate given the challenges of rolling out 
> even simple fixes in some enterprise environments.
>
> One does not exist at the moment but I can add one 
> 
> .
>
>
> Thanks,
> Johnny
>
> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström  
> wrote:
> Delaying the enabled-by-default to M112 is fine by me but I'll wait 
> for a resolution here before taking action. Currently it is 
> enabled-by-default in Canary.
>
> On Friday, January 27, 2023 at 12:41:23 PM UTC+1 
> philipp...@googlemail.com wrote:
> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
> hb...@chromium.org>:
> *Contact emails* 
> hb...@chromium.org, h...@chromium.org
>
> *Background*
> I attempted to remove this feature before but had forgotten to file an 
> intent to deprecate, background here 
> .
>
> *Specification*
> The getStats() API spec is here  and 
> it contains all the metrics. The deprecated metrics are also listed, but 
> in 
> the obsolete section 
> .
>  
> There's an open issue to remove obsolete metrics from the spec as soon as 
> they are unshipped from modern browsers. This is considered a blocker for 
> the document to reach Proposed Recommendation status.
>
> *Summary*
> WebRTC is a set of JavaScript APIs (spec 
> ) that allow real-time 
> communication between browsers. For the relevant metrics being removed, 
> we're only talking about the WebRTC use case that is sending or receiving 
> audio or video (typically Video Conferencing use cases), not the data 
> channel use cases that is a popular WebRTC use case, since data channel 
> only use cases would never have any tracks/streams.
>
> RTCPeerConnection.getStats() returns a map of string-to-objects, where 
> each object is one of the dictionaries defined in the stats spec. The 
> reason an a

Re: [blink-dev] Intent to Deprecate and Remove: WebRTC's RTCStats of type "track" and "stream".

[Chris Thompson]

> Do we have trackable statistics on the usage of corporate policies?
> ie if nobody uses the policy in 2 milestones, can we detect that and
decide that it is not needed and delete it, or will we be as unsure as we
are now?

It is quite common in my experience to handle removals with an enterprise
policy that is stated upfront to be temporary (i.e., the enterprise release
notes give a deadline milestone), with no metrics needed.

On Tue, Feb 7, 2023 at 1:17 PM 'Manjesh Malavalli' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi team,
>
> Thank you for postponing the rollout to M112. This gives our customers
> some time to migrate to the newest version of the Twilio Video SDK, which
> does not depend on the removed stats. We will do an internal post-mortem
> regarding why our tests did not catch this sooner and make the necessary
> corrections on our end.
>
> Thanks,
>
> Manjesh
>
> On Tuesday, February 7, 2023 at 2:36:43 AM UTC-8 Henrik Boström wrote:
>
>> I have the same concern as Harald regarding corporate policies. Why not a
>> Deprecation Origin Trial in that case for list of users and more concrete
>> timeline?
>>
>> On Tuesday, February 7, 2023 at 9:10:40 AM UTC+1 Harald Alvestrand wrote:
>>
>>> Do we have trackable statistics on the usage of corporate policies?
>>> ie if nobody uses the policy in 2 milestones, can we detect that and
>>> decide that it is not needed and delete it, or will we be as unsure as we
>>> are now?
>>>
>>>
>>> On Mon, Feb 6, 2023 at 9:41 PM Mike Taylor  wrote:
>>>
>> We don't know what we don't know, but it's not hard to imagine an
 in-house enterprise WebRTC application that is using "stats" or "track".
 Twilio is the breakage we know about (because a developer took the time to
 report a bug). Having a policy so an app continues to work while a fix is
 made is a good thing - and comes with the nice side effect of appearing on
 the Enterprise release notes, increasing awareness.

 On 2/4/23 3:28 AM, Harald Alvestrand wrote:

>>> What's the imagined scenario in which an enterprise policy would be
 useful?

 The only place I could imagine it being relevant is if there exists a
 WebRTC application that is only used within a single enterprise (neither
 hosting nor usage exists outside the enterprise), and that WebRTC
 application depends on non-upgraded Twilio libraries.

 I don't know that we have evidence that such applications exist.



 On Fri, Feb 3, 2023 at 6:14 PM Mike Taylor 
 wrote:

 I agree with Johnny that an enterprise policy would be useful, at least
> for a few milestones.
>
> On 1/30/23 5:16 AM, 'Harald Alvestrand' via blink-dev wrote:
>
 I'm not sure an enterprise policy is appropriate - I see the same
> problem with sunsetting the policy as with sunsetting the stat in general,
> and usage of enterprise policies is (as far as I know) far more opaque to
> us than origin trials or Finch feature usage.
>
>
> On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström 
> wrote:
>
>>
>>
>> On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny Stenback wrote:
>> Is there an enterprise policy in place for this deprecation already?
>> If not, adding one seems appropriate given the challenges of rolling out
>> even simple fixes in some enterprise environments.
>>
>> One does not exist at the moment but I can add one
>> 
>> .
>>
>>
>> Thanks,
>> Johnny
>>
>> On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström 
>> wrote:
>> Delaying the enabled-by-default to M112 is fine by me but I'll wait
>> for a resolution here before taking action. Currently it is
>> enabled-by-default in Canary.
>>
>> On Friday, January 27, 2023 at 12:41:23 PM UTC+1
>> philipp...@googlemail.com wrote:
>> Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström <
>> hb...@chromium.org>:
>> *Contact emails*
>> hb...@chromium.org, h...@chromium.org
>>
>> *Background*
>> I attempted to remove this feature before but had forgotten to file
>> an intent to deprecate, background here
>> 
>> .
>>
>> *Specification*
>> The getStats() API spec is here  and
>> it contains all the metrics. The deprecated metrics are also listed, but 
>> in
>> the obsolete section
>> .
>> There's an open issue to remove obsolete metrics from the spec as soon as
>> they are unshipped from modern browsers. This is considered a blocker for
>> the document to reach Proposed Recommendation status.
>>
>> *Summary*
>> WebRTC is a set of JavaScript APIs (spec

[blink-dev] Intent to Experiment: WebAssembly Garbage Collection (WasmGC), plus stringref

[Adam Klein]

Contact emails

ad...@chromium.org, jkumme...@chromium.org

Explainer

https://github.com/WebAssembly/gc/blob/main/proposals/gc/Overview.md

Specification

MVP GC spec: https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md

MVP JS API:
https://docs.google.com/document/d/17hCQXOyeSgogpJ0I0wir4LRmdvu4l7Oca6e1NkbVN8M/edit

stringref:
https://github.com/WebAssembly/stringref/blob/main/proposals/stringref/Overview.md

Design docs

https://docs.google.com/document/d/1DklC3qVuOdLHSXB5UXghM_syCh-4cMinQ50ICiXnK3Q/edit

Summary

The GC proposal adds efficient support for high-level managed languages to
WebAssembly, via struct and array types that enable language compilers
targeting Wasm to integrate with a garbage collector in the host VM.

The separate stringref proposal allows Wasm to efficiently create,
manipulate, and pass host-provided strings to & from the host. In browsers,
these are JavaScript strings. Though it’s not part of the GC proposal, for
convenience of language partners we want to include it as part of this
Origin Trial. Shipment readiness of stringrefs will be evaluated separately
in the future.

Blink component

Blink>JavaScript>WebAssembly


Search tags

wasm , webassembly
, gc
, managed objects
, wasmgc


TAG review

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

TAG review status

Pending

Risks
Interoperability and Compatibility

Gecko: Positive

WebKit: No signal, but implementation under way

Web developers: No signals

Other signals: Proposal is at Phase 3 in the Wasm CG, demonstrating high
levels of consensus, and implementations are under way in SpiderMonkey and
JSC.

WebView application risks

None

Goals for experimentation

Let developers compare in-the-wild performance of applications which
currently compile to JS to the same application compiled to WebAssembly GC.
And the same for framework developers with multiple export formats,
allowing their users to make the same comparisons.

We are working with multiple partners who are committed to gathering such
data, and we plan to use it to validate that the design is sufficient to
meet our expectations around performance.

Ongoing technical constraints

None

Debuggability

Wasm GC is debuggable using devtools, including sourcemap support &
profiling. We expect support to improve over time as toolchain implementers
work on improving developer experience, analogous to what we currently have
with DWARF-based C++ debugging in Emscripten + the Devtools DWARF extension.

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

?

No. Instead, it is tested by Wasm spec tests, as is customary for core Wasm
features.

Flag name

WebAssembly Garbage Collection

Requires code in //chrome?

No

Tracking bug

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

Launch bug

https://launch.corp.google.com/launch/4231622

Estimated milestones

OriginTrial

TBD based on partner readiness

Link to entry on the Chrome Platform Status

WasmGC: https://chromestatus.com/feature/6062715726462976

stringref: https://chromestatus.com/feature/5094457362350080

This intent message was generated by Chrome Platform Status
.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcJ40QGU0eOx6Y24RLQOwXWQFrPaTuqUw%2Bm2TSkiRMjWCw%40mail.gmail.com.

[blink-dev] Re: Intent to Deprecate and Remove: webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage()

[John R.]

sorry about responding to this old bug, but is there a modern polyfill for 
this? an old website i'm using requires this (and other deprecated WK 
functions) and i have found nothing to mitigate this issue.

On Monday, July 28, 2014 at 4:58:28 PM UTC-4 Philip Jägenstedt wrote:

> Primary eng (and PM) emails
>
> phi...@opera.com
>
> Summary
> Remove webkitConvertPointFromPageToNode() and 
> webkitConvertPointFromNodeToPage().
>
> These are global functions, exposed on Window.
>
> Motivation
>
> They were added in https://bugs.webkit.org/show_bug.cgi?id=23943 to "map 
> points through possibly-transformed elements." At least the uses of them 
> in LayoutTests can be replaced with getBoundingClientRect(), which also 
> take transforms into consideration. The same is likely true of usage in the 
> wild, too.
>
>
> These two functions are also the only APIs that depend on WebKitPoint, 
> paving the way for its eventual removal.
>
> Compatibility Risk
>
> The worst-case scenario is catastrophic failure of a WebKit-only site. 
> Given the usage, actual risk seems very low indeed.
>
> Alternative implementation suggestion for web developers
>
> Use element.getBoundingClientRect().left/top to get the offsets that these 
> functions would add/remove.
>
>
> For example, webkitConvertPointFromNodeToPage(element, new 
> WebKitPoint(0,0)).x can be replaced by element.getBoundingClientRect().left.
>
>
> Usage information from UseCounter 
> 
> webkitConvertPointFromPageToNode() ~0.0001%:
> http://www.chromestatus.com/metrics/feature/timeline/popularity/359
> webkitConvertPointFromNodeToPage() ~0.0002%:
> http://www.chromestatus.com/metrics/feature/timeline/popularity/360
>
> Entry on chromestatus.com, crbug.com, or MDN
>
> None.
>
> Requesting approval to remove too?
> Yes. Usage is negligible.
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/079129f7-f6e8-4e86-ada8-98a4748598ddn%40chromium.org.

[blink-dev] Intent to Prototype and Ship: WebGLContextEvent on Web Workers

[Ken Russell]

Contact emails

k...@chromium.org

Explainer

None

Specification

https://registry.khronos.org/webgl/specs/latest/1.0

Summary

The WebGLContextEvent type has been defined in Khronos' WebGL specification
for a number of years, but it was not noticed until recently that in Blink,
this type is not exposed on web workers. (Most applications simply add an
event listener for the type, and do not look for its prototype in the
global scope.)

This is a simple fix to Blink's Web IDL for WebGLContextEvent, but is a web
exposed change.



Blink component

Blink>WebGL


Motivation

See Summary.


Initial public proposal

None; standardized years ago in Khronos when WebGL support was added to
OffscreenCanvas.


TAG review

None; standardized years ago in Khronos when WebGL support was added to
OffscreenCanvas.


TAG review status

Not applicable

Risks

Interoperability and Compatibility

Gecko: Already implemented

WebKit: Just implemented in https://bugs.webkit.org/show_bug.cgi?id=251504

Web developers: Meet team reported this missing prototype in an internal
bug report.

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?

No


Debuggability

Is this feature fully tested by web-platform-tests

?

Yes

Flag name

None

Requires code in //chrome?

False

Estimated milestones

M113


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5071251544997888

This intent message was generated by Chrome Platform Status
.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMYvS2czQWvKTcvph9HNX34LH_V6EerUCLyHWOx-XrTJnar_gQ%40mail.gmail.com.

[blink-dev] Re: Intent to Deprecate and Remove: webkitConvertPointFromPageToNode() and webkitConvertPointFromNodeToPage()

['Russell Bicknell' via blink-dev]

I've been wondering about this for a while too. AFAIK, there's no built-in 
way to ask the browser to transform points like this, so you have to write 
a heavy function to walk the tree and inspect the styles manually. The 
function ends up being huge and brittle - there's no forward compatible way 
to do it given that new CSS properties might show up in the future. 
However, this part of the CSSOM spec 
 adds an 
interface (`GeometryUtils`) that sounds like it's intended to do this, but 
every time I've returned to that page over the last handful of years, they 
still have basically zero description.

The lack of this function means that there's no way to handle coordinates 
from pointer events in relation to arbitrarily transformed elements in a 
robust way. :(

On Tuesday, February 7, 2023 at 4:15:01 PM UTC-8 John R. wrote:

> sorry about responding to this old bug, but is there a modern polyfill for 
> this? an old website i'm using requires this (and other deprecated WK 
> functions) and i have found nothing to mitigate this issue.
>
> On Monday, July 28, 2014 at 4:58:28 PM UTC-4 Philip Jägenstedt wrote:
>
>> Primary eng (and PM) emails
>>
>> phi...@opera.com
>>
>> Summary
>> Remove webkitConvertPointFromPageToNode() and 
>> webkitConvertPointFromNodeToPage().
>>
>> These are global functions, exposed on Window.
>>
>> Motivation
>>
>> They were added in https://bugs.webkit.org/show_bug.cgi?id=23943 to "map 
>> points through possibly-transformed elements." At least the uses of them 
>> in LayoutTests can be replaced with getBoundingClientRect(), which also 
>> take transforms into consideration. The same is likely true of usage in the 
>> wild, too.
>>
>>
>> These two functions are also the only APIs that depend on WebKitPoint, 
>> paving the way for its eventual removal.
>>
>> Compatibility Risk
>>
>> The worst-case scenario is catastrophic failure of a WebKit-only site. 
>> Given the usage, actual risk seems very low indeed.
>>
>> Alternative implementation suggestion for web developers
>>
>> Use element.getBoundingClientRect().left/top to get the offsets that 
>> these functions would add/remove.
>>
>>
>> For example, webkitConvertPointFromNodeToPage(element, new 
>> WebKitPoint(0,0)).x can be replaced by element.getBoundingClientRect().left.
>>
>>
>> Usage information from UseCounter 
>> 
>> webkitConvertPointFromPageToNode() ~0.0001%:
>> http://www.chromestatus.com/metrics/feature/timeline/popularity/359
>> webkitConvertPointFromNodeToPage() ~0.0002%:
>> http://www.chromestatus.com/metrics/feature/timeline/popularity/360
>>
>> Entry on chromestatus.com, crbug.com, or MDN
>>
>> None.
>>
>> Requesting approval to remove too?
>> Yes. Usage is negligible.
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b8b27009-727a-408a-aad8-1fac6d6972bbn%40chromium.org.

Re: [blink-dev] Intent to Ship: WebGPU

[Kai Ninomiya]

There is no active plan to export or migrate the WebGPU CTS into WPT. It's
something we'd theoretically like to do in the long run, but there are a
lot of blockers:

- If we just export without moving it, then browser-to-wpt auto-export will
not be usable, so I would want to move it.
- TypeScript meaningfully enables our test development and we would not
want to strip it from the code, so we would want to somehow support that
inside WPT. (We actually had an idea involving running babel in a service
worker that could make this work now, but it's something we wouldn't want
to do just for WebGPU.)
- Each browser's wpt-to-browser auto-import will need to run the WebGPU
tests on all hardware/software configurations used on that browser's CQ
equivalent, and be able to collect the test results and update expectations
files automatically. Without this, auto-imports will frequently be unable
to import without breaking the build.
- Chromium doesn't actually run most of the WebGPU CTS through
WPT/web_tests anymore - only reftests still use web_tests. For numerous
reasons, it was more practical to run under Chromium's GPU integration test
framework. Other browsers are integrating the tests in whatever way is most
practical for them (for example WebKit can't run it under their WPT runner
using the WPT "variants" feature - they need it split up into files or
somehow baked into the WPT manifest).
- The test tree is very large and deep and test runtimes are highly
variable, we needed a heartbeat mechanism for timeouts, which WPT does not
have.
- We needed expectations

to depend on the GPU hardware and various configurations of Chromium's
graphics and WebGPU stack, which we already had in that framework.
- It uses the real browser instead of content_shell: tests what we
ship, and we also had difficult-to-debug flakiness somehow relating to GPU
initialization in content_shell.

-Kai (he/they)


On Tue, Feb 7, 2023 at 5:28 AM Corentin Wallez  wrote:

> Hey Rego,
>
> The WebGPU CTS is meant to be exportable into a WPT subdirectory, see
> https://github.com/gpuweb/cts/blob/main/docs/build.md. However I don't
> know that there's a specific plan to integrate into WPT proper since
> development uses a lot of combination testing and Typescript, which is not
> something WPT support (the export step creates individual HTML pages for
> each test case and compiles the Typescript to Javascript). +Kai Ninomiya
> , feel free to correct me if I missed something.
>
> Cheers,
>
> Corentin
>
> On Mon, Feb 6, 2023 at 5:55 PM Manuel Rego Casasnovas 
> wrote:
>
>>
>>
>> On 14/12/2022 18:02, Corentin Wallez wrote:
>> > The WebGPU Conformance Test Suite is being built
>> > at https://github.com/gpuweb/cts  and
>> can
>> > be integrated as a subdirectory of WPT. Coverage is still incomplete due
>> > to the complexity of the API but progressing quickly. We expect to ship
>> > with coverage holes, but with most important and risky aspects of
>> > interoperability well tested.
>>
>> Any plans about integrating the test suite into WPT?
>>
>> Thanks,
>>   Rego
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyD6G97bLgnCFRpqMCmkXhtkpkV9rP7wk2ByoiGgMznoSw%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebGPU

[Manuel Rego Casasnovas]

Thanks for the detailed explanation.

Cheers,
  Rego

On 08/02/2023 05:24, Kai Ninomiya wrote:
> There is no active plan to export or migrate the WebGPU CTS into WPT.
> It's something we'd theoretically like to do in the long run, but there
> are a lot of blockers:
> 
> - If we just export without moving it, then browser-to-wpt auto-export
> will not be usable, so I would want to move it.
> - TypeScript meaningfully enables our test development and we would not
> want to strip it from the code, so we would want to somehow support that
> inside WPT. (We actually had an idea involving running babel in a
> service worker that could make this work now, but it's something we
> wouldn't want to do just for WebGPU.)
> - Each browser's wpt-to-browser auto-import will need to run the WebGPU
> tests on all hardware/software configurations used on that browser's CQ
> equivalent, and be able to collect the test results and update
> expectations files automatically. Without this, auto-imports will
> frequently be unable to import without breaking the build.
> - Chromium doesn't actually run most of the WebGPU CTS through
> WPT/web_tests anymore - only reftests still use web_tests. For numerous
> reasons, it was more practical to run under Chromium's GPU integration
> test framework. Other browsers are integrating the tests in whatever way
> is most practical for them (for example WebKit can't run it under their
> WPT runner using the WPT "variants" feature - they need it split up into
> files or somehow baked into the WPT manifest).
>     - The test tree is very large and deep and test runtimes are highly
> variable, we needed a heartbeat mechanism for timeouts, which WPT does
> not have.
>     - We needed expectations
> 
>  to depend on the GPU hardware and various configurations of Chromium's 
> graphics and WebGPU stack, which we already had in that framework.
>     - It uses the real browser instead of content_shell: tests what we
> ship, and we also had difficult-to-debug flakiness somehow relating to
> GPU initialization in content_shell.
> 
> -Kai (he/they)
> 
> 
> On Tue, Feb 7, 2023 at 5:28 AM Corentin Wallez  > wrote:
> 
> Hey Rego,
> 
> The WebGPU CTS is meant to be exportable into a WPT subdirectory,
> see https://github.com/gpuweb/cts/blob/main/docs/build.md
> . However I
> don't know that there's a specific plan to integrate into WPT proper
> since development uses a lot of combination testing and Typescript,
> which is not something WPT support (the export step creates
> individual HTML pages for each test case and compiles the Typescript
> to Javascript). +Kai Ninomiya , feel
> free to correct me if I missed something.
> 
> Cheers,
> 
> Corentin
> 
> On Mon, Feb 6, 2023 at 5:55 PM Manuel Rego Casasnovas
> mailto:r...@igalia.com>> wrote:
> 
> 
> 
> On 14/12/2022 18:02, Corentin Wallez wrote:
> > The WebGPU Conformance Test Suite is being built
> > at https://github.com/gpuweb/cts
>   > and can
> > be integrated as a subdirectory of WPT. Coverage is still
> incomplete due
> > to the complexity of the API but progressing quickly. We
> expect to ship
> > with coverage holes, but with most important and risky aspects of
> > interoperability well tested.
> 
> Any plans about integrating the test suite into WPT?
> 
> Thanks,
>   Rego
> 
> -- 
> 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+unsubscr...@chromium.org
> .
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANxMeyD6G97bLgnCFRpqMCmkXhtkpkV9rP7wk2ByoiGgMznoSw%40mail.gmail.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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8875118c-ff89-037f-643e-7d8d79bfeae9%40igalia.com.