Re: [blink-dev] Intent to extend experiment: Privacy Sandbox Ads APIs

[Yoav Weiss]

Hey Johnny!

Josh consulted with me whether he should send a single intent or several
ones, and I asked him to send a single consolidated one. Since the
different features are all bundled as a single OT, a single intent makes it
easier to make sure they are all in sync, and we're not
inadvertently approving an extension for all the features when approving an
extension for one of them.
Maybe it's possible to list all the different status entries in this
extension request, so that we'd make sure they're all up to date?

Cheers :)
Yoav

On Wed, Jul 27, 2022 at 8:33 PM Johnny Stenback 
wrote:

> Hey Josh,
>
> As a general rule, please send one intent per feature as that'll help
> ensure all the intents get marked as approved in Chromestatus appropriately
> and we can help ensure that OT milestones etc are all up to date.
>
> Thanks,
> Johnny
>
> On Wed, Jul 27, 2022 at 9:48 AM Josh Karlin  wrote:
>
>> Greetings. The Privacy Sandbox Ads APIs experiment includes several APIs
>> and we'd like to extend all of them another three milestones to M107, with
>> the expectation that we will likely continue to ask for extensions to
>> support ecosystem testing.
>>
>> This OT covers several APIs (Attribution Reporting
>> ,
>> FLEDGE
>> ,
>> Topics
>> ,
>> Fenced Frames
>> ,
>> and Shared Storage
>> )
>> that are part of the Privacy Sandbox initiative. Based on feedback we
>> have already received
>> ,
>> it will take more time before experimenters can provide the feedback that
>> we need to validate and improve them. We also expect to add several new
>> features for testing (including Shared Storage and support for FLEDGE on
>> mobile) in upcoming releases.
>>
>> I've bundled the requests for each API into a single intent to extend
>> since they are part of the same OT and all require the extension. If you'd
>> like, they can instead be requested individually.
>>
>> Thanks,
>>
>> Josh
>>
>> --
>> 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/CAANMuaO4BR3PMHJ8r-%2BzBpb2cDfbMKs%2Bg8syM-8ZUnSnrA5KTw%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/CACZRgz5tN-jpoSkqM2%3DxXj1%3DzXe5zZR-HYjMoNTm4KeEtSsK%3Dw%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/CAL5BFfWrwgoTWAVfku2DbbsieV86%3D_ho49wxdA1geyqdOUQ6wQ%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

[Minoru Chikamune]

>> Where's the status entry for this?
> I'll create a chrome status entry. Thank you for pointing this out.

I've created a chrome status entry.
https://chromestatus.com/guide/edit/5104987642789888


On Tue, Aug 2, 2022 at 10:06 AM Minoru Chikamune 
wrote:

> > A change of schedule doesn't really qualify as an experiment extension.
> My LGTM from the previous intent
>  still
> stands.
>
> Oh, I see.
>
> > Where's the status entry for this?
>
> I'll create a chrome status entry. Thank you for pointing this out.
>
>
> On Tue, Aug 2, 2022 at 2:50 AM Joe Medley  wrote:
>
>> Where's the status entry for this?
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>>  816-678-7195
>> *If an API's not documented it doesn't exist.*
>>
>>
>> On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss  wrote:
>>
>>> A change of schedule doesn't really qualify as an experiment extension.
>>> My LGTM from the previous intent
>>> 
>>> still stands.
>>>
>>> On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
>>> wrote:
>>>
 *Contact emails*

 chikam...@chromium.org, sisidov...@chromium.org

 Explainer:

-

https://github.com/nyaxt/lazyembeds


 Specification: https://github.com/nyaxt/lazyembeds

 Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
 outside the viewport when all of the following conditions are met.


-

The loading=eager or loading=lazy attribute values are not
specified in the iframe tag.


-

The iframe's src URL matches a pre-curated list of cross-origin
embeds (for the sake of quick experimentation).


-

The page is visible.
-

The iframe's src URL must be cross origin.
-

The main frame is not loaded in the following ways. In the
following operations, the user probably wants to avoid any breakage 
 caused
by LazyEmbeds.
-

   The main frame is reloaded.
   -

   The main frame is a result after the user (re)submits a form.


 LazyEmbeds has a timeout mechanism that loads all the iframes that are
 eligible for LazyEmbeds after a few seconds have elapsed even when the
 viewport doesn't come near the iframe. This timeout mechanism is the main
 difference between  LazyEmbeds and .

 Site authors can specify loading=eager on frames to opt-out of
 LazyEmbeds.

 The current LazyEmbeds implementations target a 1% stable channel for
 data gathering purposes. We don't have any plan to release LazyEmbeds in
 its current form. This experiment is to help us assess the potential
 impact, in order to motivate a proper, launchable, design.

 Blink component: Blink>Loader
 

 TAG review

 None

 TAG review status

 Not applicable

 RisksInteroperability and Compatibility

 The goal of the experiment is to test if the idea actually improves
 page load UX. Once that is proven, we would like to start pitching in the
 standardization forum on having the new behavior part of the spec.

 We have a rough sketch of how it would look like in terms of
 specification changes at https://github.com/nyaxt/lazyembeds.
 LazyEmbeds applies a different loading schedule to offscreen cross-origin
 s. Site authors who believe offscreen content is a critical part of
 the user-experience may find this breaks their expectations. To restore the
 previous behavior, authors can specify loading=eager on those frames.

 Ergonomics

 Websites don’t have to do anything.

 Activation

 LazyEmbeds works without any developer activation.

 Security and privacy

 LazyEmbeds doesn't have any security and privacy concerns.

 Goals for experimentation

 We would like to judge if this is a good idea or not before we would
 like to validate our hypothesis using the performance data (e.g. Core Web
 Vitals) collected through the experiment before we proceed to the next
 steps (open-ended discussion with other vendors, involved 3rd-parties).

 Reason this experiment is being extended

 The previous timeline was to start an experimental 1% stable rollout
 in M104. But while running experiments in M104 beta, we have noticed
 several problems. So we would like to change the schedule. We want to
 restart the experiment in M105 beta and 1% stable rollout in M105.

 The following are the notable differences between M104 and M105.

-

The main frame is not loaded in the following ways. In the

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

[Minoru Chikamune]

> A change of schedule doesn't really qualify as an experiment extension.
My LGTM from the previous intent
 still
stands.

Oh, I see.

> Where's the status entry for this?

I'll create a chrome status entry. Thank you for pointing this out.


On Tue, Aug 2, 2022 at 2:50 AM Joe Medley  wrote:

> Where's the status entry for this?
> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>  816-678-7195
> *If an API's not documented it doesn't exist.*
>
>
> On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss  wrote:
>
>> A change of schedule doesn't really qualify as an experiment extension.
>> My LGTM from the previous intent
>> 
>> still stands.
>>
>> On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
>> wrote:
>>
>>> *Contact emails*
>>>
>>> chikam...@chromium.org, sisidov...@chromium.org
>>>
>>> Explainer:
>>>
>>>-
>>>
>>>https://github.com/nyaxt/lazyembeds
>>>
>>>
>>> Specification: https://github.com/nyaxt/lazyembeds
>>>
>>> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
>>> outside the viewport when all of the following conditions are met.
>>>
>>>
>>>-
>>>
>>>The loading=eager or loading=lazy attribute values are not specified
>>>in the iframe tag.
>>>
>>>
>>>-
>>>
>>>The iframe's src URL matches a pre-curated list of cross-origin
>>>embeds (for the sake of quick experimentation).
>>>
>>>
>>>-
>>>
>>>The page is visible.
>>>-
>>>
>>>The iframe's src URL must be cross origin.
>>>-
>>>
>>>The main frame is not loaded in the following ways. In the following
>>>operations, the user probably wants to avoid any breakage caused by
>>>LazyEmbeds.
>>>-
>>>
>>>   The main frame is reloaded.
>>>   -
>>>
>>>   The main frame is a result after the user (re)submits a form.
>>>
>>>
>>> LazyEmbeds has a timeout mechanism that loads all the iframes that are
>>> eligible for LazyEmbeds after a few seconds have elapsed even when the
>>> viewport doesn't come near the iframe. This timeout mechanism is the main
>>> difference between  LazyEmbeds and .
>>>
>>> Site authors can specify loading=eager on frames to opt-out of
>>> LazyEmbeds.
>>>
>>> The current LazyEmbeds implementations target a 1% stable channel for
>>> data gathering purposes. We don't have any plan to release LazyEmbeds in
>>> its current form. This experiment is to help us assess the potential
>>> impact, in order to motivate a proper, launchable, design.
>>>
>>> Blink component: Blink>Loader
>>> 
>>>
>>> TAG review
>>>
>>> None
>>>
>>> TAG review status
>>>
>>> Not applicable
>>>
>>> RisksInteroperability and Compatibility
>>>
>>> The goal of the experiment is to test if the idea actually improves page
>>> load UX. Once that is proven, we would like to start pitching in the
>>> standardization forum on having the new behavior part of the spec.
>>>
>>> We have a rough sketch of how it would look like in terms of
>>> specification changes at https://github.com/nyaxt/lazyembeds.
>>> LazyEmbeds applies a different loading schedule to offscreen cross-origin
>>> s. Site authors who believe offscreen content is a critical part of
>>> the user-experience may find this breaks their expectations. To restore the
>>> previous behavior, authors can specify loading=eager on those frames.
>>>
>>> Ergonomics
>>>
>>> Websites don’t have to do anything.
>>>
>>> Activation
>>>
>>> LazyEmbeds works without any developer activation.
>>>
>>> Security and privacy
>>>
>>> LazyEmbeds doesn't have any security and privacy concerns.
>>>
>>> Goals for experimentation
>>>
>>> We would like to judge if this is a good idea or not before we would
>>> like to validate our hypothesis using the performance data (e.g. Core Web
>>> Vitals) collected through the experiment before we proceed to the next
>>> steps (open-ended discussion with other vendors, involved 3rd-parties).
>>>
>>> Reason this experiment is being extended
>>>
>>> The previous timeline was to start an experimental 1% stable rollout in
>>> M104. But while running experiments in M104 beta, we have noticed several
>>> problems. So we would like to change the schedule. We want to restart the
>>> experiment in M105 beta and 1% stable rollout in M105.
>>>
>>> The following are the notable differences between M104 and M105.
>>>
>>>-
>>>
>>>The main frame is not loaded in the following ways. In the following
>>>operations, the user probably wants to avoid any breakage caused by
>>>LazyEmbeds.
>>>-
>>>
>>>   The main frame is reloaded.
>>>   -
>>>
>>>   The main frame is a result after the user (re)submits a form.
>>>   -
>>>
>>>Added a timeout mechanism that loads all the iframes that are
>>>eligible for LazyEmbeds after a few seconds have elapsed even when the
>>>viewport 

Re: [blink-dev] A quick survey on setting up fuzzy match rules to identify resolvable flaky web tests

