Re: [blink-dev] Intent to Remove: window.webkitStorageInfo

[Mike Taylor]

Hi Ayu,

Thanks for digging into usage! I'm encouraged by the fact that browserfs 
(even if not actively maintained) does do internal feature detection 
, 
and supports multiple storage API backends 
 in case a site does run 
into trouble.


LGTM1 to remove window.webkitStorageInfo


On 8/2/22 6:20 PM, Ayu Ishii wrote:

Hi Daniel,

Looking through websites I was able to observe from HTTPArchive, here 
are some usage patterns I was able to see.
Most were used via js libraries listed below. Most usages check if 
window.webkitStorageInfo exists before usage.

Thanks!

window.webkitStorageInfo.requestQuota (163 total urls)

 *

90 urls - browserfs  -
not actively worked on

 *

38 urls - dojo  - old
version / checks if exists first

 *

12 urls - mymonero js
 - old version /
checks if exists first

 *

6 urls - sencha ext js  -
old version?

 *

16 urls remain (8 checks if exists first)


window.webkitStorageInfo.queryUsageAndQuota (285 total urls)

 *

237 urls - twitter share js (example
)
- checks if exists first

 *

38 urls - dojo  - checks if exists first

 *

2 urls - meteor.js  - checks if exists first

 *

8 urls remain (6 checks if exists first)


On Wednesday, July 27, 2022 at 8:19:45 AM UTC-7 Daniel Bratell wrote:

The low usage counters indicate that this is something that could
relatively safely be removed, though I wonder if you have taken a
look at any of the sites listed with the usage counter?

/Daniel

On 2022-07-26 23:26, Ayu Ishii wrote:

*Contact emails
*a...@chromium.org 

*Specification
*https://storage.spec.whatwg.org/ 

*Summary
*We propose to remove the following prefixed quota API,
window.webkitStorageInfo in M106.

 *

window.webkitStorageInfo.queryUsageAndQuota()

 *

window.webkitStorageInfo.requestQuota()

The deprecation thread predates the Intent process, but has been
marked as deprecated since 2013
(https://bugs.webkit.org/show_bug.cgi?id=88396
).

*Blink component
*Blink>Storage>Quota



*Motivation
*Chrome proposed and implemented
 the prefixed quota API in
2011, which was immediately succeeded by the Quota API
 which has
since been deprecated as well. The legacy storage quota API was
never implemented by any other browser, and has been showing a
deprecation warning since 2013. Rather than investing more
support on these legacy APIs, we propose to remove it entirely.

*Search tags
*legacy , quota
, storage


*TAG review
*N/A

*Risks
*We previously made an attempt to remove window.webkitStorageInfo
in 2017 (I2D

).
Since then, the modern quota API navigator.storage.estimate()
shows increased adoption while window.webkitStorageInfo usage has
decreased.

The top level use counter (PrefixedStorageInfo
)
still reports 0.6% of page loads, but we think this can’t be
trusted since enumeration of global properties is common and will
tick the counter. The actual  usage of the methods on
webkitStorageInfo: is significantly lower:

 *

window.webkitStorageInfo.queryUsageAndQuota()

- 0.000632%

 *

window.webkitStorageInfo.requestQuota()

- 0.000172%

As a replacement for
window.webkitStorageInfo.queryUsageAndQuota(), we recommend using
the now standardized navigator.storage.estimate()
.
This has been added to Chrome since M61, and adopted by Firefox
since M57.

window.webkitStorageinfo.requestQuota() will not have a
recommended replacement. Although
navigator.webkitXXXStorage.requestQuota()

Re: [blink-dev] Intent to Remove: window.webkitStorageInfo

[Ayu Ishii]

Hi Daniel,

Looking through websites I was able to observe from HTTPArchive, here are 
some usage patterns I was able to see.
Most were used via js libraries listed below. Most usages check if 
window.webkitStorageInfo exists before usage.
Thanks!

window.webkitStorageInfo.requestQuota (163 total urls)

   - 
   
   90 urls - browserfs  - not 
   actively worked on
   - 
   
   38 urls - dojo  - old version / 
   checks if exists first
   - 
   
   12 urls - mymonero js  - 
   old version / checks if exists first
   - 
   
   6 urls - sencha ext js  - old 
   version?
   - 
   
   16 urls remain (8 checks if exists first)
   

window.webkitStorageInfo.queryUsageAndQuota (285 total urls)

   - 
   
   237 urls - twitter share js (example 
   ) - 
   checks if exists first
   - 
   
   38 urls - dojo - checks if exists first
   - 
   
   2 urls - meteor.js  - checks if exists first
   - 
   
   8 urls remain (6 checks if exists first)
   

