[blink-dev] Re: Intent to Prototype: FileSystemHandle Unique IDs

['Ajay Rahatekar' via blink-dev]

+Ajay Rahatekar

On Tuesday, August 16, 2022 at 11:24:01 AM UTC-7 Austin Sullivan wrote:

> Hi Mike,
>
> Good question!
>
> To explain it a different way... why do we need an isSameEntry() method? 
> Why can't we just compare two FileSystemHandle objects directly?
>
> Well, a handle mostly just represents a path on disk (which we never want 
> to expose to a site). The API has a number of ways (drag & drop, file 
> picker, file handling, re-hydration from IndexedDB) to acquire a handle. 
> Two handles acquired from different contexts (possibly at various times, 
> across browsing sessions) may represent the same path and should be 
> considered equal. Only the browser knows where this file actually lives on 
> disk, so only it can determine equality.
>
> We essentially have the same problem here. We can create a unique ID using 
> crypto.randomUUID(), but if we want it to represent the idea of a path on 
> disk and not just a one-way mapping to an arbitrary FileSystemHandle 
> object, we need the browser's help (or to call isSameEntry() on an 
> unbounded number of handles (yikes)).
>
> To make this a bit more concrete, let's consider an example from the *Storing 
> a representation of a handle in the database of your choice* use case 
> described in the explainer. Say you're a site which allows users to 
> maintain a digital database of their baseball cards 
> . The user selects an image 
> file of the card. You generate an ID using crypto.randomUUID() which 
> represents the file to use as a key in your database alongside all the 
> card's information. You can access the handle using this key with a 
> constant-time lookup in IndexedDB.
>
> A week later, the user logs back on and selects a file from the picker. Is 
> this card already in the database? Your only way to find out is to 
> enumerate all handles you have access to (which could be thousands and 
> thousands of cards) and call isSameEntry() on each of them. The ID you 
> generated is useless until you find the handle in IndexedDB (i.e. handle -> 
> database is potentially a prohibitively expensive operation).
>
> The getUniqueId() method addresses this by answering the "have I seen this 
> handle before" question in constant time.
>
> On Tue, Aug 16, 2022 at 1:07 AM Mike West  wrote:
>
>> Hi! I've skimmed through the explainer, but I feel like I'm missing 
>> something important. Can you help me understand the difference between the 
>> scheme proposed here on the one hand, and relying on something like 
>> Crypto.randomUUID() 
>>  on 
>> the other? I don't understand the requirements that would make the latter 
>> unworkable, but I'd like to before we add another identifier-generator to 
>> the platform. :)
>>
>> Thanks!
>>
>> -mike
>>
>> On Friday, August 12, 2022 at 7:15:58 PM UTC+2 Austin Sullivan wrote:
>>
>>> Contact emailsasu...@chromium.org
>>>
>>> Specificationhttps://github.com/whatwg/fs/pull/46
>>>
>>> Summary
>>>
>>> FileSystemHandle::getUniqueId() generates a uniquely identifying string 
>>> which can be used as a key, such as for IndexedDB or WebLocks. Currently, 
>>> FileSystemHandle objects can be serialized by the browser to be stored as 
>>> values in IndexedDB, but there is no way to generate a string which is 
>>> guaranteed to be uniquely identifying.
>>>
>>>
>>> Developers have complained that building rich experiences on top of the 
>>> File System Access API is challenging due to the inability to uniquely 
>>> identify (and index on) handles. Several partners have requested this.
>>>
>>>
>>> Blink componentBlink>Storage>FileSystem 
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/764
>>>
>>> TAG review statusPending
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Positive (
>>> https://github.com/WICG/file-system-access/issues/295)
>>>
>>> *Other signals*:
>>>
>>> Debuggability
>>>
>>> N/A
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)?This feature will be 
>>> supported on all platforms https://github.com/whatwg/fs/ is shipped 
>>> (currently only desktop platforms)
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?
>>>
>>> The feature will be fully testable with WPT. They'll be written as part 
>>> of the prototype
>>>
>>> Flag nameFileSystemAccessAPIExperimental
>>>
>>> Tracking bughttps://crbug.com/1342961
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5190893263388672
>>>
>>> This intent 

Re: [blink-dev] Intent to Prototype & Ship: Wildcards in Permissions Policy Origins

[Mike Taylor]

We discussed this in the API OWNERS meeting today, and given that the 
TAG review issue was added to the TPAC milestone for next week, we'd 
like to wait a week or so to see if there is any useful feedback.


On 8/31/22 10:44 AM, Ari Chivukula wrote:

I'll add a note, but this is actually deliberate.

*.foo.com  does not match foo.com .