[支文文）' via blink-dev]

Thanks for valuable feedback! Stephen, Xianzhu, will see if we can add a
filter in result.html to grab those tests in range.


On Mon, Aug 1, 2022 at 8:40 AM Xianzhu Wang 
wrote:

> On Mon, Aug 1, 2022 at 4:25 AM Stephen Chenney 
> wrote:
>
>> Thanks for investigating the potential for fuzzy matching.
>>
>> Rendering Core continues to oppose a single fuzzy match rule across all
>> web_tests. We have some tests where single pixel differences matter
>> (related to pixel snapping, for example) and a universal fuzzy match would
>> fail to identify problems with those. This came up in practice recently
>> when the GPU team enabled fuzzy matching without telling us, and expected
>> failing tests started passing when they shouldn't.
>>
>
> I think a key difference between the original fuzzy matching rule and the
> rule proposed by Vivian is the ranges. With maxDifference=0-1, we should be
> able to catch most visible single pixel differences. What I'm not sure is
> whether a difference like rgb(1, 0, 0) vs rgb(0, 0, 0) (each component in
> the range of 0-255) should be treated as a failure in some cases.
>
> Maybe specific sub teams have directories they could apply default fuzzy
>> matching to. My guess is that the same directories where it will work will
>> be directories with few failing tests, limiting the impact of a
>> per-directory approach.
>>
>> Is there a way to reproduce the sampling below with a side-by-side
>> comparison of the images? I would find it helpful to look through some of
>> the cases that would pass with ,
>> for example.
>>
>
> A filter by actual maxDifference and totalPixels in results.html will be
> helpful. I can add it when I get time.
>
> Stephen.
>>
>> On Fri, Jul 29, 2022 at 8:20 PM 'Vivian Zhi (支文文）' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Hi blink-dev
>>>
>>> I would like to let you know that blink-engprod has added feature
>>> support for non-WPT fuzzy tests. It now allows both non-WPT reftests and
>>> pixel tests to use the same fuzzy matching meta-tags as WPT tests.It also
>>> shows max color channel difference and total number of different pixels
>>> image diff stats in results.html
>>> .
>>> With these capabilities in place, we like to research further to see if we
>>> can set up some general fuzzy match rules, help blink dev identify flaky
>>> tests that can be potentially resolved by adjusting fuzzy matching rules.
>>> Currently there are quite some web tests that are flaky due to a slight
>>> image mismatch, which should have been tolerated. If we setup a general
>>> fuzzy matching rule , something like:
>>>
>>>  
>>>
>>> Instruct the image comparison web tests that if color channel and pixel
>>> diff fall within the range of the rule, we can ignore the diff and pass the
>>> test.This way we can reduce test flakiness while still maintain test
>>> accuracy without missing a real bug.
>>>
>>> We want to ask you some quick survey questions to help us make design
>>> decisions, whether it makes sense to set up an universal cross-the-board
>>> fuzzy match tolerant rule for all blink web tests, or we should make the
>>> rules more specific to individual test or test sets.
>>>
>>> 1.  Is an universal fuzzy match tolerant rule acceptable for the web
>>> tests in your area?
>>>
>>> a). If the answer is yes, what is the acceptable range of max color
>>> channel and pixel diff for your tests?
>>> b) If the answer is no, pls share your reasons.
>>>
>>> 2. Do you prefer fuzzy matching rule adjustment at a per-test or per
>>> test set level based on the pixel difference numbers shown in results.html?
>>>
>>> Here is some sample data help you make choice, we collected data
>>> recently from blink_web_tests result on linux-test builder, the
>>> distribution of color channel maxDifference and totalPixel diff for
>>> failing/flaky blink_web_tests
>>> ( Note: over 70% tests in color channel maxDifference 0-10 range have
>>> maxDifference=1):
>>>
>>> Color Channel maxDifferenece
>>> Range Fail test count
>>> 0-10 98
>>> 11-100 31
>>> 101-200 28
>>> 201-260 111
>>> totalPixels
>>> Diff Range
>>> Fail test count
>>> 0-100 30
>>> 100-1000 57
>>> 1000-10,000 99
>>> 10,000-100,000 66
>>> 100,000-1,000,000 16
>>>
>>> Let me know if you have any questions, looking forward to hearing from
>>> you!
>>>
>>>
>>> Vivian
>>> on behalf of Chrome-Blink-EngProd
>>>
>>> --
>>> 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/CAPCqkTs-L5u22-Xp5U_LeBdLP%3D%2BTDH1KGv8MTmtKQFRcANCZJg%40mail.gmail.com
>>> 

Re: [blink-dev] Intent to Ship: MSE in Workers

['Joe Medley' via blink-dev]

Gang,

NOTE: Requested desktop and Android ship milestone: 105 (The 'edit
> estimated milestones' link from chromestatus didn't result in such ability
> to edit, so I'm adding this request explicitly here.)


I'm looking into this and will report back. Has anyone else noticed this
problem?

Joe
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 1, 2022 at 8:52 AM Mike Taylor  wrote:

> LGTM3
>
> On 8/1/22 8:05 AM, Yoav Weiss wrote:
>
> LGTM2
>
> On Fri, Jul 29, 2022 at 12:40 AM slightlyoff via Chromestatus <
> admin+slightly...@cr-status.appspotmail.com> wrote:
>
>> LGTM1
>> --
>> 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/eea04c05e4e53819%40google.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/CAL5BFfWsqYRjB%3DqCuu4UxHzEa%2B%2B2SqkDJdE8W8sUNCnS%2BwoH5w%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/91d78e87-3241-0719-eb2a-a7e8d21afd0b%40chromium.org
> 
> .
>

-- 
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/CAJUhtG8EH2E1y33qLPJr3xdp8ZT1z1T98mCQ9bJ4WeBn19BOsQ%40mail.gmail.com.

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

['Joe Medley' via blink-dev]

Where's the status entry for this?
Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
 816-678-7195
*If an API's not documented it doesn't exist.*


On Mon, Aug 1, 2022 at 7:31 AM Yoav Weiss  wrote:

> A change of schedule doesn't really qualify as an experiment extension. My
> LGTM from the previous intent
> 
> still stands.
>
> On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
> wrote:
>
>> *Contact emails*
>>
>> chikam...@chromium.org, sisidov...@chromium.org
>>
>> Explainer:
>>
>>-
>>
>>https://github.com/nyaxt/lazyembeds
>>
>>
>> Specification: https://github.com/nyaxt/lazyembeds
>>
>> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
>> outside the viewport when all of the following conditions are met.
>>
>>
>>-
>>
>>The loading=eager or loading=lazy attribute values are not specified
>>in the iframe tag.
>>
>>
>>-
>>
>>The iframe's src URL matches a pre-curated list of cross-origin
>>embeds (for the sake of quick experimentation).
>>
>>
>>-
>>
>>The page is visible.
>>-
>>
>>The iframe's src URL must be cross origin.
>>-
>>
>>The main frame is not loaded in the following ways. In the following
>>operations, the user probably wants to avoid any breakage caused by
>>LazyEmbeds.
>>-
>>
>>   The main frame is reloaded.
>>   -
>>
>>   The main frame is a result after the user (re)submits a form.
>>
>>
>> LazyEmbeds has a timeout mechanism that loads all the iframes that are
>> eligible for LazyEmbeds after a few seconds have elapsed even when the
>> viewport doesn't come near the iframe. This timeout mechanism is the main
>> difference between  LazyEmbeds and .
>>
>> Site authors can specify loading=eager on frames to opt-out of LazyEmbeds.
>>
>> The current LazyEmbeds implementations target a 1% stable channel for
>> data gathering purposes. We don't have any plan to release LazyEmbeds in
>> its current form. This experiment is to help us assess the potential
>> impact, in order to motivate a proper, launchable, design.
>>
>> Blink component: Blink>Loader
>> 
>>
>> TAG review
>>
>> None
>>
>> TAG review status
>>
>> Not applicable
>>
>> RisksInteroperability and Compatibility
>>
>> The goal of the experiment is to test if the idea actually improves page
>> load UX. Once that is proven, we would like to start pitching in the
>> standardization forum on having the new behavior part of the spec.
>>
>> We have a rough sketch of how it would look like in terms of
>> specification changes at https://github.com/nyaxt/lazyembeds. LazyEmbeds
>> applies a different loading schedule to offscreen cross-origin s.
>> Site authors who believe offscreen content is a critical part of the
>> user-experience may find this breaks their expectations. To restore the
>> previous behavior, authors can specify loading=eager on those frames.
>>
>> Ergonomics
>>
>> Websites don’t have to do anything.
>>
>> Activation
>>
>> LazyEmbeds works without any developer activation.
>>
>> Security and privacy
>>
>> LazyEmbeds doesn't have any security and privacy concerns.
>>
>> Goals for experimentation
>>
>> We would like to judge if this is a good idea or not before we would like
>> to validate our hypothesis using the performance data (e.g. Core Web
>> Vitals) collected through the experiment before we proceed to the next
>> steps (open-ended discussion with other vendors, involved 3rd-parties).
>>
>> Reason this experiment is being extended
>>
>> The previous timeline was to start an experimental 1% stable rollout in
>> M104. But while running experiments in M104 beta, we have noticed several
>> problems. So we would like to change the schedule. We want to restart the
>> experiment in M105 beta and 1% stable rollout in M105.
>>
>> The following are the notable differences between M104 and M105.
>>
>>-
>>
>>The main frame is not loaded in the following ways. In the following
>>operations, the user probably wants to avoid any breakage caused by
>>LazyEmbeds.
>>-
>>
>>   The main frame is reloaded.
>>   -
>>
>>   The main frame is a result after the user (re)submits a form.
>>   -
>>
>>Added a timeout mechanism that loads all the iframes that are
>>eligible for LazyEmbeds after a few seconds have elapsed even when the
>>viewport doesn't come near the iframe. This timeout mechanism is intended
>>to minimize the risk of breakage caused by LazyEmbeds.
>>-
>>
>>Expanded the pre-curated list of cross-origin embeds.
>>
>>
>> Any risks when the experiment finishes?
>>
>> No.
>>
>> 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
>> 

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Jayson Adams]

This policy, despite the proposed disclaimer paragraph, still feels like it
penalizes people who are on leave. Whether it's parental or disability or
any other kind of leave, no one should have to jump through hoops upon
their return to restart their job (or I guess why not also remove
committer status, in the interest of making things tidy, while you're at
it?).

Given that your updated list only contains 47 owners, it seems like
checking each one to see if they're on leave (and removing them if so)
would not be that big of an issue.

On Mon, Aug 1, 2022 at 6:57 AM Kentaro Hara  wrote:

> Discussed with Peter and Glen offline.
>
> I excluded per-file owners and updated the spreadsheet
> 
> (based on the data as of July 26 when I announced this).
>
> To mitigate the concern about removing long-time OOO owners and making
> them feel uncomfortable about re-adding themselves when they are back, we
> decided to add the following paragraph
>  to
> the owners guideline (which is under review):
>
> "For the purpose of not slowing down code review latency, Chromium removes
> inactive owners (e.g., those who made no contributions in the past 6
> months) on a regular basis. The script does not take into account personal
> situations like a long leave and thus can be wrong. If you are removed by
> the automated process for a wrong reason while you are being a good owner,
> you can create a CL to re-add yourself to OWNERS and land after getting
> local owner's approval. You just need to explain the reason (e.g., long
> leave) and don't need to make a substantial contribution to become an owner
> again."
>
> Manuel:
>
>> Just for completeness, there are some OWNERS files that require a
>> nomination process. At least third_party/blink/renderer/core/OWNERS
>> requires that.
>
>
> I hope the above process mitigates the concern.
>
> Matt:
>
>> Maybe it would make more sense to identify OWNERS who are not active
>> globally in chrome/, instead of owners not active in a particular
>> directory?  How common are OWNERS active in Chrome, but high latency only
>> for specific directories?
>
>
> FWIW I created a list
> 
> of OWNERS who made no commits / reviews in the past 6 months (as of July
> 26). We could take an intersection between this list and my proposed list
> but I'd prefer simply going with my proposed list with the above mitigation
> process.
>
> Peter:
>
>> I don't think that 85/6850 OWNERS entries are a large enough problem to
>> bypass local owner approval for this (i.e. land it unconditionally). If
>> some of them are owners in very active folders and have had a lot of
>> reviews assigned to them, sure. This is about 1% of ownership entries if
>> I'm understanding this correctly. How badly are they contributing to review
>> latency in order to override "and they are not on a leave during that time"
>> as a policy? I like this policy, and it's supposed to still be the policy.
>
>
> We are removing (only) 85 owners (47 owners after per-file owners are
> excluded) because we removed ~500 owners one year ago. I think it's
> important to run this cleanup process periodically to keep the codebase
> up-dated. Our Chrome infra team is now brainstorming an idea to automate
> the process of removing inactive owners.
>
>
> I'm planning to execute the cleanup next week. If you have any questions,
> please let me know. Thanks!
>
>
>
> On Sat, Jul 30, 2022 at 3:56 AM Peter Boström  wrote:
>
>> I specifically disagree with the "for this cycle, I'm planning to remove
>> the inactive owners unconditionally" bit. If you suggest this removal but
>> you defer to local OWNERS to make the call I think that's fine to send out
>> removal CLs for. I would encourage you and/or the reviewers to look at the
>> removed owner's calendar if they're internal and confirm that they've not
>> been on long-term leave.
>>
>> I don't think that 85/6850 OWNERS entries are a large enough problem to
>> bypass local owner approval for this (i.e. land it unconditionally). If
>> some of them are owners in very active folders and have had a lot of
>> reviews assigned to them, sure. This is about 1% of ownership entries if
>> I'm understanding this correctly. How badly are they contributing to review
>> latency in order to override "and they are not on a leave during that time"
>> as a policy? I like this policy, and it's supposed to still be the policy.
>>
>> If any of these OWNERS entries had a significant amount of reviews
>> assigned to them during this period (i.e. sorta-evidence of latency), you
>> could use that as additional justification in the CLs to get the OWNERS to
>> approve the (possibly temporary) removal.
>>
>> For fixing review latency which is the real goal pre

Re: [blink-dev] Intent to Ship: CSS Overflow for replaced elements

[Yoav Weiss]

On Mon, Jul 25, 2022 at 7:44 PM Khushal Sagar 
wrote:

>
>
> On Wed, Jul 20, 2022 at 5:17 AM Yoav Weiss  wrote:
>
>> Thanks Khushal! :)
>>
>> The breakage seems potentially significant (at worst, makes the site
>> visually broken and unusable), and the percentage of breakage seems above
>> the threshold we typically consider safe.
>> At the same time this seems like a positive change, and our friends at
>> Mozilla consider it "worth prototyping".
>>
>> Would it be possible to consider this as a deprecation of the old
>> behavior, and run the console issue (+deprecation warnings and outreach to
>> affected sites) for a few milestones, to try and drive the usage down
>> before flipping this change to be on by default? Maybe also get some
>> documentation out there and work with devrel folks to make sure folks are
>> aware of this coming change?
>>
>> Does that sound reasonable?
>>
>
> Thanks for the suggestion Yoav. This sounds reasonable. I've reached out
> to the devrel folks to do more outreach about this change. I'll update this
> thread with the plan for it. The console issue and deprecation warnings
> have been added in M105.
>
> I looked into adding a use counter for sites which have real breakage,
> since the current metric tracks whether the computed style *could* permit
> allow but not whether there is actual overflow at paint time. And
> unfortunately computing potential overflow is not easy to add. The CT
> analysis I ran earlier did this by turning the feature on and tracking
> actual overflow generated by the element. So a couple of questions for
> moving forward:
>
> - Would it be okay to turn the feature on in beta and 1% stable (in M105)
> to collect metrics for the sites with real breakage and the extent of this
> breakage (how many pixels of overflow do we see). This should be lower than
> the counter of 0.017%.
>

That sounds like a great way to gather data! (assuming the relevant Chrome
processes are followed)
Would be good to gather a histogram of overflowed pixels, to get a sense of
"small breakage" vs. "large breakage".


>
> - What's the number (in terms of page loads affected) we should be
> targeting before this would be safe?
>

>From my perspective, I'd be comfortable shipping this if we're seeing less
than 0.003% of page loads in the "large breakage" bucket (say more than
~5000 overflowing pixels, assuming that number makes sense).

+Andre Bandarra  - for devrel opinions on this.


>
>
>>
>> Cheers,
>> Yoav
>>
>> On Thursday, July 14, 2022 at 5:03:54 PM UTC+2 Khushal Sagar wrote:
>>
>>> Hey folks,
>>>
>>> I'm summarizing the steps to mitigate the compat risk with this feature
>>> based on the feedback:
>>>
>>>- Add a warning to the console when a developer style would permit
>>>replaced elements to overflow. The patch to add that is here
>>> and
>>>documentation to help developers debug, which is referenced in the 
>>> console
>>>warning, is here
>>>.
>>>We can pre-emptively add this warning to M105 and ship the feature in 
>>> M106
>>>to have a one release window before the behaviour changes.
>>>
>>>- Send an email to the webmaster of sites surfaced in the CT
>>>analysis which already have the styles that trigger the warning above.
>>>
>>> In addition to the above, the feature can be turned off with a
>>> server-side config using finch if there is any severe breakage.
>>>
>>> Please let me know if the above suffices.
>>>
>>> Thanks.
>>> Khushal
>>>
>>> On Wed, Jul 13, 2022 at 4:11 PM Khushal Sagar 
>>> wrote:
>>>


 On Wed, Jul 13, 2022 at 3:44 PM Mike Taylor 
 wrote:

> On 7/13/22 3:04 PM, Khushal Sagar wrote:
>
>
>
> On Wed, Jul 13, 2022 at 6:12 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Wednesday, July 13, 2022 at 3:54:28 AM UTC+2 Khushal Sagar wrote:
>>
>>> On Mon, Jul 11, 2022 at 11:40 AM Yoav Weiss 
>>> wrote:
>>>


 On Fri, Jul 8, 2022 at 7:22 PM Khushal Sagar <
 khushalsa...@chromium.org> wrote:

> Contact emails khushalsa...@chromium.org, vmp...@chromium.org
>
> Explainer
> https://github.com/WICG/shared-element-transitions/blob/main/overflow-on-replaced-elements.md
> https://github.com/w3c/csswg-drafts/issues/7058
>
> Specification
> https://drafts.csswg.org/css-overflow/#overflow-properties
>
> Summary
>
> This change allows developers to use the existing `overflow`
> property with replaced elements that paint outside the content-box. 
> Paired
> with `object-view-box` this can be used to create an image with a 
> custom
> glow or shadow applied, with proper ink-overflow behavior like a CSS 
> shadow
> would have.
>
> Blin

[blink-dev] Ready for Trial: Quick intensive timer throttling of loaded background pages

[Zhang, Jiahe]

Contact emails
jiahe.zh...@intel.com, 
fdo...@chromium.org


Specification
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html


Design docs

https://docs.google.com/document/d/1WFyfKUUxqM7uKxKOGhLiOjyY6T7QRduVcuHN0f6vJkk/edit


Summary

Enter Intensive Wake Up throttling after 10 seconds if the page is fully loaded 
when it becomes hidden. Currently, wake ups from JS timers with a nesting level 
>= 5 are throttled to 1 per minute after the page has spent 5 minutes in the 
background [1], which is very conservative and was chosen to allow a launch of 
Intensive Wake Up Throttling with minimal regression risk. We're now planning 
to reduce this timeout to 10 seconds if the page is fully loaded when hidden. 
[1] https://chromestatus.com/feature/4718288976216064


Blink component
Blink>Scheduling


TAG review
Not applicable. This feature changes the behavior of an existing API, while 
remaining spec-compliant ("Optionally, wait a further implementation-defined 
length of 
time.")


Risks



Interoperability and Compatibility

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals: The more conservative version of Intensive Wake Up Throttling 
shipped smoothly to 100% Stable more than 1 year ago. A few bugs were filed, 
but in all cases we've been able to propose workarounds which made apps more 
efficient 
(example).


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, this feature will only ship on desktop platforms.



Goals for experimentation
We plan to experiment on 1% Stable to confirm whether we observe the same 
memory and power improvements as in the lab and on lower channels. We will 
decide whether this intervention ships based on the experiment data.


Ongoing technical constraints
None


Debuggability

This is not a new Web Platform feature.


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

This feature will only ship on desktop platforms. On Android, the system 
severely limits resource consumption from background renderers, which makes 
this feature unnecessary.


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


Flag name
quick-intensive-throttling-after-loading


Requires code in //chrome?
False


Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1324656


Estimated milestones
DevTrial on desktop
105


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

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/MWHPR11MB1520EBDCBC6F0C4D35F7111BF49A9%40MWHPR11MB1520.namprd11.prod.outlook.com.

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

['Christian Dullweber' via blink-dev]

I looked into the first 10 entries manually and there are multiple cases
where I don't think it is correct to remove them.

There are people who are on long term leave and are indicating this in
their status message.
I would be quite annoyed if I had to figure out all the files I was
owner for and restore this when I come back from a leave.
Could you check for each person you want to remove if the status message
has an indication that the OWNER is only temporarily inactive?

There are also otherwise active owners who have a comment that limits their
ownership to a subset of files.
I wonder why it would be useful to remove people who are otherwise active
just because they haven't reviewed files in a certain directory?

There are also per-file owners but I guess the list just isn't updated yet?

As an alternative to implementing the suggestions above:
How about sending CLs with autosubmit enabled for each removal to all
owners of the corresponding file and see if they agree with the removal or
not?



On Mon, 1 Aug 2022 at 15:56, Kentaro Hara  wrote:

> Discussed with Peter and Glen offline.
>
> I excluded per-file owners and updated the spreadsheet
> 
> (based on the data as of July 26 when I announced this).
>
> To mitigate the concern about removing long-time OOO owners and making
> them feel uncomfortable about re-adding themselves when they are back, we
> decided to add the following paragraph
>  to
> the owners guideline (which is under review):
>
> "For the purpose of not slowing down code review latency, Chromium removes
> inactive owners (e.g., those who made no contributions in the past 6
> months) on a regular basis. The script does not take into account personal
> situations like a long leave and thus can be wrong. If you are removed by
> the automated process for a wrong reason while you are being a good owner,
> you can create a CL to re-add yourself to OWNERS and land after getting
> local owner's approval. You just need to explain the reason (e.g., long
> leave) and don't need to make a substantial contribution to become an owner
> again."
>
> Manuel:
>
>> Just for completeness, there are some OWNERS files that require a
>> nomination process. At least third_party/blink/renderer/core/OWNERS
>> requires that.
>
>
> I hope the above process mitigates the concern.
>
> Matt:
>
>> Maybe it would make more sense to identify OWNERS who are not active
>> globally in chrome/, instead of owners not active in a particular
>> directory?  How common are OWNERS active in Chrome, but high latency only
>> for specific directories?
>
>
> FWIW I created a list
> 
> of OWNERS who made no commits / reviews in the past 6 months (as of July
> 26). We could take an intersection between this list and my proposed list
> but I'd prefer simply going with my proposed list with the above mitigation
> process.
>
> Peter:
>
>> I don't think that 85/6850 OWNERS entries are a large enough problem to
>> bypass local owner approval for this (i.e. land it unconditionally). If
>> some of them are owners in very active folders and have had a lot of
>> reviews assigned to them, sure. This is about 1% of ownership entries if
>> I'm understanding this correctly. How badly are they contributing to review
>> latency in order to override "and they are not on a leave during that time"
>> as a policy? I like this policy, and it's supposed to still be the policy.
>
>
> We are removing (only) 85 owners (47 owners after per-file owners are
> excluded) because we removed ~500 owners one year ago. I think it's
> important to run this cleanup process periodically to keep the codebase
> up-dated. Our Chrome infra team is now brainstorming an idea to automate
> the process of removing inactive owners.
>
>
> I'm planning to execute the cleanup next week. If you have any questions,
> please let me know. Thanks!
>
>
>
> On Sat, Jul 30, 2022 at 3:56 AM Peter Boström  wrote:
>
>> I specifically disagree with the "for this cycle, I'm planning to remove
>> the inactive owners unconditionally" bit. If you suggest this removal but
>> you defer to local OWNERS to make the call I think that's fine to send out
>> removal CLs for. I would encourage you and/or the reviewers to look at the
>> removed owner's calendar if they're internal and confirm that they've not
>> been on long-term leave.
>>
>> I don't think that 85/6850 OWNERS entries are a large enough problem to
>> bypass local owner approval for this (i.e. land it unconditionally). If
>> some of them are owners in very active folders and have had a lot of
>> reviews assigned to them, sure. This is about 1% of ownership entries if
>> I'm understanding this correctly. How badly are they contributing to review
>> latency in ord