On Wednesday, July 27, 2022 at 8:19:45 AM UTC-7 Daniel Bratell wrote:

> The low usage counters indicate that this is something that could 
> relatively safely be removed, though I wonder if you have taken a look at 
> any of the sites listed with the usage counter?
>
> /Daniel
> On 2022-07-26 23:26, Ayu Ishii wrote:
>
>
> *Contact emails *a...@chromium.org 
>
>
> *Specification *https://storage.spec.whatwg.org/
>
>
> *Summary *We propose to remove the following prefixed quota API, 
> window.webkitStorageInfo in M106. 
>
>- 
>
>window.webkitStorageInfo.queryUsageAndQuota()
>- 
>
>window.webkitStorageInfo.requestQuota()
>
> The deprecation thread predates the Intent process, but has been marked as 
> deprecated since 2013 (https://bugs.webkit.org/show_bug.cgi?id=88396).
>
> *Blink component *Blink>Storage>Quota 
> 
>
>
> *Motivation *Chrome proposed and implemented 
>  the prefixed quota API in 2011, 
> which was immediately succeeded by the Quota API 
>  which has since been 
> deprecated as well. The legacy storage quota API was never implemented by 
> any other browser, and has been showing a deprecation warning since 2013. 
> Rather than investing more support on these legacy APIs, we propose to 
> remove it entirely.
>
>
> *Search tags *legacy , 
> quota , storage 
> 
>
>
> *TAG review *N/A
>
>
> *Risks *We previously made an attempt to remove window.webkitStorageInfo 
> in 2017 (I2D 
> ).
>  
> Since then, the modern quota API navigator.storage.estimate() shows 
> increased adoption while window.webkitStorageInfo usage has decreased. 
>
> The top level use counter (PrefixedStorageInfo 
> ) still 
> reports 0.6% of page loads, but we think this can’t be trusted since 
> enumeration of global properties is common and will tick the counter. The 
> actual  usage of the methods on webkitStorageInfo: is significantly lower:
>
>- 
>
>window.webkitStorageInfo.queryUsageAndQuota() 
> - 
>0.000632%
>- 
>
>window.webkitStorageInfo.requestQuota() 
> - 
>0.000172%
>
> As a replacement for window.webkitStorageInfo.queryUsageAndQuota(), we 
> recommend using the now standardized navigator.storage.estimate() 
> . 
> This has been added to Chrome since M61, and adopted by Firefox since M57. 
>
> window.webkitStorageinfo.requestQuota() will not have a recommended 
> replacement. Although navigator.webkitXXXStorage.requestQuota() 
> 
>  
> will still exist, this has never been standardized or adopted by other 
> browsers. Its current usage is at 0.01% 
>  and 
> will need to do some work before full removal, but we are motivated to 
> remove them. Explicitly requesting quota is only used in conjunction with 
> the deprecated and Chrome-only webkitRequestFileSystem() API, which we also 
> hope to remove when feasible.
>
> This removal is part of a lar

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

[Khushal Sagar]

On Mon, Aug 1, 2022 at 12:11 PM Yoav Weiss  wrote:

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

Currently we're recording a UseCounter when any breakage would happen, i.e,
there is any pixel overflow. If it helps to have a UseCounter for overflow
above a threshold, I'm happy to add that too.

We do have an UMA metric which measures the number of overflowing pixels
when there is overflow but it's for all images rendered. I can tie it to
the UseCounter so we can also know the number of affected page loads with
large breakage. I'll wait till the end of the week for more feedback,
otherwise assume 5k is a good threshold for large breakage.


>
>
>>
>>
>>>
>>> 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 <
 khushalsa...@chromium.org> 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.

[blink-dev] Intent to Extend Experiment: User-Agent Reduction Origin Trial

[Mike Taylor]

**

*Hi there,*

*

We would like to extend the User-Agent Reduction OT again, from M104 to 
M106 (inclusive). The original extension expired on July 26th. We’ve 
heard from several partners that they would like to have more time to 
test the fully reduced UA string ahead of Phase 5 and Phase 6 rollouts.



Original I2E

https://groups.google.com/a/chromium.org/g/blink-dev/c/R0xKm1B7qoQ/ 




First 
I2EEhttps://groups.google.com/a/chromium.org/g/blink-dev/c/6x6WH2Odzfo/m/FkDjee5cHQAJ 




Experiment Timeline


M103-M106 inclusive


Reason this experiment is being extended


Like the previous extension, we believe the risks for burn-in don't 
apply, because this OT just enables what we are planning to ship as 
default behavior in the future (and the OT stopped working last week).



We still have not received negative feedback or reports of breaking from 
OT participants, and are encouraged by that fact.



Here’s the relevant info required for OT extensions beyond 6 milestones:


Draft spec:

 *

   https://compat.spec.whatwg.org/#ua-string-chrome
   

 *

   We’ve made solid progress against the open UA string issues, and
   have documented the recent landing of “Phase 4” in Chromium. We plan
   to continue improving things here.

TAG review:

 *

   https://github.com/w3ctag/design-reviews/issues/640
   - closed as
   “Satisfied with concerns”

bit.ly/blink-signals requests

 *

   Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of
   their UA string already.

 *

   WebKit: Shipped/Shipping. Safari has already frozen everything in
   their UA string except for version number info.

 *

   Web developers: Mixed signals. Reactions have ranged from positive
   to indifferent to negative, from various channels.

WPT tests

 *

   None yet, since UAs have flexibility to diverge here. With more
   alignment, this may make sense in the future.


Thanks,Mike

*

--
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/8484ed9c-dc87-5a46-a145-6289921c9b77%40chromium.org.

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

[Mike Taylor]

LGTM to extend to M107.

On 8/2/22 7:58 AM, Johnny Stenback wrote:
Sounds like API Owners are happy with the proposed approach of 
handling these all through the single intent (thanks Yoav, I was 
unaware of your earlier conversation). Given that and as long as all 
the relevant chromestatus entries are kept up to date I'm fine with 
that approach.


Cheers,
Johnny

On Tue, Aug 2, 2022 at 5:34 AM Josh Karlin  wrote:

I can do individual intents if that's necessary. Here are the
affected status entries:

Overall 

Topics 
Attribution Reporting

FLEDGE 
Fenced Frames 
Shared Storage 


On Tue, Aug 2, 2022 at 2:29 AM Yoav Weiss 
wrote:

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 vis

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

[Philip Rogers]

How much of a problem is flakiness caused by minor pixel differences 
compared to overall flakiness? I looked at the top 10 flaky tests here 

 and 
none of them were minor pixel differences.

70 tests is a manageable number and it seems reasonable to add fuzzy 
matching to them.
On Tuesday, August 2, 2022 at 9:04:00 AM UTC-7 Xianzhu Wang wrote:

> On Mon, Aug 1, 2022 at 10:36 AM Vivian Zhi (支文文）  
> wrote:
>
>> Thanks for valuable feedback! Stephen, Xianzhu, will see if we can add a 
>> filter in result.html to grab those tests in range.
>>
>
> The CL  
> adding pixel diff filter in results.html has landed. Thanks Thorben!
>
> In this example results.html 
> ,
>  
> you can examine the pixel results of tests that produced pixel differences 
> matching a particular fuzzy rule in the following steps:
> 1. Enter pixel difference filter e.g. "channel_max:1-1" in the filter 
> input box;
> 2. Click "All" button (as we show regressions only by default).
> You might want to switch to "side-by-side view" and click the image to 
> examine the pixel values.
>
> With "channel_max:1-1" we can see all tests that produced pixel 
> differences that can be tolerated with a fuzzy rule like  content="0-1;0-100">. There are 70 such tests in the example 
> results.html. All of them look benign to me. So perhaps a universal rule 
> (for non wpt tests) is proper?
>
> On the other hand, even if we have such a universal rule, we can only 
> recover 70 tests. Instead of applying the rule automatically, we can also 
> manually modify these tests to include a meta fuzzy rule.
>
>
>> 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. 
>
>

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 10:36 AM Vivian Zhi (支文文）  wrote:

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

The CL 
adding pixel diff filter in results.html has landed. Thanks Thorben!

In this example results.html
,
you can examine the pixel results of tests that produced pixel differences
matching a particular fuzzy rule in the following steps:
1. Enter pixel difference filter e.g. "channel_max:1-1" in the filter input
box;
2. Click "All" button (as we show regressions only by default).
You might want to switch to "side-by-side view" and click the image to
examine the pixel values.

With "channel_max:1-1" we can see all tests that produced pixel differences
that can be tolerated with a fuzzy rule like . There are 70 such tests in the example
results.html. All of them look benign to me. So perhaps a universal rule
(for non wpt tests) is proper?

On the other hand, even if we have such a universal rule, we can only
recover 70 tests. Instead of applying the rule automatically, we can also
manually modify these tests to include a meta fuzzy rule.


> 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

[blink-dev] Intent to Prototype: PaymentHandler - connect-src CSP policy

[Rouslan Solomakhin]

Contact emailssmcgr...@chromium.org, rous...@chromium.org

Specificationhttps://www.w3.org/TR/payment-method-manifest/#processing-model

Summary

Deprecate the ability for PaymentHandler to bypass the connect-src CSP
policy when fetching the manifest. After this deprecation, a site's
connect-src CSP policy will need to allow for the payment method URL
specified in a PaymentRequest call, as well as any other URLs that the
method chains to fetch its manifest.


Blink componentBlink>Payments


Motivation

Content Security Policy (CSP) directives enable a site to detect and
mitigate various forms of attacks including Cross-Site Scripting, data
injection, and data theft. Specifically, the connect-src[0] directive
limits which URLs can be loaded via various script interfaces. Web-based
PaymentHandlers are loaded by specifying a URL to the PaymentRequest API,
which the browser then uses to fetch a manifest file for the
PaymentHandler. This fetching (of various URLs along the way[1]) does not
currently obey connect-src within Chrome and so could be used as a data
exfiltration method. For example, injected script on https://example.org
could specify a (invalid) payment method of
https://attacker.com/exfiltrate?data=foobar, where 'foobar' is some secret
stolen from example.org. To defeat such an attack, we intend to make
PaymentHandler requests fall under the purview of the connect-src CSP
policy. This may require action from both PaymentHandler apps and the sites
(merchants) that use them. The PaymentHandler app will have to determine
all URLs that its app may rely on (e.g., including redirects and the
multiple manifest files) and publish this list somewhere. Sites (merchants)
using PaymentRequest will have to make sure that if they have a connect-src
CSP, it allows for the payment app that they want. [0]:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src
[1]: https://www.w3.org/TR/payment-method-manifest/#fetch-pmm

TAG review statusNot applicable

Risks
Interoperability and Compatibility*Gecko*: N/A Firefox does not currently
implement or ship PaymentHandler.
*WebKit*: N/A Safari does not currently implement or ship PaymentHandler.
*Web developers*: No signals

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?

None: PaymentHanlders are not supported in WebView.

Debuggability

CSP violations print console error messages.

Is this feature fully tested by web-platform-tests

?No

Flag name#payment-handler-csp

Requires code in //chrome?No

Tracking bughttps://crbug.com/1349091

Launch bughttps://crbug.com/1349093

Estimated milestones
DevTrial: 106

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

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

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

[Johnny Stenback]

Sounds like API Owners are happy with the proposed approach of handling
these all through the single intent (thanks Yoav, I was unaware of your
earlier conversation). Given that and as long as all the relevant
chromestatus entries are kept up to date I'm fine with that approach.

Cheers,
Johnny

On Tue, Aug 2, 2022 at 5:34 AM Josh Karlin  wrote:

> I can do individual intents if that's necessary. Here are the affected
> status entries:
>
> Overall 
>
> Topics 
> Attribution Reporting 
> FLEDGE 
> Fenced Frames 
> Shared Storage 
>
>
> On Tue, Aug 2, 2022 at 2:29 AM Yoav Weiss  wrote:
>
>> 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/CACZRgz5BFSGk47KREHMf%2BS0P8Z-bdNiyNbFQSh

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

['Joe Medley' via blink-dev]

Thanks!
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 10:06 PM Minoru Chikamune 
wrote:

> >> 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 <(816)%20678-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 <
 chikam...@chromium.org> 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 experi

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

[Gabriel Charette]

On Mon, Aug 1, 2022 at 11:22 AM 'Christian Dullweber' via Chromium-dev <
chromium-...@chromium.org> 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?
>

We used to have documentation that required that all large-scale changes be
`git cl split` unless 100% mechanical (Owners-Override), I can't find it
anymore (lost in Style Guide / LSC documentation move to .MD?). It sounds
like this isn't 100% mechanical and it thus makes a lot of sense to me that
it'd at least require a local owner's approval.


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

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

[Josh Karlin]

I can do individual intents if that's necessary. Here are the affected
status entries:

Overall 

Topics 
Attribution Reporting 
FLEDGE 
Fenced Frames 
Shared Storage 


On Tue, Aug 2, 2022 at 2:29 AM Yoav Weiss  wrote:

> 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/CAANMuaOpxujkhaxBVm96-GhNL8Jgcp%3D5v6BU-UYG8tmVfuouUw%40mail.gmail.com.