~ Ari Chivukula (Their/There/They're)

On Wed, Aug 31, 2022, 10:19 ayumi hamasaki  wrote:

The example in the description is a bit confusing found here:
https://chromestatus.com/feature/5170361717489664

Before, a permissions policy might need to look like:

```
permissions-policy: ch-ua-platform-version=(self "https://foo.com;
"https://cdn1.foo.com; "https://cdn2.foo.com;)
```

With this feature, it could look like: permissions-policy:

```
ch-ua-platform-version=(self "https://foo.com; "https://*.foo.com
")
```

One would think why not just write: `ch-ua-platform-version=(self
"https://*.foo.com ")` instead. As you're
used `foo.com ` twice!



Would it not be better to use `foo.com ` and
`example.com ` instead e.g.

Before, a permissions policy might need to look like:

```
permissions-policy: ch-ua-platform-version=(self
"https://example.com
" "https://cdn1.foo.com" "https://cdn2.foo.com;)
```

With this feature, it could look like: permissions-policy:

```
ch-ua-platform-version=(self "https://example.com
" "https://*.foo.com ")
```

Which would make more sense.


On Wednesday, 31 August 2022 at 15:10:31 UTC+1 ari...@chromium.org
wrote:

Sorry about that:
https://github.com/mozilla/standards-positions/issues/679
https://github.com/WebKit/standards-positions/issues/51


~ Ari Chivukula (Their/There/They're)

On Wed, Aug 31, 2022, 10:06 Yoav Weiss 
wrote:



On Fri, Aug 26, 2022 at 7:27 PM Ari Chivukula
 wrote:

Contact emails

ari...@chromium.org, mike...@chromium.org


Design Doc


https://docs.google.com/document/d/1HtkQivbjO6TiP6uZdTt4KmTnWzbs5IZpEdrz59-fyYU/edit




Specification

https://github.com/w3c/webappsec-permissions-policy/issues/479



Summary

This feature will add support for wildcard in
permissions policy structured like
SCHEME://*.HOST:PORT (e.g., https://*.foo.com/
) where a valid Origin could be
constructed from SCHEME://HOST:PORT (e.g.,
https://foo.com/). This requires that HOST is at least
eTLD+1 (a registrable domain). This means that
https://*.bar.foo.com/  works but
https://*.com/ won’t (if you want to allow all domains
to use the feature, you should just delegate to *).
Wildcards in the scheme and port section will be
unsupported and https://*.foo.com/ 
does not delegate to https://foo.com/.


Before, a permissions policy might need to look like:

permissions-policy: ch-ua-platform-version=(self
"https://foo.com; "https://cdn1.foo.com;
"https://cdn2.foo.com;)


With this feature, it could look like:

permissions-policy: ch-ua-platform-version=(self
"https://foo.com; "https://*.foo.com ")

Blink component

Blink>PermissionsAPI



Motivation

The Permissions Policy specification
“defines
a mechanism that allows developers to selectively
enable and disable use of various browser features and
APIs.” One capability of this mechanism allows
features to be enabled only on explicitly enumerated
origins (e.g., https://foo.com/). This mechanism is
not flexible enough for the design of some CDNs, which
deliver content via an origin that might be hosted on
one of several hundred possible subdomains.


TAG review

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

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

[Victor Tan]

Thanks all. I just realized there are some date typos for the roll out
plan. Update as follows:

Stage

Time

Date

Stable 1% (M107+)

Canary/Dev/Beta 100%

M107 stable release is shipping to 100% (a best guess)

Nov 1, 2022

Stable 10% (M107/M108/M109)

~10 weeks after previous stage

Jan 9, *2023*

Stable 50%

(M107/M108/M109)

~2 weeks

Jan 23, *2023*

TOT Default (M111)

~2 weeks after previous stage

Feb 7, *2023*

Stable 100% (M107=>M111)

~ Same business day as previous stage

Feb 7, *2023*

Bests,
Victor

On Wed, Sep 7, 2022 at 11:59 AM Yoav Weiss  wrote:

> LGTM3
>
> On Wed, Sep 7, 2022 at 5:51 PM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2022-09-07 17:50, Chris Harrelson wrote:
>>
>> LGTM1. If any issues come up during this rollout that affect the plan,
>> please bring them back to this thread for our consideration.
>>
>> On Thu, Sep 1, 2022 at 11:29 AM Victor Tan 
>> wrote:
>>
>>> Contact emails
>>>
>>> miketa...@chromium.org, victor...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>>
>>> Specification
>>>
>>> https://www.chromium.org/updates/ua-reduction is the closest thing that
>>> specifies Chrome’s UA Reduction plans today. As these changes land in
>>> Chromium and ship to 100% of stable, the Compat Standard
>>>  will be updated in the UA String
>>> section ,
>>> like we did for the Phase 4 changes.
>>>
>>> Summary
>>>
>>> As previously detailed on the Chromium Blog
>>> ,
>>> we intend to proceed with Phase 5 of the User-Agent Reduction plan
>>> .
>>> In Phase 5, the User-Agent string changes the platform and oscpu tokens
>>> from their platform-defined values to the relevant unifiedPlatform
>>>  token
>>> value. The `navigator.platform`, `navigator.platform`, and
>>> `navigator.appVersion` JS APIs will be similarly reduced.
>>>
>>> Blink component
>>>
>>> Blink>Network>ClientHints
>>>
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/640
>>>
>>> TAG review status
>>>
>>> Closed with concerns.
>>>
>>> Risks
>>> Interoperability and Compatibility
>>>
>>> Any time you modify the User-Agent string there is a risk of some
>>> content somewhere depending on the previous format.
>>>
>>> We do not expect interop risks, as each browser sends its own User-Agent
>>> string format. But there is a risk, especially on legacy Windows platforms,
>>> that content somewhere is relying on User-Agents to parse platform and
>>> oscpu information. We believe the risk is somewhat low. But in order to
>>> mitigate the risk of this change, we intend to slowly roll it out via Finch
>>> creating two sub groups: one group enabling the feature for all platforms
>>> except legacy Windows platforms, another group enabling the feature on
>>> legacy Windows platforms and observing health metrics and bug reports. This
>>> gives us the option to roll this back specifically for legacy Windows
>>> clients if needed, but proceed for other platforms.
>>>
>>> Displaying a modern OS version for legacy clients will not create a
>>> problem syntactically on legacy Windows platforms. But the web can get
>>> pretty weird in ways we don't anticipate, hence the slow roll-out and
>>> incremental path towards User-Agent Reduction.
>>>
>>> Here is our proposed rollout plan, with the understanding that if we
>>> discover concerning breakage or regressions via health metrics or bug
>>> reports we will pause the rollout or roll back the feature entirely (and
>>> update this thread if so):
>>>
>>> Stage
>>>
>>> Time
>>>
>>> Date
>>>
>>> Stable 1% (M107+)
>>>
>>> Canary/Dev/Beta 100%
>>>
>>> M107 stable release is shipping to 100% (a best guess)
>>>
>>> Nov 1, 2022
>>>
>>> Stable 10% (M107/M108/M109)
>>>
>>> ~10 weeks after previous stage
>>>
>>> Jan 9, 2022
>>>
>>> Stable 50%
>>>
>>> (M107/M108/M109)
>>>
>>> ~2 weeks
>>>
>>> Jan 23, 2022
>>>
>>> TOT Default (M111)
>>>
>>> ~2 weeks after previous stage
>>>
>>> Feb 7, 2022
>>>
>>> Stable 100% (M107=>M111)
>>>
>>> ~ Same business day as previous stage
>>>
>>> Feb 7, 2022
>>>
>>>
>>> Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their
>>> UA string already.
>>>
>>> WebKit: Shipped/Shipping. Safari has already frozen everything in their
>>> desktop UA string except for Safari and WebKit versions.
>>>
>>> Web developers: Mixed signals. Reactions have ranged from positive to
>>> indifferent to negative, from various channels.
>>>
>>> Debuggability
>>>
>>> No special DevTools support needed.
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> No (Only for desktop platforms: 

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

[Yoav Weiss]

LGTM3

On Wed, Sep 7, 2022 at 5:51 PM Daniel Bratell  wrote:

> LGTM2
>
> /Daniel
> On 2022-09-07 17:50, Chris Harrelson wrote:
>
> LGTM1. If any issues come up during this rollout that affect the plan,
> please bring them back to this thread for our consideration.
>
> On Thu, Sep 1, 2022 at 11:29 AM Victor Tan  wrote:
>
>> Contact emails
>>
>> miketa...@chromium.org, victor...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>>
>> Specification
>>
>> https://www.chromium.org/updates/ua-reduction is the closest thing that
>> specifies Chrome’s UA Reduction plans today. As these changes land in
>> Chromium and ship to 100% of stable, the Compat Standard
>>  will be updated in the UA String
>> section , like
>> we did for the Phase 4 changes.
>>
>> Summary
>>
>> As previously detailed on the Chromium Blog
>> ,
>> we intend to proceed with Phase 5 of the User-Agent Reduction plan
>> .
>> In Phase 5, the User-Agent string changes the platform and oscpu tokens
>> from their platform-defined values to the relevant unifiedPlatform
>>  token
>> value. The `navigator.platform`, `navigator.platform`, and
>> `navigator.appVersion` JS APIs will be similarly reduced.
>>
>> Blink component
>>
>> Blink>Network>ClientHints
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/640
>>
>> TAG review status
>>
>> Closed with concerns.
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Any time you modify the User-Agent string there is a risk of some content
>> somewhere depending on the previous format.
>>
>> We do not expect interop risks, as each browser sends its own User-Agent
>> string format. But there is a risk, especially on legacy Windows platforms,
>> that content somewhere is relying on User-Agents to parse platform and
>> oscpu information. We believe the risk is somewhat low. But in order to
>> mitigate the risk of this change, we intend to slowly roll it out via Finch
>> creating two sub groups: one group enabling the feature for all platforms
>> except legacy Windows platforms, another group enabling the feature on
>> legacy Windows platforms and observing health metrics and bug reports. This
>> gives us the option to roll this back specifically for legacy Windows
>> clients if needed, but proceed for other platforms.
>>
>> Displaying a modern OS version for legacy clients will not create a
>> problem syntactically on legacy Windows platforms. But the web can get
>> pretty weird in ways we don't anticipate, hence the slow roll-out and
>> incremental path towards User-Agent Reduction.
>>
>> Here is our proposed rollout plan, with the understanding that if we
>> discover concerning breakage or regressions via health metrics or bug
>> reports we will pause the rollout or roll back the feature entirely (and
>> update this thread if so):
>>
>> Stage
>>
>> Time
>>
>> Date
>>
>> Stable 1% (M107+)
>>
>> Canary/Dev/Beta 100%
>>
>> M107 stable release is shipping to 100% (a best guess)
>>
>> Nov 1, 2022
>>
>> Stable 10% (M107/M108/M109)
>>
>> ~10 weeks after previous stage
>>
>> Jan 9, 2022
>>
>> Stable 50%
>>
>> (M107/M108/M109)
>>
>> ~2 weeks
>>
>> Jan 23, 2022
>>
>> TOT Default (M111)
>>
>> ~2 weeks after previous stage
>>
>> Feb 7, 2022
>>
>> Stable 100% (M107=>M111)
>>
>> ~ Same business day as previous stage
>>
>> Feb 7, 2022
>>
>>
>> Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their UA
>> string already.
>>
>> WebKit: Shipped/Shipping. Safari has already frozen everything in their
>> desktop UA string except for Safari and WebKit versions.
>>
>> Web developers: Mixed signals. Reactions have ranged from positive to
>> indifferent to negative, from various channels.
>>
>> Debuggability
>>
>> No special DevTools support needed.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> No (Only for desktop platforms: Windows, Mac, Linux, Chrome OS)
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> No
>>
>> Flag name
>>
>> #reduce-user-agent-platform-oscpu
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1339834
>>
>> Launch bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1346071
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5098783126323200
>> --
>> 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
>> 

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

[Daniel Bratell]

LGTM2

/Daniel

On 2022-09-07 17:50, Chris Harrelson wrote:
LGTM1. If any issues come up during this rollout that affect the plan, 
please bring them back to this thread for our consideration.


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


Contact emails

miketa...@chromium.org, victor...@chromium.org


Explainer


https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity




Specification

https://www.chromium.org/updates/ua-reduction
is the closest
thing that specifies Chrome’s UA Reduction plans today. As these
changes land in Chromium and ship to 100% of stable, the Compat
Standard will be updated in the
UA String section
, like
we did for the Phase 4 changes.


Summary

As previously detailed on the Chromium Blog

,
we intend to proceed with Phase 5 of the User-Agent Reduction plan
.
In Phase 5, the User-Agent string changes the platform and oscpu
tokens from their platform-defined values to the relevant
unifiedPlatform
token
value. The `navigator.platform`, `navigator.platform`, and
`navigator.appVersion` JS APIs will be similarly reduced.


Blink component

Blink>Network>ClientHints


TAG review

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



TAG review status

Closed with concerns.


Risks


Interoperability and Compatibility

Any time you modify the User-Agent string there is a risk of some
content somewhere depending on the previous format.


We do not expect interop risks, as each browser sends its own
User-Agent string format. But there is a risk, especially on
legacy Windows platforms, that content somewhere is relying on
User-Agents to parse platform and oscpu information. We believe
the risk is somewhat low. But in order to mitigate the risk of
this change, we intend to slowly roll it out via Finch creating
two sub groups: one group enabling the feature for all platforms
except legacy Windows platforms, another group enabling the
feature on legacy Windows platforms and observing health metrics
and bug reports. This gives us the option to roll this back
specifically for legacy Windows clients if needed, but proceed for
other platforms.


Displaying a modern OS version for legacy clients will not create
a problem syntactically on legacy Windows platforms. But the web
can get pretty weird in ways we don't anticipate, hence the slow
roll-out and incremental path towards User-Agent Reduction.


Here is our proposed rollout plan, with the understanding that if
we discover concerning breakage or regressions via health metrics
or bug reports we will pause the rollout or roll back the feature
entirely (and update this thread if so):


Stage



Time



Date

Stable 1% (M107+)

Canary/Dev/Beta 100%



M107 stable release is shipping to 100% (a best guess)



Nov 1, 2022

Stable 10% (M107/M108/M109)



~10 weeks after previous stage



Jan 9, 2022

Stable 50%

(M107/M108/M109)



~2 weeks



Jan 23, 2022

TOT Default (M111)



~2 weeks after previous stage



Feb 7, 2022

Stable 100% (M107=>M111)



~ Same business day as previous stage



Feb 7, 2022



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

WebKit: Shipped/Shipping. Safari has already frozen everything in
their desktop UA string except for Safari and WebKit versions.

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


Debuggability

No special DevTools support needed.


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

No (Only for desktop platforms: Windows, Mac, Linux, Chrome OS)


Is this feature fully tested by web-platform-tests

?

No


Flag name

#reduce-user-agent-platform-oscpu


Tracking bug

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

[Chris Harrelson]

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

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

> Contact emails
>
> miketa...@chromium.org, victor...@chromium.org
>
> Explainer
>
>
> https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity
>
> Specification
>
> https://www.chromium.org/updates/ua-reduction is the closest thing that
> specifies Chrome’s UA Reduction plans today. As these changes land in
> Chromium and ship to 100% of stable, the Compat Standard
>  will be updated in the UA String section
> , like we did
> for the Phase 4 changes.
>
> Summary
>
> As previously detailed on the Chromium Blog
> ,
> we intend to proceed with Phase 5 of the User-Agent Reduction plan
> .
> In Phase 5, the User-Agent string changes the platform and oscpu tokens
> from their platform-defined values to the relevant unifiedPlatform
>  token
> value. The `navigator.platform`, `navigator.platform`, and
> `navigator.appVersion` JS APIs will be similarly reduced.
>
> Blink component
>
> Blink>Network>ClientHints
>
> TAG review
>
> https://github.com/w3ctag/design-reviews/issues/640
>
> TAG review status
>
> Closed with concerns.
>
> Risks
> Interoperability and Compatibility
>
> Any time you modify the User-Agent string there is a risk of some content
> somewhere depending on the previous format.
>
> We do not expect interop risks, as each browser sends its own User-Agent
> string format. But there is a risk, especially on legacy Windows platforms,
> that content somewhere is relying on User-Agents to parse platform and
> oscpu information. We believe the risk is somewhat low. But in order to
> mitigate the risk of this change, we intend to slowly roll it out via Finch
> creating two sub groups: one group enabling the feature for all platforms
> except legacy Windows platforms, another group enabling the feature on
> legacy Windows platforms and observing health metrics and bug reports. This
> gives us the option to roll this back specifically for legacy Windows
> clients if needed, but proceed for other platforms.
>
> Displaying a modern OS version for legacy clients will not create a
> problem syntactically on legacy Windows platforms. But the web can get
> pretty weird in ways we don't anticipate, hence the slow roll-out and
> incremental path towards User-Agent Reduction.
>
> Here is our proposed rollout plan, with the understanding that if we
> discover concerning breakage or regressions via health metrics or bug
> reports we will pause the rollout or roll back the feature entirely (and
> update this thread if so):
>
> Stage
>
> Time
>
> Date
>
> Stable 1% (M107+)
>
> Canary/Dev/Beta 100%
>
> M107 stable release is shipping to 100% (a best guess)
>
> Nov 1, 2022
>
> Stable 10% (M107/M108/M109)
>
> ~10 weeks after previous stage
>
> Jan 9, 2022
>
> Stable 50%
>
> (M107/M108/M109)
>
> ~2 weeks
>
> Jan 23, 2022
>
> TOT Default (M111)
>
> ~2 weeks after previous stage
>
> Feb 7, 2022
>
> Stable 100% (M107=>M111)
>
> ~ Same business day as previous stage
>
> Feb 7, 2022
>
>
> Gecko: Shipped/Shipping. Firefox has frozen (or capped) much of their UA
> string already.
>
> WebKit: Shipped/Shipping. Safari has already frozen everything in their
> desktop UA string except for Safari and WebKit versions.
>
> Web developers: Mixed signals. Reactions have ranged from positive to
> indifferent to negative, from various channels.
>
> Debuggability
>
> No special DevTools support needed.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> No (Only for desktop platforms: Windows, Mac, Linux, Chrome OS)
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
> Flag name
>
> #reduce-user-agent-platform-oscpu
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1339834
>
> Launch bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1346071
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5098783126323200
>
> --
> 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/CAJh4P7FysJS2D2i4G3YNkf6X8N4_eyUcP%2BpoFrUB_ikdiATwuA%40mail.gmail.com
> 

Re: [blink-dev] Intent to Ship: aria-brailleroledescription and aria-braillelabel

[Daniel Bratell]

LGTM3

/Daniel

On 2022-09-06 20:37, Mike Taylor wrote:

LGTM2

On 9/5/22 5:16 AM, Yoav Weiss wrote:

LGTM1. Thanks for catching us up here!

On Sat, Sep 3, 2022, 08:13 Valerie Young  wrote:

*Contact emails*
alevent...@chromium.org, spectran...@igalia.com

*Explainer*

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-brailleroledescription

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-braillelabel

*Specification*
https://w3c.github.io/aria/#aria-brailleroledescription

*Summary*
Add the aria-brailleroledescription and aria-braillelabel attributes.

These ARIA attributes can be used to override the role
description or accessible name for an element when the output of
a screen reader is directed to a braille device, primarily for
purposes of brevity.

See https://w3c.github.io/aria/#aria-brailleroledescription
and https://w3c.github.io/aria/#aria-braillelabel

*Blink component*
Blink>Accessibility

*TAG review*

*TAG review status*
Not applicable
*
**Risks*
*Interoperability and Compatibility*
There are none.

*Gecko:* Shipped/Shipping And all aria* attributes are exposed by
default in firefox.

*WebKit:* Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=220719)
*
**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?*
No

*Debuggability*
you will see "aria-brailleroledescription" and
"aria-braillelabel" in the dev tools and accessibility tree by
default.

*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?*
Yes, https://github.com/web-platform-tests/wpt/pull/35323

*Flag name*

*Requires code in //chrome?*
False

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

*Estimated milestones*
No milestones specified

*Anticipated spec changes*
Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links to
known github issues in the project for the feature specification)
whose resolution may introduce web compat/interop risk (e.g.,
changing to naming or structure of the API in a
non-backward-compatible way).

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

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/b0364a0d-8acc-7507-d765-8134f5efa50b%40igalia.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/CAL5BFfUFRhwzz32GCjn%3DtoEr0TX8-utmRDVHUyPGtkHTbUFqTw%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/178d519b-0cf0-15ee-21cc-10053819a9cd%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/653840ac-9f25-d3de-3e11-8a4f723360f8%40gmail.com.

Re: [blink-dev] Intent to Experiment: Declarative Beacon API

['Ming-Ying Chung' via blink-dev]

Hi Ian & Yoav,

We might have to delay the OT to M107-M109 as we still have several issues
to solve. Could it be updated?

On Tue, Sep 6, 2022 at 2:18 PM Yoav Weiss  wrote:

> LGTM to experiment M106-108 inclusive
>
> On Tue, Sep 6, 2022, 04:02 'Ming-Ying Chung' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi Ian,
>>
>> There is no concern from the dev team. We can try to run the OT from M106
>> to M108 if possible.
>>
>> On Sat, Sep 3, 2022 at 5:40 AM Ian Clelland 
>> wrote:
>>
>>>
>>> On Wed, Aug 31, 2022 at 3:04 AM Ming-Ying Chung 
>>> wrote:
>>>
 Hi all,

 Reviving this thread as we plan to conduct an Origin Trial for this
 feature in M106, with the following updates. Please take a look.

>>>
>>> Is it possible to extend this trial for a few releases? Most trials run
>>> for ~3 releases initially, and I think that would be useful here. I know of
>>> a number of external partners, eager to test the API, who might need more
>>> than a single release to be able to deploy this and get back sufficient
>>> data for constructive feedback.
>>>
>>>
>>>
>>>

 Explainer

 https://github.com/WICG/unload-beacon/blob/main/README.md

 Specification

 https://wicg.github.io/unload-beacon/ (In draft state)




 On Tue, Jun 28, 2022 at 11:23 PM Joe Medley  wrote:

> Daisuke,
>
> That makes it either a dev trial or an origin trial. Since you've
> recorded a value for origin_trial_feature_name
> in runtime_enabled_features.json5 that makes it an origin trial. I assume
> that's starting in 105?
>
> Joe
> 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, Jun 27, 2022 at 7:14 PM Daisuke Enomoto 
> wrote:
>
>> Joe, the API is behind the flag "PendingBeaconAPI".
>>
>> Mike, we came to discuss the new ideas of API design after we sent
>> this I2E. We will update the I2E thread when we have clarity on the 
>> design
>> discussion and the timeline when an experiment can start.
>>
>> Caleb, thank you for filing an issue.
>>
>> On Tue, Jun 28, 2022 at 3:09 AM Caleb Raitto 
>> wrote:
>>
>>> Hi, I filed https://github.com/darrenw/docs/issues/3 about a time
>>> limit on the duration from bfcache page freeze to beacons being sent --
>>> could you PTAL?
>>>
>>> Thanks,
>>> -Caleb
>>>
>>> On Friday, June 24, 2022 at 9:36:15 AM UTC-4 mike...@chromium.org
>>> wrote:
>>>
 Thanks - sounds good.

 Could you clarify the desired experiment timeline? Is it just for
 M104, or something else?

 On 6/20/22 12:31 AM, Fergal Daly wrote:

 Sorry, there were some details left out of this I2E. We actually
 have a lot of signals from web devs on this. There are some comments on


 https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776

 but we also presented this to W3C WebPerf with a lot of positive
 signals. Minutes are here
 
  from
 the most recent one.

 We don't have any reaction from Mozilla or WebKit that I know of
 and we will file a TAG request shortly,

 F

 On Sat, 18 Jun 2022 at 02:57, Mike Taylor 
 wrote:

> On 6/17/22 10:59 AM, Ming-Ying Chung wrote:
>
> Contact emails
>
> my...@chromium.org, fer...@chromium.org, deno...@chromium.org
>
> Explainer
>
> https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md
>
> Specification
>
> https://clelland.github.io/page-unload-beacon/spec.html (In draft
> state)
>
> Summary
>
> A stateful API for beacons that has the browser control the time
> beacons are sent.
>
> Existing beacon APIs are all based around a developer constructing
> and sending a beacon, and there's no good time for that "send" call 
> to be
> made. (Handlers such as 'unload' are often ignored, for example.) 
> This API
> delegates the sending to the browser itself, so it can support 
> beacons on
> page unload or on page hide, without the developer having to 
> implement send
> calls at exactly the right times.
>
>
> Blink component
>
> Blink>Network
> 
>
> TAG review
>
> None yet.
>
> I'd recommend filing a TAG review as well as asking for signals

[blink-dev] Re: Intent to Ship: Variable COLRv1

[Yoav Weiss]

Hey Dominik!

So once this ships, if developers would want to ship something that works 
on both latest Chrome and older Chrome versions, do they have a way to do 
that? Would they do that using `tech(colrv1 variations)` or somesuch? 

On Monday, September 5, 2022 at 4:36:01 PM UTC+2 Dominik Röttsches wrote:

> Contact emailsdr...@chromium.org
>
> Explainer
> https://github.com/googlefonts/colr-gradients-spec/blob/main/OFF_AMD2_WD.md#changes-to-off-5711---color-table
>
> Specification
> https://docs.microsoft.com/en-us/typography/opentype/otspec191alpha/colr
>
> Summary
>
> COLRv1 color vector fonts have been previously released in Chrome 98 
> https://developer.chrome.com/blog/colrv1-fonts/ but this release 
> supported only static functionality of the COLRv1 table. (Previous I2S 
> 
> ).
>
>
> The COLRv1 specification defined integration with OpenType Variations 
> 
>  
> from the beginning. This allows modifying the color elements of a font, 
> parameters of gradients and transforms by means of changing font variable 
> axis parameters. This I2S here is for bringing implementation support and 
> adding variations to COLRv1 in Blink (see demo video 
> , or demo links below)
>
> Blink componentBlink>Fonts 
> 
>
> Search tagscolrv1 , 
> variations , variable 
> fonts , color 
> , emoji 
> , gradients 
> 
>
> TAG reviewThe COLRv1 specification is developed outside of W3C, slated 
> for inclusion in OpenType and ISO/MPEG Open Font Format. Before the previous 
> I2S 
> ,
>  
> I started a thread on blink-api-owners-discuss asking whether TAG review 
> for such a font format would be needed. This discussion concluded that a 
> TAG review is not required (thread 
> 
> ).
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> I see an interoperability risk mainly by not shipping variable COLRv1 
> support. Here's why:
>
>
> Firefox is already in the process of shipping COLRv1 support (#1740530) 
> , and their initial 
> release will immediately include COLRv1 variations support. 
>
>
> In the past few weeks, I've worked closely with Jonathan Kew from the 
> Mozilla side to ensure interoperability of the resulting variable COLRv1 
> glyph renderings. To that end, I developed an extensive variable COLRv1 
> test font, for which we have compared results. 
> https://github.com/googlefonts/color-fonts/blob/main/fonts/test_glyphs-glyf_colr_1_variable.ttf
>  
> Additional interoperability efforts are underways: I would like to get to a 
> point where we can have at least pixel comparisons of text stack rendering 
> results for COLRv1. This is below the level of testing that WPT covers and 
> likely needs separate infrastructure. For now, rendering results based on 
> the test font have been manually compared. 
>
> *Gecko*: In development (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1740530) The standards 
> position was already "worth implementing" and no a fast-paced effort to 
> deliver COLRv1 including variations support to users is driven by Jonathan 
> Kew. The high quality implementation can already be tested in FF Nightly.
>
> *WebKit*: Neutral (
> https://groups.google.com/a/chromium.org/g/blink-dev/c/kDfj3rcA6sc/m/77Ary8NVBwAJ)
>  
> See discussion in previous COLRv1 intent-to-ship. Since then, I would 
> estimate their stance towards COLRv1 has changed from negative to 
> "observing".
>
> *Web developers*: Positive Google Fonts, Underware.nl and other type 
> foundry partners are anticipating this feature.
>
> *Other signals*:
>
> Activation
>
> Similar to the initial release of COLRv1, the issue of feature detection 
> remains. See separate I2S for tech() in src: line of @font-face. This, plus 
> @supports(font-tech()) are intended to solve that. 
>
>
> Security
>
> In addition to the initial COLRv1 release, which already had fuzzing for 
> the FreeType parts, a fuzzer that fuzzes the Skia level code has been 
> introduced  and 
> a few smaller issues that this fuzzer found have been addressed. 
>
>

Re: [blink-dev] Intent to Experiment: Declarative Beacon API

[Yoav Weiss]

Sure, LGTM still stands.

On Wed, Sep 7, 2022 at 10:48 AM Ming-Ying Chung  wrote:

> Hi Ian & Yoav,
>
> We might have to delay the OT to M107-M109 as we still have several issues
> to solve. Could it be updated?
>
> On Tue, Sep 6, 2022 at 2:18 PM Yoav Weiss  wrote:
>
>> LGTM to experiment M106-108 inclusive
>>
>> On Tue, Sep 6, 2022, 04:02 'Ming-Ying Chung' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Hi Ian,
>>>
>>> There is no concern from the dev team. We can try to run the OT from
>>> M106 to M108 if possible.
>>>
>>> On Sat, Sep 3, 2022 at 5:40 AM Ian Clelland 
>>> wrote:
>>>

 On Wed, Aug 31, 2022 at 3:04 AM Ming-Ying Chung 
 wrote:

> Hi all,
>
> Reviving this thread as we plan to conduct an Origin Trial for this
> feature in M106, with the following updates. Please take a look.
>

 Is it possible to extend this trial for a few releases? Most trials run
 for ~3 releases initially, and I think that would be useful here. I know of
 a number of external partners, eager to test the API, who might need more
 than a single release to be able to deploy this and get back sufficient
 data for constructive feedback.




>
> Explainer
>
> https://github.com/WICG/unload-beacon/blob/main/README.md
>
> Specification
>
> https://wicg.github.io/unload-beacon/ (In draft state)
>
>
>
>
> On Tue, Jun 28, 2022 at 11:23 PM Joe Medley 
> wrote:
>
>> Daisuke,
>>
>> That makes it either a dev trial or an origin trial. Since you've
>> recorded a value for origin_trial_feature_name
>> in runtime_enabled_features.json5 that makes it an origin trial. I assume
>> that's starting in 105?
>>
>> Joe
>> 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, Jun 27, 2022 at 7:14 PM Daisuke Enomoto <
>> denom...@chromium.org> wrote:
>>
>>> Joe, the API is behind the flag "PendingBeaconAPI".
>>>
>>> Mike, we came to discuss the new ideas of API design after we sent
>>> this I2E. We will update the I2E thread when we have clarity on the 
>>> design
>>> discussion and the timeline when an experiment can start.
>>>
>>> Caleb, thank you for filing an issue.
>>>
>>> On Tue, Jun 28, 2022 at 3:09 AM Caleb Raitto 
>>> wrote:
>>>
 Hi, I filed https://github.com/darrenw/docs/issues/3 about a time
 limit on the duration from bfcache page freeze to beacons being sent --
 could you PTAL?

 Thanks,
 -Caleb

 On Friday, June 24, 2022 at 9:36:15 AM UTC-4 mike...@chromium.org
 wrote:

> Thanks - sounds good.
>
> Could you clarify the desired experiment timeline? Is it just for
> M104, or something else?
>
> On 6/20/22 12:31 AM, Fergal Daly wrote:
>
> Sorry, there were some details left out of this I2E. We actually
> have a lot of signals from web devs on this. There are some comments 
> on
>
>
> https://discourse.wicg.io/t/proposal-stateful-javascript-page-unload-beacon-api/5776
>
> but we also presented this to W3C WebPerf with a lot of positive
> signals. Minutes are here
> 
>  from
> the most recent one.
>
> We don't have any reaction from Mozilla or WebKit that I know of
> and we will file a TAG request shortly,
>
> F
>
> On Sat, 18 Jun 2022 at 02:57, Mike Taylor 
> wrote:
>
>> On 6/17/22 10:59 AM, Ming-Ying Chung wrote:
>>
>> Contact emails
>>
>> my...@chromium.org, fer...@chromium.org, deno...@chromium.org
>>
>> Explainer
>>
>> https://github.com/darrenw/docs/blob/main/explainers/beacon_api.md
>>
>> Specification
>>
>> https://clelland.github.io/page-unload-beacon/spec.html (In
>> draft state)
>>
>> Summary
>>
>> A stateful API for beacons that has the browser control the time
>> beacons are sent.
>>
>> Existing beacon APIs are all based around a developer
>> constructing and sending a beacon, and there's no good time for that 
>> "send"
>> call to be made. (Handlers such as 'unload' are often ignored, for
>> example.) This API delegates the sending to the browser itself, so 
>> it can
>> support beacons on page unload or on page hide, without the developer
>> having to implement send calls at exactly the right times.
>>
>>
>> Blink component
>>