Re: [blink-dev] Intent to Ship: MSE in Workers

[Mike Taylor]

LGTM3

On 8/1/22 8:05 AM, Yoav Weiss wrote:

LGTM2

On Fri, Jul 29, 2022 at 12:40 AM slightlyoff via Chromestatus 
> wrote:


LGTM1
-- 
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/eea04c05e4e53819%40google.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/CAL5BFfWsqYRjB%3DqCuu4UxHzEa%2B%2B2SqkDJdE8W8sUNCnS%2BwoH5w%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/91d78e87-3241-0719-eb2a-a7e8d21afd0b%40chromium.org.

Re: [blink-dev] A quick survey on setting up fuzzy match rules to identify resolvable flaky web tests

[Xianzhu Wang]

On Mon, Aug 1, 2022 at 4:25 AM Stephen Chenney 
wrote:

> Thanks for investigating the potential for fuzzy matching.
>
> Rendering Core continues to oppose a single fuzzy match rule across all
> web_tests. We have some tests where single pixel differences matter
> (related to pixel snapping, for example) and a universal fuzzy match would
> fail to identify problems with those. This came up in practice recently
> when the GPU team enabled fuzzy matching without telling us, and expected
> failing tests started passing when they shouldn't.
>

I think a key difference between the original fuzzy matching rule and the
rule proposed by Vivian is the ranges. With maxDifference=0-1, we should be
able to catch most visible single pixel differences. What I'm not sure is
whether a difference like rgb(1, 0, 0) vs rgb(0, 0, 0) (each component in
the range of 0-255) should be treated as a failure in some cases.

Maybe specific sub teams have directories they could apply default fuzzy
> matching to. My guess is that the same directories where it will work will
> be directories with few failing tests, limiting the impact of a
> per-directory approach.
>
> Is there a way to reproduce the sampling below with a side-by-side
> comparison of the images? I would find it helpful to look through some of
> the cases that would pass with ,
> for example.
>

A filter by actual maxDifference and totalPixels in results.html will be
helpful. I can add it when I get time.

Stephen.
>
> On Fri, Jul 29, 2022 at 8:20 PM 'Vivian Zhi (支文文）' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi blink-dev
>>
>> I would like to let you know that blink-engprod has added feature support
>> for non-WPT fuzzy tests. It now allows both non-WPT reftests and pixel
>> tests to use the same fuzzy matching meta-tags as WPT tests.It also shows
>> max color channel difference and total number of different pixels image
>> diff stats in results.html
>> .
>> With these capabilities in place, we like to research further to see if we
>> can set up some general fuzzy match rules, help blink dev identify flaky
>> tests that can be potentially resolved by adjusting fuzzy matching rules.
>> Currently there are quite some web tests that are flaky due to a slight
>> image mismatch, which should have been tolerated. If we setup a general
>> fuzzy matching rule , something like:
>>
>>  
>>
>> Instruct the image comparison web tests that if color channel and pixel
>> diff fall within the range of the rule, we can ignore the diff and pass the
>> test.This way we can reduce test flakiness while still maintain test
>> accuracy without missing a real bug.
>>
>> We want to ask you some quick survey questions to help us make design
>> decisions, whether it makes sense to set up an universal cross-the-board
>> fuzzy match tolerant rule for all blink web tests, or we should make the
>> rules more specific to individual test or test sets.
>>
>> 1.  Is an universal fuzzy match tolerant rule acceptable for the web
>> tests in your area?
>>
>> a). If the answer is yes, what is the acceptable range of max color
>> channel and pixel diff for your tests?
>> b) If the answer is no, pls share your reasons.
>>
>> 2. Do you prefer fuzzy matching rule adjustment at a per-test or per test
>> set level based on the pixel difference numbers shown in results.html?
>>
>> Here is some sample data help you make choice, we collected data recently
>> from blink_web_tests result on linux-test builder, the distribution of
>> color channel maxDifference and totalPixel diff for failing/flaky
>> blink_web_tests
>> ( Note: over 70% tests in color channel maxDifference 0-10 range have
>> maxDifference=1):
>>
>> Color Channel maxDifferenece
>> Range Fail test count
>> 0-10 98
>> 11-100 31
>> 101-200 28
>> 201-260 111
>> totalPixels
>> Diff Range
>> Fail test count
>> 0-100 30
>> 100-1000 57
>> 1000-10,000 99
>> 10,000-100,000 66
>> 100,000-1,000,000 16
>>
>> Let me know if you have any questions, looking forward to hearing from
>> you!
>>
>>
>> Vivian
>> on behalf of Chrome-Blink-EngProd
>>
>> --
>> 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/CAPCqkTs-L5u22-Xp5U_LeBdLP%3D%2BTDH1KGv8MTmtKQFRcANCZJg%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 bli

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[K. Moon]

Given the amount of discussion this topic has generated, I almost wonder if
the, "Let's just run this script and fix any problems later," approach is
actually taking more time in total than something more nuanced.

Also, is there an AI for any team to follow up on some of the suggestions
about surfacing OOO status, or other sources of high review latency?

On Mon, Aug 1, 2022 at 8:22 AM Christian Dullweber 
wrote:

> I looked into the first 10 entries manually and there are multiple cases
> where I don't think it is correct to remove them.
>
> There are people who are on long term leave and are indicating this in
> their status message.
> I would be quite annoyed if I had to figure out all the files I was
> owner for and restore this when I come back from a leave.
> Could you check for each person you want to remove if the status message
> has an indication that the OWNER is only temporarily inactive?
>
> There are also otherwise active owners who have a comment that limits
> their ownership to a subset of files.
> I wonder why it would be useful to remove people who are otherwise active
> just because they haven't reviewed files in a certain directory?
>
> There are also per-file owners but I guess the list just isn't updated yet?
>
> As an alternative to implementing the suggestions above:
> How about sending CLs with autosubmit enabled for each removal to all
> owners of the corresponding file and see if they agree with the removal or
> not?
>
>
>
> On Mon, 1 Aug 2022 at 15:56, Kentaro Hara  wrote:
>
>> Discussed with Peter and Glen offline.
>>
>> I excluded per-file owners and updated the spreadsheet
>> 
>> (based on the data as of July 26 when I announced this).
>>
>> To mitigate the concern about removing long-time OOO owners and making
>> them feel uncomfortable about re-adding themselves when they are back, we
>> decided to add the following paragraph
>>  to
>> the owners guideline (which is under review):
>>
>> "For the purpose of not slowing down code review latency, Chromium
>> removes inactive owners (e.g., those who made no contributions in the past
>> 6 months) on a regular basis. The script does not take into account
>> personal situations like a long leave and thus can be wrong. If you are
>> removed by the automated process for a wrong reason while you are being a
>> good owner, you can create a CL to re-add yourself to OWNERS and land after
>> getting local owner's approval. You just need to explain the reason (e.g.,
>> long leave) and don't need to make a substantial contribution to become an
>> owner again."
>>
>> Manuel:
>>
>>> Just for completeness, there are some OWNERS files that require a
>>> nomination process. At least third_party/blink/renderer/core/OWNERS
>>> requires that.
>>
>>
>> I hope the above process mitigates the concern.
>>
>> Matt:
>>
>>> Maybe it would make more sense to identify OWNERS who are not active
>>> globally in chrome/, instead of owners not active in a particular
>>> directory?  How common are OWNERS active in Chrome, but high latency only
>>> for specific directories?
>>
>>
>> FWIW I created a list
>> 
>> of OWNERS who made no commits / reviews in the past 6 months (as of July
>> 26). We could take an intersection between this list and my proposed list
>> but I'd prefer simply going with my proposed list with the above mitigation
>> process.
>>
>> Peter:
>>
>>> I don't think that 85/6850 OWNERS entries are a large enough problem to
>>> bypass local owner approval for this (i.e. land it unconditionally). If
>>> some of them are owners in very active folders and have had a lot of
>>> reviews assigned to them, sure. This is about 1% of ownership entries if
>>> I'm understanding this correctly. How badly are they contributing to review
>>> latency in order to override "and they are not on a leave during that time"
>>> as a policy? I like this policy, and it's supposed to still be the policy.
>>
>>
>> We are removing (only) 85 owners (47 owners after per-file owners are
>> excluded) because we removed ~500 owners one year ago. I think it's
>> important to run this cleanup process periodically to keep the codebase
>> up-dated. Our Chrome infra team is now brainstorming an idea to automate
>> the process of removing inactive owners.
>>
>>
>> I'm planning to execute the cleanup next week. If you have any questions,
>> please let me know. Thanks!
>>
>>
>>
>> On Sat, Jul 30, 2022 at 3:56 AM Peter Boström  wrote:
>>
>>> I specifically disagree with the "for this cycle, I'm planning to remove
>>> the inactive owners unconditionally" bit. If you suggest this removal but
>>> you defer to local OWNERS to make the call I think that's fine to send out
>>> removal CLs for. I would encourage you 

[blink-dev] Re: Intent to Extend Origin Trial: MSE in Workers

[Yoav Weiss]

LGTM to continue the experiment through M104.

On Wed, Jul 27, 2022 at 9:57 PM Matthew Wolenetz 
wrote:

> I need to request a further extension of this origin trial, to end in M104
> instead of the current end of 103.
>
> While I've just sent the intent-to-ship for this feature
>  (with
> target milestone 105), I have just received a request from another major
> web developer for the origin trial to be extended into 104.
>
> The full implementation and stabilization of this feature didn't land
> until early in the 105 milestone due to some API changes requested by
> participants in the media workgroup discussions of this feature.
> While these changes in 105 are not expected to be part of the origin
> trial, the bulk of the MSE-in-Workers implementation remains usable via the
> origin-trial-feature "MediaSourceInWorkers" using the older API shape.
> The primary change in the API shape is to use a MediaSourceHandle for
> attaching a worker MediaSource instead of a MediaSource object URL.
> Extending the OT into 104 will enable experimentation as requested by the
> web developer.
>
> Please review this request and advise on next steps. Note, this is not
> intended to replace the intent to ship in 105 for this feature, but instead
> to let the feature continue to be experimented with in 104.
>
> Thank you,
> Matt
>
> On Wed, Feb 23, 2022 at 9:06 AM Matthew Wolenetz 
> wrote:
>
>> Thank you. The results so far have been very encouraging, so I expect no
>> further extension would be necessary beyond 103.
>>
>> On Wed, Feb 23, 2022 at 5:18 AM Yoav Weiss 
>> wrote:
>>
>>> LGTM to continue experimenting till M103. Note that this will bring the
>>> OT to 9 releases, so it'd be good to wrap up experimentation by this
>>> extension's end.
>>>
>>> On Wednesday, February 16, 2022 at 11:03:08 PM UTC+1 Matthew Wolenetz
>>> wrote:
>>>
 Hello blink-dev,

 We'd like to ask for an extension to our Origin Trial, from M99 to M103.

 There are two reasons extension is necessary:

 1) A breaking error discovered in the middle of the trial (see
 https://crbug.com/1268614) caused participation to drop before the
 2021 holiday period. While the fix landed by early 2022 and at least one
 participant has reported excellent improvement in metrics in their
 experiment since then, further stabilization is desired.

 2) An API change for this feature (using srcObject for MSE-in-Workers
 attachments instead of baking in objectURL attachment further) was agreed
 with the media workgroup last September [1] following the previous
 objectURL-based attachment design getting more recent feedback [2], and I'm
 working on getting that into both the feature spec and Chromium's
 experimental implementation currently for rapid experimentation during the
 extended trial.

 [1] https://www.w3.org/2021/09/14-mediawg-minutes.html
 [2] https://github.com/mozilla/standards-positions/issues/547


 Please find the Chrome status template, below:


 Contact emailswolen...@chromium.org

 Explainer
 https://github.com/wicg/media-source/blob/mse-in-workers-using-handle/mse-in-workers-using-handle-explainer.md

 Specificationhttps://github.com/w3c/media-source/pull/282

 Summary

 Enable Media Source Extensions (MSE) API usage from DedicatedWorker
 contexts to enable improved performance of buffering media for playback by
 an HTMLMediaElement on the main Window context. By creating a MediaSource
 object on a DedicatedWorker context, an application may then create an
 ObjectURL for it and postMessage that URL to the main thread for use in
 attaching to an HTMLMediaElement. The context that created the MediaSource
 object may then use it to buffer media.


 Blink componentBlink>Media
 

 Search tagsMSE ,
 MediaSource ,
 MediaSourceExtensions
 

 TAG reviewhttps://github.com/w3ctag/design-reviews/issues/656

 TAG review statusIssues addressed

 Risks


 Interoperability and Compatibility

 Main interoperability risk is that other browsers may not implement it.
 Compatibility risk is mitigated by unchanged same-thread MSE API support
 and proactive feature-detectability of MSE-in-Workers with a new
 canConstructInDedicatedWorker attribute on the MediaSource interface.


 Gecko: No signal (
 https://github.com/mozilla/standards-positions/issues/547)

 WebKit: No signal (
 https://lists.webkit.org/pipermail/webkit-dev/2021-June/031916.html)

 Web developers: No signals

>>>

Re: [blink-dev] Intent to Ship: MSE in Workers

[Yoav Weiss]

LGTM2

On Fri, Jul 29, 2022 at 12:40 AM slightlyoff via Chromestatus <
admin+slightly...@cr-status.appspotmail.com> wrote:

> LGTM1
>
> --
> 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/eea04c05e4e53819%40google.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/CAL5BFfWsqYRjB%3DqCuu4UxHzEa%2B%2B2SqkDJdE8W8sUNCnS%2BwoH5w%40mail.gmail.com.

Re: [blink-dev] Re: PSA: Multi-Screen Window Placement implementation change (Accurate Screen Labels)

[Yoav Weiss]

As this is changing a returned string that developers didn't have any
particular reasons to make any assumptions about, this change seems safe
enough. Low usage
 is also
instilling confidence. Thanks for PSAing! :)

On Wed, Jul 27, 2022 at 11:19 PM 'Ajay Rahatekar' via blink-dev <
blink-dev@chromium.org> wrote:

> Please let us know of any comments/concerns. As mentioned in the PSA, we
> are hoping to target M105 for shipping this change.
>
> Thanks in advance.
>
> On Friday, July 22, 2022 at 1:05:36 PM UTC-7 Brad Triebwasser wrote:
>
>> Hello blink-dev,
>>
>> Following previous guidance, I would like to distribute this PSA
>> regarding an implementation change for a previously shipped Multi Screen
>> Window Placement API surface. In particular, we are changing Chrome's
>> implementation of the ScreenDetailed.label attribute.
>>
>>
>> See below for the specifics of this change including the implementation
>> and launch bugs. We are currently targeting a launch in M105.
>>
>>
>> Contact emails
>>
>> btr...@chromium.org, m...@chromium.org
>>
>>
>> Explainer
>>
>>
>> https://github.com/w3c/window-placement/blob/main/EXPLAINER.md#:~:text=DOMString%20label
>> 
>>
>>
>> Specification
>>
>> https://w3c.github.io/window-placement/#dom-screendetailed-label
>>
>>
>> Summary
>>
>> Enhances screen label strings provided by the Multi-Screen Window
>> Placement API: 
>>
>>
>> This launch refines the `ScreenDetailed.label` implementation by
>> replacing the current placeholder values (e.g. 'External Display 1') with
>> data sourced from display device EDIDs (e.g. 'HP Z27n') and higher-level OS
>> APIs (e.g. localized descriptions such as 'Built-in Retina Display'). These
>> more accurate labels match those shown by OSes in display settings UI
>> surfaces. The labels are only exposed to sites which have been granted the
>> window-placement permission by the user.
>>
>>
>> This revised implementation aligns with the current attribute
>> specification  and
>> definitions used for the M93-M96 Origin Trial and the M100 API launch.
>> There is no structural change to the API, only a change in the string
>> content returned by the `ScreenDetailed.label` attribute. The new labels
>> are intended to allow the end user to better identify and tell the
>> difference between screens. Applications can’t assume that the label
>> contains any specific information, such as the device type, model,
>> dimensions, density, etc.
>>
>>
>> Blink component
>>
>> Blink>Screen>MultiScreen
>> 
>>
>>
>> Motivation
>>
>> Multi-Screen Window Placement API partners have requested this change to
>> provide more recognizable and user-friendly entries in screen selection
>> interfaces.
>>
>>
>> Initial public proposal
>>
>>
>> https://github.com/w3c/window-placement/blob/f2386c13d879aa3a84e3a46e380d00a663644654/EXPLAINER.md#:~:text=DOMString%20label
>>
>>
>> TAG review
>>
>> The original window placement API design review is here:
>>
>> https://github.com/w3ctag/design-reviews/issues/602
>>
>>
>> TAG review status
>>
>> Issues open
>>
>>
>> Risks
>> Interoperability and Compatibility
>>
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/542) Link is for
>> the original window placement API which has some feedback but no definitive
>> signal.
>>
>>
>> WebKit: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2021-June/031903.html)
>> Link is for the original window placement API which has some feedback but
>> no definitive signal.
>>
>>
>> Web developers: Positive
>>
>> (Specifically requested by Multi-Screen Window Placement API partners)
>>
>>
>> Other signals:
>>
>> WebView application risks
>> N/A
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> The Multi-Screen Window Placement API is currently available only on
>> desktop platforms (Windows, Mac, Linux, Chrome OS).
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes. WPTs are limited to checking the string type for now.
>>
>>
>> https://wpt.fyi/results/screen-details/getScreenDetails.tentative.https.window.html
>>
>>
>> DevTrial instructions
>>
>> https://github.com/w3c/window-placement/blob/main/HOWTO.md
>>
>>
>> Flag name
>>
>> --enable-blink-features=WindowPlacementEnhancedScreenLabels
>>
>>
>> Requires code in //chrome?
>>
>> False
>>
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1254885
>>
>>
>> Launch bug
>>
>> https://bugs.chromium.org/p/chromium/issues/deta

Re: [blink-dev] Intent to Extend Experiment: LazyEmbeds

[Yoav Weiss]

A change of schedule doesn't really qualify as an experiment extension. My
LGTM from the previous intent
 still
stands.

On Mon, Aug 1, 2022 at 12:16 PM Minoru Chikamune 
wrote:

> *Contact emails*
>
> chikam...@chromium.org, sisidov...@chromium.org
>
> Explainer:
>
>-
>
>https://github.com/nyaxt/lazyembeds
>
>
> Specification: https://github.com/nyaxt/lazyembeds
>
> Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
> outside the viewport when all of the following conditions are met.
>
>
>-
>
>The loading=eager or loading=lazy attribute values are not specified
>in the iframe tag.
>
>
>-
>
>The iframe's src URL matches a pre-curated list of cross-origin embeds
>(for the sake of quick experimentation).
>
>
>-
>
>The page is visible.
>-
>
>The iframe's src URL must be cross origin.
>-
>
>The main frame is not loaded in the following ways. In the following
>operations, the user probably wants to avoid any breakage caused by
>LazyEmbeds.
>-
>
>   The main frame is reloaded.
>   -
>
>   The main frame is a result after the user (re)submits a form.
>
>
> LazyEmbeds has a timeout mechanism that loads all the iframes that are
> eligible for LazyEmbeds after a few seconds have elapsed even when the
> viewport doesn't come near the iframe. This timeout mechanism is the main
> difference between  LazyEmbeds and .
>
> Site authors can specify loading=eager on frames to opt-out of LazyEmbeds.
>
> The current LazyEmbeds implementations target a 1% stable channel for data
> gathering purposes. We don't have any plan to release LazyEmbeds in its
> current form. This experiment is to help us assess the potential impact, in
> order to motivate a proper, launchable, design.
>
> Blink component: Blink>Loader
> 
>
> TAG review
>
> None
>
> TAG review status
>
> Not applicable
>
> RisksInteroperability and Compatibility
>
> The goal of the experiment is to test if the idea actually improves page
> load UX. Once that is proven, we would like to start pitching in the
> standardization forum on having the new behavior part of the spec.
>
> We have a rough sketch of how it would look like in terms of specification
> changes at https://github.com/nyaxt/lazyembeds. LazyEmbeds applies a
> different loading schedule to offscreen cross-origin s. Site
> authors who believe offscreen content is a critical part of the
> user-experience may find this breaks their expectations. To restore the
> previous behavior, authors can specify loading=eager on those frames.
>
> Ergonomics
>
> Websites don’t have to do anything.
>
> Activation
>
> LazyEmbeds works without any developer activation.
>
> Security and privacy
>
> LazyEmbeds doesn't have any security and privacy concerns.
>
> Goals for experimentation
>
> We would like to judge if this is a good idea or not before we would like
> to validate our hypothesis using the performance data (e.g. Core Web
> Vitals) collected through the experiment before we proceed to the next
> steps (open-ended discussion with other vendors, involved 3rd-parties).
>
> Reason this experiment is being extended
>
> The previous timeline was to start an experimental 1% stable rollout in
> M104. But while running experiments in M104 beta, we have noticed several
> problems. So we would like to change the schedule. We want to restart the
> experiment in M105 beta and 1% stable rollout in M105.
>
> The following are the notable differences between M104 and M105.
>
>-
>
>The main frame is not loaded in the following ways. In the following
>operations, the user probably wants to avoid any breakage caused by
>LazyEmbeds.
>-
>
>   The main frame is reloaded.
>   -
>
>   The main frame is a result after the user (re)submits a form.
>   -
>
>Added a timeout mechanism that loads all the iframes that are eligible
>for LazyEmbeds after a few seconds have elapsed even when the viewport
>doesn't come near the iframe. This timeout mechanism is intended to
>minimize the risk of breakage caused by LazyEmbeds.
>-
>
>Expanded the pre-curated list of cross-origin embeds.
>
>
> Any risks when the experiment finishes?
>
> No.
>
> 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, through the experiment phase, but if the idea proves to be useful
> through the experiment and makes it to the spec, we will add WPTs to cover
> them.
>
> Tracking bug
>
> https://crbug.com/1247131
>
> Launch bug
>
> https://crbug.com/1247130
>
> Links to previous Intent discussions
>
> N/A
>
> Link to entry on the feature das

Re: [blink-dev] Intent to Extend Deprecation Trial: Restrict "private network requests" for subresources from public websites to secure contexts.

[Yoav Weiss]

LGTM to extend the deprecation trial from M107 to *M109* (inclusive). If
further extension is needed, I'd love to hear back from y'all on progress
you're making in outreach to affected sites, and in them adopting the user
permission model.

On Sat, Jul 30, 2022 at 2:20 AM Jonathan Hao  wrote:

> Contact emails
>
>
> *tito...@chromium.org  (on leave),
> cl...@chromium.org , v...@chromium.org
> , l...@chromium.org , p...@chromium.org
>  *Explainer
>
>
> *https://github.com/WICG/private-network-access/blob/master/explainer.md
> *
> Specification
>
>
> *https://wicg.github.io/private-network-access/
> *Design docs
>
>
> *https://docs.google.com/document/d/1x1a1fQLOrcWogK3tpFBgQZQ5ZjcONTvD0IqqXkgrg5I/edit#heading=h.7nki9mck5t64
> *
> Summary
>
>
>
> *Requires that private network requests for subresources from public
> websites may only be initiated from a secure context. Examples include
> internet to intranet requests and internet to loopback requests. This is a
> first step towards fully implementing Private Network Access:
> https://wicg.github.io/private-network-access/
> *Reason this trial is
> being extended
>
>
>
> *The first phase of the PNA project was to prohibit public HTTP pages from
> making requests on the private network. Because some pages require this, we
> implemented a deprecation trial that sites can use to maintain
> functionality. As described in this doc
> ,
> we have now realized that there are legitimate use cases for this
> functionality, and no good workaround for websites. So we decided to allow
> Mixed contents restrictions to be relaxed to allow an HTTPS page to request
> HTTP resources on the private network.  We are currently implementing a
> permission prompt
> 
> for users to give the aforementioned permission and aim to ship it in
> M107.  An extension is necessary to give web developers time to upgrade
> their pages to HTTPS.Previous experiment timeline: M94 to M106Requested
> extension timeline: M107 to M113*Blink component
>
>
> *Blink>SecurityFeature>CORS>PrivateNetworkAccess
> *TAG
> review
>
>
> *https://github.com/w3ctag/design-reviews/issues/572
> *TAG review status
>
>
> *Completed*Risks
>
> Interoperability and CompatibilityNo interoperability risks.
> Compatibility risk is small but non-negligible. UseCounters show ~0.1% of
> page visit making use of this feature. Direct outreach to the largest users
> per UKM data revealed no objections to this launch.
>
>
>
>
>
>
>
> *Rolling this deprecation out to beta per the previous I2S resulted in
> more feedback about the compatibility risk and the need for a time
> extension. See the following doc for an extensive discussion:
> https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit
> Gecko:
> Worth prototyping
> (https://github.com/mozilla/standards-positions/issues/143
> ) Tentatively
> positive, but no formal position yet.WebKit: Positive
> (https://lists.webkit.org/pipermail/webkit-dev/2021-May/031837.html
> )Web
> developers: Negative
> (https://docs.google.com/document/d/1bpis0QwaA9ZrRFmpPW6LiaPmdwT0UhhUMNsEnU0zfLk/edit
> )
> Some websites, broadly falling in the category of controller webapps for
> IoT devices, find this change incompatible with their use cases. While many
> use cases can be solved with specific workarounds, some still require
> further engagement.Other signals:*Activation
>
>
>
>
> *Developers of non-secure sites that rely upon local servers will need to
> upgrade to HTTPS. This might cause some complications, as mixed-content
> checks will begin to apply unless users give explicit permission. Chrome
> carves out HTTP access to loopback (as per
> https://w3c.github.io/webappsec-secure-contexts/#localhost
> ), which is a
> release valve for folks who don't want to go through the effort of
> securely-distributing certs for local servers.The initial launch in M92 was
> delayed due to compatibility risks surfaced during the rollout to beta. See
> this doc for a lot more details:
> https:/

Re: [chromium-dev] Re: [blink-dev] Inactive OWNERS cleanup

[Kentaro Hara]

Discussed with Peter and Glen offline.

I excluded per-file owners and updated the spreadsheet

(based on the data as of July 26 when I announced this).

To mitigate the concern about removing long-time OOO owners and making them
feel uncomfortable about re-adding themselves when they are back, we
decided to add the following paragraph
 to the
owners guideline (which is under review):

"For the purpose of not slowing down code review latency, Chromium removes
inactive owners (e.g., those who made no contributions in the past 6
months) on a regular basis. The script does not take into account personal
situations like a long leave and thus can be wrong. If you are removed by
the automated process for a wrong reason while you are being a good owner,
you can create a CL to re-add yourself to OWNERS and land after getting
local owner's approval. You just need to explain the reason (e.g., long
leave) and don't need to make a substantial contribution to become an owner
again."

Manuel:

> Just for completeness, there are some OWNERS files that require a
> nomination process. At least third_party/blink/renderer/core/OWNERS
> requires that.


I hope the above process mitigates the concern.

Matt:

> Maybe it would make more sense to identify OWNERS who are not active
> globally in chrome/, instead of owners not active in a particular
> directory?  How common are OWNERS active in Chrome, but high latency only
> for specific directories?


FWIW I created a list

of OWNERS who made no commits / reviews in the past 6 months (as of July
26). We could take an intersection between this list and my proposed list
but I'd prefer simply going with my proposed list with the above mitigation
process.

Peter:

> I don't think that 85/6850 OWNERS entries are a large enough problem to
> bypass local owner approval for this (i.e. land it unconditionally). If
> some of them are owners in very active folders and have had a lot of
> reviews assigned to them, sure. This is about 1% of ownership entries if
> I'm understanding this correctly. How badly are they contributing to review
> latency in order to override "and they are not on a leave during that time"
> as a policy? I like this policy, and it's supposed to still be the policy.


We are removing (only) 85 owners (47 owners after per-file owners are
excluded) because we removed ~500 owners one year ago. I think it's
important to run this cleanup process periodically to keep the codebase
up-dated. Our Chrome infra team is now brainstorming an idea to automate
the process of removing inactive owners.


I'm planning to execute the cleanup next week. If you have any questions,
please let me know. Thanks!



On Sat, Jul 30, 2022 at 3:56 AM Peter Boström  wrote:

> I specifically disagree with the "for this cycle, I'm planning to remove
> the inactive owners unconditionally" bit. If you suggest this removal but
> you defer to local OWNERS to make the call I think that's fine to send out
> removal CLs for. I would encourage you and/or the reviewers to look at the
> removed owner's calendar if they're internal and confirm that they've not
> been on long-term leave.
>
> I don't think that 85/6850 OWNERS entries are a large enough problem to
> bypass local owner approval for this (i.e. land it unconditionally). If
> some of them are owners in very active folders and have had a lot of
> reviews assigned to them, sure. This is about 1% of ownership entries if
> I'm understanding this correctly. How badly are they contributing to review
> latency in order to override "and they are not on a leave during that time"
> as a policy? I like this policy, and it's supposed to still be the policy.
>
> If any of these OWNERS entries had a significant amount of reviews
> assigned to them during this period (i.e. sorta-evidence of latency), you
> could use that as additional justification in the CLs to get the OWNERS to
> approve the (possibly temporary) removal.
>
> For fixing review latency which is the real goal presumably, I think
> handling OOO and load balancing are both more important vectors here. We
> shouldn't need to get inactive owners down to 0 to solve review latency.
>
> On Thu, Jul 28, 2022 at 6:47 PM Kentaro Hara  wrote:
>
>> +1 to improving the tool to handle OOO owners.
>>
>> Let's step back. The problem I'm solving now is: currently OWNERS files
>> contain many long-time inactive, non-OOO owners. The goal is to remove
>> them. Do you agree with the goal?
>>
>> The "long-time inactive" part is covered by looking into their review /
>> commit activities in the past 6 months.
>>
>> The "non-OOO" part is tricky because currently there is no way to get the
>> information from the tool. I'm not sure if giving an o

Re: [blink-dev] Intent to Extend Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Lutz Vahl]

Thanks, sure I'll come back before the M1909 branch cut to present progress
if needed. See you soon :)

On Mon, Aug 1, 2022 at 2:44 PM Yoav Weiss  wrote:

> Given the evidence you presented, which shows significant progress, LGTM
> to experiment until M109 inclusive.
>
> Please come back to this thread (with any future progress) if further
> extensions are needed.
>
> Cheers :)
> Yoav
>
> On Mon, Aug 1, 2022 at 2:17 PM Lutz Vahl  wrote:
>
>> Yes, we've asked in the past already for M113 but it was only approved to
>> M106 (including) until now.
>> Thus I've shared the progress made until now and the outlook.
>>
>> Cheers,
>> Lutz
>>
>> Yoav Weiss  schrieb am Mo., 1. Aug. 2022, 13:57:
>>
>>> If I'm reading the past thread comments correctly, the OT extension was
>>> approved until M106 (inclusive). Is that correct?
>>>
>>> On Thu, Jul 28, 2022 at 5:36 PM Lutz Vahl  wrote:
>>>
 HI all,

 coming back to this thread as discussed a while back.

 Summary

 ‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to
 cross-origin isolated environments, matching the behavior we've recently
 shipped on Android and Firefox. We've performed that change in Chrome 92. A
 reverse OT was started to give developers the option to use SABs in case
 they are not able to adopt cross origin isolation yet.

 Updates

 We’ve received lots of feedback that adopting COOP/COEP is difficult
 (details above). Nevertheless we made substantial progress towards removing
 the usage - Chromestatus is showing that SABs in non-COI context are being
 used on ~0.026%
 
 page loads (down from >2.5%).

 The API owners asked to prove substantial progress to allow an
 extension until M113 (3x MS after shipping the last feature), which
 I’m happy to share:


1.

COEP:credentialless  -
https://crbug.com/1218896

 COEP:credentialless was shipped in M96. (Adoption is already increasing
 to 0.025%
 
 of main pages)


1.

COOP: restrict-properties

 
- launch bug
 -
I2E

 

 Developers who depend on popups to 3P for e.g. identity or payment
 flows can’t currently deploy cross-origin-isolation. To allow
 crossOriginIsolated pages to use popup-based OAuth/payment flows, we plan
 to have a new COOP value: “restrict-properties” that enables
 crossOriginIsolation when used in conjunction with COEP. This new value
 restricts cross-window access to just postMessage and closed instead of
 completely severing popup access.

 Spec work is ongoing (see discussion
 , and previous iteration PR
 ) and requires partners
 input to convince Mozilla that it is the correct solution, ENG work is
 ongoing and we’re targeting M106 for OT and M110 to ship.


1.

Anonymous iframes  and
COEP reflection - launch bug  - I2P

 
- I2E

 

 Anonymous iframes are a generalization of COEP credentialless to
 support 3rd party iframes that may not deploy COEP. Like with COEP
 credentialless, we replace the opt-in of cross-origin subresources by
 avoiding to load non-public resources. This will remove the constraint and
 will unblock developers to adopt cross-origin-isolation as soon as they’re
 embedding 3P iframes.

 Based on the progress made for storage partitioning and CHIPs, which
 are needed to safely ship Anonymous iframes, we’re unblocked to start the
 OT in M106 and the rollout in Q3 2022 (M110).

 The spec:

 https://wicg.github.io/anonymous-iframe/#specification (PRs: 1
 ,2
 ,3
 )




 PLMK if we can extend the OT until M113. Thanks.

 On Wed, May 11, 2022 at 8:08 PM Chris Harrelson 
 wrote:

> Reusing this thread would be totally fine.
>
> On Wed, May 11, 2022, 11:29 AM Lutz Vahl  wrote:
>
>> Great, thanks Chris.
>> I'll report bac

Re: [blink-dev] Intent to Extend Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Yoav Weiss]

Given the evidence you presented, which shows significant progress, LGTM to
experiment until M109 inclusive.

Please come back to this thread (with any future progress) if further
extensions are needed.

Cheers :)
Yoav

On Mon, Aug 1, 2022 at 2:17 PM Lutz Vahl  wrote:

> Yes, we've asked in the past already for M113 but it was only approved to
> M106 (including) until now.
> Thus I've shared the progress made until now and the outlook.
>
> Cheers,
> Lutz
>
> Yoav Weiss  schrieb am Mo., 1. Aug. 2022, 13:57:
>
>> If I'm reading the past thread comments correctly, the OT extension was
>> approved until M106 (inclusive). Is that correct?
>>
>> On Thu, Jul 28, 2022 at 5:36 PM Lutz Vahl  wrote:
>>
>>> HI all,
>>>
>>> coming back to this thread as discussed a while back.
>>>
>>> Summary
>>>
>>> ‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to
>>> cross-origin isolated environments, matching the behavior we've recently
>>> shipped on Android and Firefox. We've performed that change in Chrome 92. A
>>> reverse OT was started to give developers the option to use SABs in case
>>> they are not able to adopt cross origin isolation yet.
>>>
>>> Updates
>>>
>>> We’ve received lots of feedback that adopting COOP/COEP is difficult
>>> (details above). Nevertheless we made substantial progress towards removing
>>> the usage - Chromestatus is showing that SABs in non-COI context are being
>>> used on ~0.026%
>>> 
>>> page loads (down from >2.5%).
>>>
>>> The API owners asked to prove substantial progress to allow an extension
>>> until M113 (3x MS after shipping the last feature), which I’m happy to
>>> share:
>>>
>>>
>>>1.
>>>
>>>COEP:credentialless  -
>>>https://crbug.com/1218896
>>>
>>> COEP:credentialless was shipped in M96. (Adoption is already increasing
>>> to 0.025%
>>> 
>>> of main pages)
>>>
>>>
>>>1.
>>>
>>>COOP: restrict-properties
>>>
>>> 
>>>- launch bug
>>> - I2E
>>>
>>> 
>>>
>>> Developers who depend on popups to 3P for e.g. identity or payment flows
>>> can’t currently deploy cross-origin-isolation. To allow crossOriginIsolated
>>> pages to use popup-based OAuth/payment flows, we plan to have a new COOP
>>> value: “restrict-properties” that enables crossOriginIsolation when used in
>>> conjunction with COEP. This new value restricts cross-window access to just
>>> postMessage and closed instead of completely severing popup access.
>>>
>>> Spec work is ongoing (see discussion
>>> , and previous iteration PR
>>> ) and requires partners input
>>> to convince Mozilla that it is the correct solution, ENG work is ongoing
>>> and we’re targeting M106 for OT and M110 to ship.
>>>
>>>
>>>1.
>>>
>>>Anonymous iframes  and
>>>COEP reflection - launch bug  - I2P
>>>
>>> 
>>>- I2E
>>>
>>> 
>>>
>>> Anonymous iframes are a generalization of COEP credentialless to support
>>> 3rd party iframes that may not deploy COEP. Like with COEP credentialless,
>>> we replace the opt-in of cross-origin subresources by avoiding to load
>>> non-public resources. This will remove the constraint and will unblock
>>> developers to adopt cross-origin-isolation as soon as they’re embedding 3P
>>> iframes.
>>>
>>> Based on the progress made for storage partitioning and CHIPs, which are
>>> needed to safely ship Anonymous iframes, we’re unblocked to start the OT in
>>> M106 and the rollout in Q3 2022 (M110).
>>>
>>> The spec:
>>>
>>> https://wicg.github.io/anonymous-iframe/#specification (PRs: 1
>>> ,2
>>> ,3
>>> )
>>>
>>>
>>>
>>>
>>> PLMK if we can extend the OT until M113. Thanks.
>>>
>>> On Wed, May 11, 2022 at 8:08 PM Chris Harrelson 
>>> wrote:
>>>
 Reusing this thread would be totally fine.

 On Wed, May 11, 2022, 11:29 AM Lutz Vahl  wrote:

> Great, thanks Chris.
> I'll report back in the next months. Shall I use this thread to do so
> or kick off a new one - any preferences?
>
> On Tue, May 10, 2022 at 11:09 PM Chris Harrelson <
> chris...@chromium.org> wrote:
>
>> LGTM to experiment for 3 additional milestones. I think this counts
>> for sure as su

Re: [blink-dev] Intent to Extend Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Lutz Vahl]

Yes, we've asked in the past already for M113 but it was only approved to
M106 (including) until now.
Thus I've shared the progress made until now and the outlook.

Cheers,
Lutz

Yoav Weiss  schrieb am Mo., 1. Aug. 2022, 13:57:

> If I'm reading the past thread comments correctly, the OT extension was
> approved until M106 (inclusive). Is that correct?
>
> On Thu, Jul 28, 2022 at 5:36 PM Lutz Vahl  wrote:
>
>> HI all,
>>
>> coming back to this thread as discussed a while back.
>>
>> Summary
>>
>> ‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to
>> cross-origin isolated environments, matching the behavior we've recently
>> shipped on Android and Firefox. We've performed that change in Chrome 92. A
>> reverse OT was started to give developers the option to use SABs in case
>> they are not able to adopt cross origin isolation yet.
>>
>> Updates
>>
>> We’ve received lots of feedback that adopting COOP/COEP is difficult
>> (details above). Nevertheless we made substantial progress towards removing
>> the usage - Chromestatus is showing that SABs in non-COI context are being
>> used on ~0.026%
>>  page
>> loads (down from >2.5%).
>>
>> The API owners asked to prove substantial progress to allow an extension
>> until M113 (3x MS after shipping the last feature), which I’m happy to
>> share:
>>
>>
>>1.
>>
>>COEP:credentialless  -
>>https://crbug.com/1218896
>>
>> COEP:credentialless was shipped in M96. (Adoption is already increasing
>> to 0.025%
>> 
>> of main pages)
>>
>>
>>1.
>>
>>COOP: restrict-properties
>>
>> 
>>- launch bug
>> - I2E
>>
>> 
>>
>> Developers who depend on popups to 3P for e.g. identity or payment flows
>> can’t currently deploy cross-origin-isolation. To allow crossOriginIsolated
>> pages to use popup-based OAuth/payment flows, we plan to have a new COOP
>> value: “restrict-properties” that enables crossOriginIsolation when used in
>> conjunction with COEP. This new value restricts cross-window access to just
>> postMessage and closed instead of completely severing popup access.
>>
>> Spec work is ongoing (see discussion
>> , and previous iteration PR
>> ) and requires partners input
>> to convince Mozilla that it is the correct solution, ENG work is ongoing
>> and we’re targeting M106 for OT and M110 to ship.
>>
>>
>>1.
>>
>>Anonymous iframes  and COEP
>>reflection - launch bug  - I2P
>>
>> 
>>- I2E
>>
>> 
>>
>> Anonymous iframes are a generalization of COEP credentialless to support
>> 3rd party iframes that may not deploy COEP. Like with COEP credentialless,
>> we replace the opt-in of cross-origin subresources by avoiding to load
>> non-public resources. This will remove the constraint and will unblock
>> developers to adopt cross-origin-isolation as soon as they’re embedding 3P
>> iframes.
>>
>> Based on the progress made for storage partitioning and CHIPs, which are
>> needed to safely ship Anonymous iframes, we’re unblocked to start the OT in
>> M106 and the rollout in Q3 2022 (M110).
>>
>> The spec:
>>
>> https://wicg.github.io/anonymous-iframe/#specification (PRs: 1
>> ,2
>> ,3
>> )
>>
>>
>>
>>
>> PLMK if we can extend the OT until M113. Thanks.
>>
>> On Wed, May 11, 2022 at 8:08 PM Chris Harrelson 
>> wrote:
>>
>>> Reusing this thread would be totally fine.
>>>
>>> On Wed, May 11, 2022, 11:29 AM Lutz Vahl  wrote:
>>>
 Great, thanks Chris.
 I'll report back in the next months. Shall I use this thread to do so
 or kick off a new one - any preferences?

 On Tue, May 10, 2022 at 11:09 PM Chris Harrelson 
 wrote:

> LGTM to experiment for 3 additional milestones. I think this counts
> for sure as substantial progress.
>
> Thank you for all the useful information and your dedication to doing
> right by the web and partner developers!
>
>
> On Fri, May 6, 2022 at 5:58 AM 'Arthur Hemery' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi everyone I just wanted to chime in as the current owner of the COI
>> with popups effort. Spec discussions have been extremely long
>

Re: [blink-dev] Intent to Extend Origin Trial: Trial for SharedArrayBuffers in non-isolated pages on Desktop platforms

[Yoav Weiss]

If I'm reading the past thread comments correctly, the OT extension was
approved until M106 (inclusive). Is that correct?

On Thu, Jul 28, 2022 at 5:36 PM Lutz Vahl  wrote:

> HI all,
>
> coming back to this thread as discussed a while back.
>
> Summary
>
> ‘SharedArrayBuffers’ (SABs) on desktop platforms are restricted to
> cross-origin isolated environments, matching the behavior we've recently
> shipped on Android and Firefox. We've performed that change in Chrome 92. A
> reverse OT was started to give developers the option to use SABs in case
> they are not able to adopt cross origin isolation yet.
>
> Updates
>
> We’ve received lots of feedback that adopting COOP/COEP is difficult
> (details above). Nevertheless we made substantial progress towards removing
> the usage - Chromestatus is showing that SABs in non-COI context are being
> used on ~0.026%
>  page
> loads (down from >2.5%).
>
> The API owners asked to prove substantial progress to allow an extension
> until M113 (3x MS after shipping the last feature), which I’m happy to
> share:
>
>
>1.
>
>COEP:credentialless  -
>https://crbug.com/1218896
>
> COEP:credentialless was shipped in M96. (Adoption is already increasing to
> 0.025%
> 
> of main pages)
>
>
>1.
>
>COOP: restrict-properties
>
> 
>- launch bug
> - I2E
>
> 
>
> Developers who depend on popups to 3P for e.g. identity or payment flows
> can’t currently deploy cross-origin-isolation. To allow crossOriginIsolated
> pages to use popup-based OAuth/payment flows, we plan to have a new COOP
> value: “restrict-properties” that enables crossOriginIsolation when used in
> conjunction with COEP. This new value restricts cross-window access to just
> postMessage and closed instead of completely severing popup access.
>
> Spec work is ongoing (see discussion
> , and previous iteration PR
> ) and requires partners input
> to convince Mozilla that it is the correct solution, ENG work is ongoing
> and we’re targeting M106 for OT and M110 to ship.
>
>
>1.
>
>Anonymous iframes  and COEP
>reflection - launch bug  - I2P
>
> 
>- I2E
>
> 
>
> Anonymous iframes are a generalization of COEP credentialless to support
> 3rd party iframes that may not deploy COEP. Like with COEP credentialless,
> we replace the opt-in of cross-origin subresources by avoiding to load
> non-public resources. This will remove the constraint and will unblock
> developers to adopt cross-origin-isolation as soon as they’re embedding 3P
> iframes.
>
> Based on the progress made for storage partitioning and CHIPs, which are
> needed to safely ship Anonymous iframes, we’re unblocked to start the OT in
> M106 and the rollout in Q3 2022 (M110).
>
> The spec:
>
> https://wicg.github.io/anonymous-iframe/#specification (PRs: 1
> ,2
> ,3
> )
>
>
>
>
> PLMK if we can extend the OT until M113. Thanks.
>
> On Wed, May 11, 2022 at 8:08 PM Chris Harrelson 
> wrote:
>
>> Reusing this thread would be totally fine.
>>
>> On Wed, May 11, 2022, 11:29 AM Lutz Vahl  wrote:
>>
>>> Great, thanks Chris.
>>> I'll report back in the next months. Shall I use this thread to do so or
>>> kick off a new one - any preferences?
>>>
>>> On Tue, May 10, 2022 at 11:09 PM Chris Harrelson 
>>> wrote:
>>>
 LGTM to experiment for 3 additional milestones. I think this counts for
 sure as substantial progress.

 Thank you for all the useful information and your dedication to doing
 right by the web and partner developers!


 On Fri, May 6, 2022 at 5:58 AM 'Arthur Hemery' via blink-dev <
 blink-dev@chromium.org> wrote:

> Hi everyone I just wanted to chime in as the current owner of the COI
> with popups effort. Spec discussions have been extremely long
>  since the topic is
> complex and other vendors don't have the same incentive, since they've
> completely disabled SAB. We're working hard on making this move forward 
> but
> some of it is out of our control. We're doing as much implementation work
> in advance as possible, so that once we 

Re: [blink-dev] A quick survey on setting up fuzzy match rules to identify resolvable flaky web tests

[Stephen Chenney]

Thanks for investigating the potential for fuzzy matching.

Rendering Core continues to oppose a single fuzzy match rule across all
web_tests. We have some tests where single pixel differences matter
(related to pixel snapping, for example) and a universal fuzzy match would
fail to identify problems with those. This came up in practice recently
when the GPU team enabled fuzzy matching without telling us, and expected
failing tests started passing when they shouldn't.

Maybe specific sub teams have directories they could apply default fuzzy
matching to. My guess is that the same directories where it will work will
be directories with few failing tests, limiting the impact of a
per-directory approach.

Is there a way to reproduce the sampling below with a side-by-side
comparison of the images? I would find it helpful to look through some of
the cases that would pass with ,
for example.

Stephen.

On Fri, Jul 29, 2022 at 8:20 PM 'Vivian Zhi (支文文）' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi blink-dev
>
> I would like to let you know that blink-engprod has added feature support
> for non-WPT fuzzy tests. It now allows both non-WPT reftests and pixel
> tests to use the same fuzzy matching meta-tags as WPT tests.It also shows
> max color channel difference and total number of different pixels image
> diff stats in results.html
> .
> With these capabilities in place, we like to research further to see if we
> can set up some general fuzzy match rules, help blink dev identify flaky
> tests that can be potentially resolved by adjusting fuzzy matching rules.
> Currently there are quite some web tests that are flaky due to a slight
> image mismatch, which should have been tolerated. If we setup a general
> fuzzy matching rule , something like:
>
>  
>
> Instruct the image comparison web tests that if color channel and pixel
> diff fall within the range of the rule, we can ignore the diff and pass the
> test.This way we can reduce test flakiness while still maintain test
> accuracy without missing a real bug.
>
> We want to ask you some quick survey questions to help us make design
> decisions, whether it makes sense to set up an universal cross-the-board
> fuzzy match tolerant rule for all blink web tests, or we should make the
> rules more specific to individual test or test sets.
>
> 1.  Is an universal fuzzy match tolerant rule acceptable for the web tests
> in your area?
>
> a). If the answer is yes, what is the acceptable range of max color
> channel and pixel diff for your tests?
> b) If the answer is no, pls share your reasons.
>
> 2. Do you prefer fuzzy matching rule adjustment at a per-test or per test
> set level based on the pixel difference numbers shown in results.html?
>
> Here is some sample data help you make choice, we collected data recently
> from blink_web_tests result on linux-test builder, the distribution of
> color channel maxDifference and totalPixel diff for failing/flaky
> blink_web_tests
> ( Note: over 70% tests in color channel maxDifference 0-10 range have
> maxDifference=1):
>
> Color Channel maxDifferenece
> Range Fail test count
> 0-10 98
> 11-100 31
> 101-200 28
> 201-260 111
> totalPixels
> Diff Range
> Fail test count
> 0-100 30
> 100-1000 57
> 1000-10,000 99
> 10,000-100,000 66
> 100,000-1,000,000 16
>
> Let me know if you have any questions, looking forward to hearing from you!
>
>
> Vivian
> on behalf of Chrome-Blink-EngProd
>
> --
> 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/CAPCqkTs-L5u22-Xp5U_LeBdLP%3D%2BTDH1KGv8MTmtKQFRcANCZJg%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/CAGsbWzRDrX%3Dgz9NNcwpBEOXCxR37p2XwZC3Agm6fdE6%2BFcPhvg%40mail.gmail.com.

[blink-dev] Intent to Extend Experiment: LazyEmbeds

[Minoru Chikamune]

*Contact emails*

chikam...@chromium.org, sisidov...@chromium.org

Explainer:

   -

   https://github.com/nyaxt/lazyembeds


Specification: https://github.com/nyaxt/lazyembeds

Summary: LazyEmbeds aims to improve LCP by delaying the iframe loads
outside the viewport when all of the following conditions are met.


   -

   The loading=eager or loading=lazy attribute values are not specified in
   the iframe tag.


   -

   The iframe's src URL matches a pre-curated list of cross-origin embeds
   (for the sake of quick experimentation).


   -

   The page is visible.
   -

   The iframe's src URL must be cross origin.
   -

   The main frame is not loaded in the following ways. In the following
   operations, the user probably wants to avoid any breakage caused by
   LazyEmbeds.
   -

  The main frame is reloaded.
  -

  The main frame is a result after the user (re)submits a form.


LazyEmbeds has a timeout mechanism that loads all the iframes that are
eligible for LazyEmbeds after a few seconds have elapsed even when the
viewport doesn't come near the iframe. This timeout mechanism is the main
difference between  LazyEmbeds and .

Site authors can specify loading=eager on frames to opt-out of LazyEmbeds.

The current LazyEmbeds implementations target a 1% stable channel for data
gathering purposes. We don't have any plan to release LazyEmbeds in its
current form. This experiment is to help us assess the potential impact, in
order to motivate a proper, launchable, design.

Blink component: Blink>Loader


TAG review

None

TAG review status

Not applicable

RisksInteroperability and Compatibility

The goal of the experiment is to test if the idea actually improves page
load UX. Once that is proven, we would like to start pitching in the
standardization forum on having the new behavior part of the spec.

We have a rough sketch of how it would look like in terms of specification
changes at https://github.com/nyaxt/lazyembeds. LazyEmbeds applies a
different loading schedule to offscreen cross-origin s. Site
authors who believe offscreen content is a critical part of the
user-experience may find this breaks their expectations. To restore the
previous behavior, authors can specify loading=eager on those frames.

Ergonomics

Websites don’t have to do anything.

Activation

LazyEmbeds works without any developer activation.

Security and privacy

LazyEmbeds doesn't have any security and privacy concerns.

Goals for experimentation

We would like to judge if this is a good idea or not before we would like
to validate our hypothesis using the performance data (e.g. Core Web
Vitals) collected through the experiment before we proceed to the next
steps (open-ended discussion with other vendors, involved 3rd-parties).

Reason this experiment is being extended

The previous timeline was to start an experimental 1% stable rollout in
M104. But while running experiments in M104 beta, we have noticed several
problems. So we would like to change the schedule. We want to restart the
experiment in M105 beta and 1% stable rollout in M105.

The following are the notable differences between M104 and M105.

   -

   The main frame is not loaded in the following ways. In the following
   operations, the user probably wants to avoid any breakage caused by
   LazyEmbeds.
   -

  The main frame is reloaded.
  -

  The main frame is a result after the user (re)submits a form.
  -

   Added a timeout mechanism that loads all the iframes that are eligible
   for LazyEmbeds after a few seconds have elapsed even when the viewport
   doesn't come near the iframe. This timeout mechanism is intended to
   minimize the risk of breakage caused by LazyEmbeds.
   -

   Expanded the pre-curated list of cross-origin embeds.


Any risks when the experiment finishes?

No.

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, through the experiment phase, but if the idea proves to be useful
through the experiment and makes it to the spec, we will add WPTs to cover
them.

Tracking bug

https://crbug.com/1247131

Launch bug

https://crbug.com/1247130

Links to previous Intent discussions

N/A

Link to entry on the feature dashboard 

Not yet.

Links to previous Intent discussions

Intent to Experiment


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