Re: [blink-dev] Intent to Ship: Back/forward cache NotRestoredReasons API

['Yuzu Saijo' via blink-dev]

Sorry for the delayed response.

*> there doesn't appear to be any NotRestoredReasons interface defined in 
Chromium?*
Let me address this implementation and delay the shipping until the 
chromium implementation matches the proposed spec. Thanks for pointing it 
out!
Same for WPT. I will add tests for all the standardized reasons.

*> Can you confirm that you're only shipping the specified four?*
We do have ~50 not restored reasons, and in theory we will be able to 
remove most of them except for the standardized four reasons. 
However, in reality it will take time for us to support all the reasons and 
we need to keep blocking on them for a while.
In the meantime, our plan was to expose the non-standardized reasons too, 
but in a way that's distinguishable from standardized reasons as you 
suggested here 
.
I realized that we need to add browser specific reasons to the spec as 
well. Let me add that and send a review request again.

Thanks!
Yuzu
On Thursday, July 13, 2023 at 12:07:05 PM UTC+9 dom...@chromium.org wrote:

> Also, checking the tests, it seems like the currently-implemented reasons 
> don't match the spec. E.g. this test 
> 
>  requires 
> the reason to be "WebSocket", but the specification says "websocket" 
> (lowercase). I couldn't find tests for the other three reasons...
>
> On Thu, Jul 13, 2023 at 12:04 PM Domenic Denicola  
> wrote:
>
>> I have some questions about how well the implementation here matches up 
>> with the spec.
>>
>> First, there doesn't appear to be any NotRestoredReasons interface 
>> defined in Chromium? The relevant attribute on 
>> PerformanceNavigationTiming returns object? 
>> .
>>  
>> That seems like a problematic mismatch...
>>
>> Second, I can't find exactly where the list of script-exposed not 
>> restored reasons are. But, I'll note that Chromium seems to have ~50 
>> such reasons 
>> ,
>>  
>> whereas you've only specified 4 (fetch, navigation-failure, parser-aborted, 
>> websocket). Can you confirm that you're only shipping the specified four?
>>
>> Thanks!
>>
>> On Thu, Jul 13, 2023 at 12:11 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Thu, Jul 6, 2023 at 7:28 AM 'Yuzu Saijo' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emails

 yu...@google.com, yu...@chromium.org, fer...@chromium.org

 Explainer


 https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md

 Specification

 https://github.com/whatwg/html/pull/9360

 Design docs


 https://github.com/WICG/bfcache-not-restored-reason/blob/main/NotRestoredReason.md

 Summary

 NotRestoredReason API will report the list of reasons why a page is not 
 served from BFcache in a frame tree structure, via 
 PerformanceNavigationTiming API.


 Blink component

 UI>Browser>Navigation>BFCache 
 

 TAG review

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

 TAG review status

 Issues addressed

 Risks

 Interoperability and Compatibility

 Gecko: Defer (https://github.com/mozilla/standards-positions/issues/766) 
 Once issues (standardized reasons & unsalvageable documents), they would 
 switch to positive.

>>>
>>> It seems like the "standardized reasons" part is addressed in your PR. 
>>> Is the same true for the second point?
>>>  
>>>

 WebKit: No signal (
 https://github.com/WebKit/standards-positions/issues/154)

 Web developers: Positive (
 https://github.com/w3c/navigation-timing/issues/171#issuecomment-1062672989
 )

 Other signals: Positive from Origin Trial users:

 How likely are you to keep using this feature?

 92% answered likely, 8% (1 vote) is unsure

 Security

 We do not report detailed information about cross-origin iframes. See 
 Security 
 and Privacy section 
 
  
 in the explainer.


 WebView application risks

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

Re: [blink-dev] Intent to Ship: Remove quirks mode behavior for option label attribute

[Joey Arhar]

I looked at the top 20 websites here:
https://chromestatus.com/metrics/feature/timeline/popularity/4454
I looked at the option elements which were triggering the UseCounter, and I
found that all of them seemed to have a label attribute with no text
content at some point during page load, but then when I actually looked at
them in DevTools after page load they all had text content.
None of those top 20 websites are affected by this change.

On Wed, Apr 26, 2023 at 9:22 AM Rick Byers  wrote:

> Hey Joey,
> We discussed this in the API owners meeting today. Given that Firefox has
> succeeded in removing this quirk, we do think it's valuable for us to
> attempt to follow. Thank you again for pushing on it. Could you take a look
> at either 20 hits from HA, or 10 high-ranking hits
> *
>  and
> see if you see any actual breakage? API owners agreed today that if you
> didn't (or if you saw just 1 in 20), we'd be OK proceeding with a
> killswitch we can pull if necessary.
>
> *Note chrishtr@ is looking into making ranking-based HA analysis easier
> than getting BigQuery setup.
>
> Thanks,
>Rick
>
> On Wed, Apr 19, 2023 at 11:06 AM Rick Byers  wrote:
>
>> Hey Joey, sorry for the delay. Yeah 0.01% puts this into the high risk
>> range unfortunately. If you want to proceed, the next step would probably
>> be to get a random sample of impacted URLs and evaluate the severity of
>> breakage
>> 
>> and ease of adaptation
>> .
>> Maybe we'd find they are almost all pages with very subtle layout changes
>> which already look OK or just slightly off in Firefox. The real risk likely
>> comes from sites / apps designed for blink/webkit only (enterprise, android
>> webview, etc.). But if you could show evidence that < 1 in 20 impacted page
>> loads have any meaningful breakage (i.e. <0.005% page views impacted), then
>> we might still be able to proceed with appropriate webview and enterprise
>> guards. But that obviously has a cost, so up to you if it's better to just
>> specify the current quirky behavior. Maybe our efforts are better spent
>> trying to actively drive down quirks mode usage somehow?
>>
>> Thanks for trying to clean this sort of thing up!
>>   Rick
>>
>> On Wed, Apr 12, 2023 at 5:34 PM Joey Arhar  wrote:
>>
>>> Here is the UseCounter:
>>> https://chromestatus.com/metrics/feature/timeline/popularity/4454
>>> It looks like it is at 0.0103%
>>> What do yall think?
>>>
>>> > Personally I would be happy to approve if we had a UseCounter with
>>> less than our small but non-trivial risk threshold of 0.001% of page loads
>>>
>>> Looks like its higher than this threshold :(
>>>
>>> On Wed, Apr 12, 2023 at 3:53 AM Yoav Weiss 
>>> wrote:
>>>
 Friendly ping! :)

 On Wednesday, March 15, 2023 at 7:13:25 PM UTC+1 Joey Arhar wrote:

> Yes, that matches my understanding. I can see on omahaproxy that the
> usecounter was merged in 112 and I can see on chromiumdash that 112 goes 
> to
> stable on april 4
>
> On Wed, Mar 15, 2023 at 11:11 AM Yoav Weiss 
> wrote:
>
>> Looked at this following the API owners meeting and given that the
>> usecounters
>>  
>> landed
>> in 112, I think we can expect stable data early April but not before.
>>
>> Joey - does that match your understanding?
>>
>> On Sat, Jan 28, 2023 at 1:04 AM Rick Byers 
>> wrote:
>>
>>> On Thu, Jan 26, 2023 at 5:07 PM Simon Pieters 
>>> wrote:
>>>
 Hi folks!

 Thanks for working on this, Joey. Removing quirks where possible is
 always nice!

 On Wed, Jan 25, 2023 at 7:18 PM Joey Arhar 
 wrote:

> Sounds good, I'm adding a UseCounter here:
> https://chromium-review.googlesource.com/c/chromium/src/+/4193560
>
> On Tue, Jan 24, 2023 at 8:05 AM Rick Byers 
> wrote:
>
>> Hey Joey,
>> Thanks for working to remove a quirk! Although we haven't written
>> it into our compat principles , I'm
>> personally willing to accept greater compat risk for removing quirks 
>> as
>> they're by-definition legacy behavior of the web which create an 
>> ongoing
>> complexity burden for the platform which we should seek to eventually
>> eliminate.
>>
>> Reading through the history
>> 
>> of WebKit not being able to make this change due to severe breakage 
>> in
>> bugzilla and

Re: [blink-dev] Intent to Ship: Storage Access API with Prompts

[Mike Taylor]

On 8/2/23 4:47 PM, Chris Fredrickson wrote:

Contact emails

cfred...@chromium.org, johann...@chromium.org, shuu...@chromium.org


Explainer

https://github.com/privacycg/storage-access/blob/main/README.md 



https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md 




Specification

https://privacycg.github.io/storage-access 




Summary

The Storage Access API provides a means for authenticated cross-site 
embeds to check whether access to unpartitioned cookies is blocked and 
request access if it is blocked. This request may be surfaced to the 
user as a prompt, or auto-granted/auto-denied. Chrome will support the 
Storage Access API by implementing all the behaviors listed in the 
specification, i.e. with user prompts, and additionally having its own 
user-agent-specific behaviors. Chrome’s implementation is available 
for testing 
starting 
in Chrome 117.



The Storage Access API is related to other cookie-focused projects 
like CHIPS 
and 
First-Party Sets as 
preparation for phasing out third-party cookies 
in 
Chrome.



Note that Edge previously sent an I2I 
for 
the Storage Access API feature (with their own user-agent-specific 
behavior), and Chrome has previously sent an I2S 
for 
support for the Storage Access API gated on First-Party Sets 
membership (without user prompts). This I2S is intended for support 
for the API across sites that are not within the same First-Party Set.



Blink component

Blink>StorageAccessAPI 




TAG review

https://github.com/w3ctag/design-reviews/issues/807 
(review of 
overall API, not of prompts)



TAG review status

Positive 




Risks

Interoperability and Compatibility

There is minor compatibility risk as Firefox and Safari already differ 
slightly in their user-agent-specific prompt requirements. Chrome's 
planned behavior 
is closest to 
Safari's current behavior, and we aim to standardize as much of this 
user-agent-specific behavior as possible over time.


Could you elaborate on the differences for prompt requirements, and how 
that might lead to compat issues?



Gecko: Shipping


WebKit: Shipping


Web developers: There has been great developer interest in the Storage 
Access API, given that it provides the only predictable way of working 
with cross-site cookies in many browsers. Various developers have 
chimed in onhttps://github.com/whatwg/html/issues/3338 
and filed issues 
onhttps://github.com/privacycg/storage-access 
.



Other signals: Edge has shipped Blink's previous implementations of 
this API, which differ from Chrome's plans. We have kept (and intend 
to continue keeping) Edge engineers in the loop about these changes 
and there will be feature flags to control Blink's behavior.



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

None


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


No. It will be supported on all Blink platforms except Android WebView 
initially. We may add WebView support in the future.



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



No. Browser UI is not testable by WPTs, since that is UA-specific. 
(The Storage Access API spec itself is tested by WPTs 
.)



Flag name on chrome://flags

#storage-access-api, #permission-storage-access-api


Finch feature name

StorageAccessAPI, PermissionStorageAccessAPI


Non-finch justification

None


Requires code in //chrome?

True


Estimated milestones
    Shipping on desktop: 117
    Shipping on Android: 120

Anticipated spec changes

Some minor changes are expected in order to properly take user 
settings into account: 
https://github.com/privacycg/storage-access/pull/174 
and an 

[blink-dev] Intent to Ship: Storage Access API with Prompts

[Chris Fredrickson]

Contact emails

cfred...@chromium.org, johann...@chromium.org, shuu...@chromium.org

Explainer

https://github.com/privacycg/storage-access/blob/main/README.md

https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md

Specification

https://privacycg.github.io/storage-access

Summary

The Storage Access API provides a means for authenticated cross-site embeds 
to check whether access to unpartitioned cookies is blocked and request 
access if it is blocked. This request may be surfaced to the user as a 
prompt, or auto-granted/auto-denied. Chrome will support the Storage Access 
API by implementing all the behaviors listed in the specification, i.e. 
with user prompts, and additionally having its own user-agent-specific 
behaviors. Chrome’s implementation is available for testing 
 
starting in Chrome 117.

The Storage Access API is related to other cookie-focused projects like 
CHIPS  and 
First-Party 
Sets  as preparation for phasing 
out third-party cookies 

 
in Chrome.

Note that Edge previously sent an I2I 

 
for the Storage Access API feature (with their own user-agent-specific 
behavior), and Chrome has previously sent an I2S 

 
for support for the Storage Access API gated on First-Party Sets membership 
(without user prompts). This I2S is intended for support for the API across 
sites that are not within the same First-Party Set.

Blink component

Blink>StorageAccessAPI 


TAG review

https://github.com/w3ctag/design-reviews/issues/807 (review of overall API, 
not of prompts)

TAG review status

Positive 


Risks

Interoperability and Compatibility

There is minor compatibility risk as Firefox and Safari already differ 
slightly in their user-agent-specific prompt requirements. Chrome's planned 
behavior  is closest 
to Safari's current behavior, and we aim to standardize as much of this 
user-agent-specific behavior as possible over time.


Gecko: Shipping

WebKit: Shipping

Web developers: There has been great developer interest in the Storage 
Access API, given that it provides the only predictable way of working with 
cross-site cookies in many browsers. Various developers have chimed in on 
https://github.com/whatwg/html/issues/3338 and filed issues on 
https://github.com/privacycg/storage-access.

Other signals: Edge has shipped Blink's previous implementations of this 
API, which differ from Chrome's plans. We have kept (and intend to continue 
keeping) Edge engineers in the loop about these changes and there will be 
feature flags to control Blink's behavior.

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

None

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

No. It will be supported on all Blink platforms except Android WebView 
initially. We may add WebView support in the future.

Is this feature fully tested by web-platform-tests 

?

No. Browser UI is not testable by WPTs, since that is UA-specific. (The 
Storage Access API spec itself is tested by WPTs 
.)

Flag name on chrome://flags

#storage-access-api, #permission-storage-access-api

Finch feature name

StorageAccessAPI, PermissionStorageAccessAPI

Non-finch justification

None

Requires code in //chrome?

True

Estimated milestones
Shipping on desktop: 117
Shipping on Android: 120

Anticipated spec changes

Some minor changes are expected in order to properly take user settings 
into account: https://github.com/privacycg/storage-access/pull/174 and an 
analogous change for document.requestStorageAccess.

There is ongoing discussion 
 on how to offer 
access to unpartitioned DOM storage via this API.

The spec has been in incubation being co-developed by all three browser 
engines for a while and is close to graduation as tracked here: 
https://github.com/whatwg/html/issues/9000.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5085655327047680

Links to previous Intent discussions

Intent to prototype: Intent to Prototype: Storage Ac

[blink-dev] Re: Intent to Prototype & Ship: Cookie Expires/Max-Age attribute upper limit for prior storage

[Ari Chivukula]

According to measurements in Chrome, of all cookies set, about 20% request
an Expires/Max-Age further than 400 days in the future. Of that 20%: half
target 2 years, a quarter target 10 years or more, and the remainder are
spread over the rest of the range.

Keep in mind this is looking at the usage of sites *before* any cap was
imposed. Although the distribution of cookies with expirations more than
400 days in the future will be the same, the amount will be under 20% of
current storage and shrinking as any cookies added or updated will now be
forced to respect the 400 day cap.

The motivation for this change is to require, now that we're about to hit
400 days since the cap was imposed on new/updated cookies, that no special
privileges be extended to cookies that just happened to have been stored
before.

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


On Wed, Aug 2, 2023 at 3:47 PM Alex Russell 
wrote:

> Hey Ari,
>
> It isn't clear to me that the change in the RFC is a motivator to make
> this change, or that it reduces potential risk.
>
> There are details here will matter a lot to the risk profile. IIRC, we'll
> be going first with regards to the lifetime of first-party, server-set
> cookies? Do we have an analysis of what fraction of cookies will be
> impacted?
>
> Thanks,
>
> Alex
>
> On Tuesday, August 1, 2023 at 8:59:59 AM UTC-7 Ari Chivukula wrote:
>
>> Contact emails
>>
>> aric...@chromium.org, miketa...@chromium.org, bing...@chromium.org
>>
>> Specification
>>
>>
>> https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute
>>
>> Summary
>>
>> Since M104 cookies newly created or updated with an expiration date would
>> have that date capped at no more than 400 days in the future. This same
>> limit will now be retroactively applied to cookies already in storage to
>> cap their expiration dates to no more than 400 days after the first time
>> Chrome M118+ starts up and does a one time database migration. The impact
>> of this change will not be felt by users until at least 400 days after M118
>> is released, and then only for existing cookies that have not been updated
>> in that period.
>>
>>
>> Blink component
>>
>> Internals>Network>Cookies
>> 
>>
>>
>> Motivation
>>
>> The draft of rfc6265bis
>> 
>> now contains an upper limit for Cookie Expires/Max-Age attributes. As
>> written:
>>
>> `The user agent MUST limit the maximum value of the [Max-Age/Expiration]
>> attribute. The limit MUST NOT be greater than 400 days (3456 seconds)
>> in duration. The RECOMMENDED limit is 400 days in duration, but the user
>> agent MAY adjust the limit to be less. [Max-Age/Expiration] attributes that
>> are greater than the limit MUST be reduced to the limit.`
>>
>>
>> This limit should be enforced retroactively to comply with the
>> specification and clear old cookies with high expiration dates out on a
>> reasonable timetable.
>>
>> TAG review
>>
>> Supportive  of
>> original change
>>
>> Compatibility
>>
>> In general, websites should never depend on cookies existing for some
>> predictable length of time. The browser can and will evict for any number
>> of reasons.
>>
>>
>> Interoperability
>>
>> Safari is already partially compliant (with an upper age limit of 7 days
>> when cookies are set client side but no limit when set by the server),
>> while Firefox supports cookies with expiration dates millennia in the
>> future.
>>
>> Gecko: Positive
>> 
>>
>> WebKit: Positive
>> 
>>
>> Web developers: Mostly negative or neutral on expires limits in general
>>
>> Debuggability
>>
>> Existing DevTools affordances for debugging cookie attributes will work
>> as expected here
>>
>> Is this feature fully tested by web-platform-tests?
>>
>> Yes
>> 
>>
>> Tracking bug
>>
>> https://crbug.com/1181924
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5086241845936128
>>
>>

-- 
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/CAGpy5D%2B_u5LB6wF%3DT9fu%2B2Svciv%2BWVu-oOVN1CWCvVAeHfVvAA%40mail.gmail.com.

[blink-dev] Intent to Ship: CSS logical flow relative values

[Oriol Brufau]

   Contact emails

obru...@igalia.com


   Explainer

https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/


   Specification

https://drafts.csswg.org/css-logical/#directional-keywords
https://drafts.csswg.org/css-ui/#resize 




   Design docs


https://developer.mozilla.org/docs/Web/CSS/CSS_logical_properties_and_values


   Summary

Add these new values to existing CSS properties: - float: inline-start - 
float: inline-end - clear: inline-start - clear: inline-end - resize: 
block - resize: inline




   Blink component

Blink>CSS 




   Search tags

css-logical 


   TAG review

https://github.com/w3ctag/design-reviews/issues/286
The only issue relevant to logical values 
washttps://github.com/w3c/csswg-drafts/issues/2821, which was addressed 
in the spec, and Blink obeys the resolution.



   TAG review status

Issues addressed


   Risks



   Interoperability and Compatibility

Gecko and WebKit already shipped. Gecko doesn't follow the spec.



/Gecko/: Shipped/Shipping 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1253919, 
https://bugzilla.mozilla.org/show_bug.cgi?id=1464786 
)
The implementation is wrong, 
seehttps://bugzilla.mozilla.org/show_bug.cgi?id=1661548


/WebKit/: Shipped/Shipping 
(https://bugs.webkit.org/show_bug.cgi?id=218087, 
https://bugs.webkit.org/show_bug.cgi?id=218088 
)


/Web developers/: Positive 
(https://bugs.chromium.org/p/chromium/issues/detail?id=850004#c8)


/Other signals/:


   WebView application risks

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


None



   Debuggability

The DevTools Styles panel’s autocomplete functionality is already aware 
of these new values.




   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 byweb-platform-tests
   
?

Yes


   Flag name on chrome://flags

None


   Finch feature name

CSSLogical
(This is the feature name in runtime_enabled_features.json5, which 
seemingly I'm supposed to provide here, but it's not actually using Finch)



   Requires code in //chrome?

False


   Tracking bug

https://crbug.com/850004


   Estimated milestones

Shipping on desktop 117
DevTrial on desktop 70

Shipping on Android 117
DevTrial on Android 70

Shipping on WebView 117



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


None


   Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6237096230518784


   Links to previous Intent discussions

Intent to 
prototype:https://groups.google.com/a/chromium.org/d/msg/blink-dev/48OwfwZrbvI/A1XZFGkzAwAJ


This intent message was generated byChrome 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/952390c4-1903-5f96-8e6b-b8a6235d3052%40igalia.com.

[blink-dev] Re: Intent to Prototype & Ship: Cookie Expires/Max-Age attribute upper limit for prior storage

[Alex Russell]

Hey Ari,

It isn't clear to me that the change in the RFC is a motivator to make this 
change, or that it reduces potential risk.

There are details here will matter a lot to the risk profile. IIRC, we'll 
be going first with regards to the lifetime of first-party, server-set 
cookies? Do we have an analysis of what fraction of cookies will be 
impacted? 

Thanks,

Alex

On Tuesday, August 1, 2023 at 8:59:59 AM UTC-7 Ari Chivukula wrote:

> Contact emails
>
> aric...@chromium.org, miketa...@chromium.org, bing...@chromium.org
>
> Specification
>
>
> https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#name-the-expires-attribute
>
> Summary
>
> Since M104 cookies newly created or updated with an expiration date would 
> have that date capped at no more than 400 days in the future. This same 
> limit will now be retroactively applied to cookies already in storage to 
> cap their expiration dates to no more than 400 days after the first time 
> Chrome M118+ starts up and does a one time database migration. The impact 
> of this change will not be felt by users until at least 400 days after M118 
> is released, and then only for existing cookies that have not been updated 
> in that period.
>
>
> Blink component
>
> Internals>Network>Cookies 
> 
>
>
> Motivation
>
> The draft of rfc6265bis 
> 
>  
> now contains an upper limit for Cookie Expires/Max-Age attributes. As 
> written:
>
> `The user agent MUST limit the maximum value of the [Max-Age/Expiration] 
> attribute. The limit MUST NOT be greater than 400 days (3456 seconds) 
> in duration. The RECOMMENDED limit is 400 days in duration, but the user 
> agent MAY adjust the limit to be less. [Max-Age/Expiration] attributes that 
> are greater than the limit MUST be reduced to the limit.`
>
>
> This limit should be enforced retroactively to comply with the 
> specification and clear old cookies with high expiration dates out on a 
> reasonable timetable.
>
> TAG review
>
> Supportive  of 
> original change
>
> Compatibility
>
> In general, websites should never depend on cookies existing for some 
> predictable length of time. The browser can and will evict for any number 
> of reasons.
>
>
> Interoperability
>
> Safari is already partially compliant (with an upper age limit of 7 days 
> when cookies are set client side but no limit when set by the server), 
> while Firefox supports cookies with expiration dates millennia in the 
> future.
>
> Gecko: Positive 
> 
>
> WebKit: Positive 
> 
>
> Web developers: Mostly negative or neutral on expires limits in general
>
> Debuggability
>
> Existing DevTools affordances for debugging cookie attributes will work as 
> expected here
>
> Is this feature fully tested by web-platform-tests?
>
> Yes 
> 
>
> Tracking bug
>
> https://crbug.com/1181924
>
> Link to entry on the Chrome Platform Status
>
> https://chromestatus.com/feature/5086241845936128
>
>

-- 
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/7ba41655-f176-4227-b680-ae37446328f1n%40chromium.org.

Re: [blink-dev] PSA: Browser text zoom on Android will now work like it does on desktop

['Torne (Richard Coles)' via blink-dev]

This mentions it's supported in Android WebView, but WebView has always
used the font size specified in the OS to scale text specifically (*not* to
scale CSS pixels):
https://source.chromium.org/chromium/chromium/src/+/main:android_webview/java/src/org/chromium/android_webview/AwSettings.java;l=296;drc=334d01268df246e959b238956ab956413562edfb

Does this change actually affect WebView? If so, how? If it ends up
stacking with the text zoom we are already doing then the results may not
be desirable.

On Wed, 2 Aug 2023 at 13:27, 'Jonathan Bernal' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> mschill...@google.com, rayjonath...@google.com, p...@google.com,
> ikilpatr...@google.com, aldi...@google.com, chris...@google.com
>
>
> Explainer
>
>
> https://docs.google.com/document/d/1vRVRJFaY3TWRFkrKvLhhiBemTfFxUzI_co4YZq_kB0E/edit
>
>
> Summary
>
> Browser text zoom on Android will now work like it does on desktop. See
> https://blog.google/products/android/new-android-features-february-2023/
> for a blog post about it. The default rendered zoom value of a given page
> will transparently account for a user’s OS-level font size setting. This
> means that any user on Android who has a non-default OS-level font size
> setting (~40% of users), will use a non-100% zoom on Android Chrome by
> default. This feature is currently released to 10% of stable users.
>
>
> How to opt into the feature:
>
>1.
>
>Go to chrome://flags
>2.
>
>Search for "Accessibility Page Zoom”
>3.
>
>Use the dropdown box to switch the feature from “Default” to “Enabled”
>4.
>
>Restart Chrome (force quit)
>
>
> How to use the feature:
> https://support.google.com/chrome/answer/96810?co=GENIE.Platform%3DAndroid&oco=1
> Blink component
>
> Compositor
>
>
> Risks
>
>-
>
>This will change the overall distribution of window.innerWidth values
>a website sees, which may be unexpected.
>-
>
>Don't currently have any provision for opting out specific origins
>(eg. overriding the default zoom level back to 100%) if breakage is
>discovered.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Android and Android WebView
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
>
> Flag name
>
> Accessibility Page Zoom
> Requires code in //chrome?
>
> Yes
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=645717
>
>
> Launch bug
>
> https://launch.corp.google.com/launch/4206588 (sorry, Googlers only)
>
>
> Estimated milestones
>
> M113
> Link to entry on the Chrome Platform Status
>
> N/A
>
>
> Links to previous Intent discussions
>
> N/A
>
> --
> 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/CA%2B8nQZ6JJHyUXC5fofsnSW2gAi64Xqe7WHus94FqQs%3DFMS1qOA%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/CAEV-rjfS8HbqdveWr9ve3k0E6QOW93umXc%3DWFNbSDFGgbk%3Dshg%40mail.gmail.com.

Re: [blink-dev] PSA: Browser text zoom on Android will now work like it does on desktop

[Torne (Richard Coles)]

This mentions it's supported in Android WebView, but WebView has always
used the font size specified in the OS to scale text specifically (*not* to
scale CSS pixels):
https://source.chromium.org/chromium/chromium/src/+/main:android_webview/java/src/org/chromium/android_webview/AwSettings.java;l=296;drc=334d01268df246e959b238956ab956413562edfb

Does this change actually affect WebView? If so, how? If it ends up
stacking with the text zoom we are already doing then the results may not
be desirable.

On Wed, 2 Aug 2023 at 13:27, 'Jonathan Bernal' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> mschill...@google.com, rayjonath...@google.com, p...@google.com,
> ikilpatr...@google.com, aldi...@google.com, chris...@google.com
>
>
> Explainer
>
>
> https://docs.google.com/document/d/1vRVRJFaY3TWRFkrKvLhhiBemTfFxUzI_co4YZq_kB0E/edit
>
>
> Summary
>
> Browser text zoom on Android will now work like it does on desktop. See
> https://blog.google/products/android/new-android-features-february-2023/
> for a blog post about it. The default rendered zoom value of a given page
> will transparently account for a user’s OS-level font size setting. This
> means that any user on Android who has a non-default OS-level font size
> setting (~40% of users), will use a non-100% zoom on Android Chrome by
> default. This feature is currently released to 10% of stable users.
>
>
> How to opt into the feature:
>
>1.
>
>Go to chrome://flags
>2.
>
>Search for "Accessibility Page Zoom”
>3.
>
>Use the dropdown box to switch the feature from “Default” to “Enabled”
>4.
>
>Restart Chrome (force quit)
>
>
> How to use the feature:
> https://support.google.com/chrome/answer/96810?co=GENIE.Platform%3DAndroid&oco=1
> Blink component
>
> Compositor
>
>
> Risks
>
>-
>
>This will change the overall distribution of window.innerWidth values
>a website sees, which may be unexpected.
>-
>
>Don't currently have any provision for opting out specific origins
>(eg. overriding the default zoom level back to 100%) if breakage is
>discovered.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Android and Android WebView
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No
>
>
> Flag name
>
> Accessibility Page Zoom
> Requires code in //chrome?
>
> Yes
>
>
> Tracking bug
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=645717
>
>
> Launch bug
>
> https://launch.corp.google.com/launch/4206588 (sorry, Googlers only)
>
>
> Estimated milestones
>
> M113
> Link to entry on the Chrome Platform Status
>
> N/A
>
>
> Links to previous Intent discussions
>
> N/A
>
> --
> 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/CA%2B8nQZ6JJHyUXC5fofsnSW2gAi64Xqe7WHus94FqQs%3DFMS1qOA%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/CAEV-rjeX9L6mSHxJCCxb0L5-i0%3DZ2kWXVf7Fr%3DNvSE4AdeMCKw%40mail.gmail.com.

[blink-dev] PSA: Browser text zoom on Android will now work like it does on desktop

['Jonathan Bernal' via blink-dev]

Contact emails

mschill...@google.com, rayjonath...@google.com, p...@google.com,
ikilpatr...@google.com, aldi...@google.com, chris...@google.com


Explainer

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


Summary

Browser text zoom on Android will now work like it does on desktop. See
https://blog.google/products/android/new-android-features-february-2023/
for a blog post about it. The default rendered zoom value of a given page
will transparently account for a user’s OS-level font size setting. This
means that any user on Android who has a non-default OS-level font size
setting (~40% of users), will use a non-100% zoom on Android Chrome by
default. This feature is currently released to 10% of stable users.


How to opt into the feature:

   1.

   Go to chrome://flags
   2.

   Search for "Accessibility Page Zoom”
   3.

   Use the dropdown box to switch the feature from “Default” to “Enabled”
   4.

   Restart Chrome (force quit)


How to use the feature:
https://support.google.com/chrome/answer/96810?co=GENIE.Platform%3DAndroid&oco=1
Blink component

Compositor


Risks

   -

   This will change the overall distribution of window.innerWidth values a
   website sees, which may be unexpected.
   -

   Don't currently have any provision for opting out specific origins (eg.
   overriding the default zoom level back to 100%) if breakage is discovered.


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

Android and Android WebView


Is this feature fully tested by web-platform-tests

?

No


Flag name

Accessibility Page Zoom
Requires code in //chrome?

Yes


Tracking bug

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


Launch bug

https://launch.corp.google.com/launch/4206588 (sorry, Googlers only)


Estimated milestones

M113
Link to entry on the Chrome Platform Status

N/A


Links to previous Intent discussions

N/A

-- 
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/CA%2B8nQZ6JJHyUXC5fofsnSW2gAi64Xqe7WHus94FqQs%3DFMS1qOA%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: Form Controls Support Vertical Writing Mode

[Daniel Bratell]

This could be interesting if existing content by accident has used these 
properties on their form control, but if Gecko has shipped it, we should 
just make sure it works the same in Chromium.


LGTM3

/Daniel

On 2023-08-02 18:02, Chris Harrelson wrote:

LGTM2

On Wed, Aug 2, 2023 at 9:01 AM Alex Russell  
wrote:


LGTM1

On Tuesday, August 1, 2023 at 4:31:20 PM UTC-7 Di Zhang wrote:


Contact emails


dizha...@chromium.org


Explainer


None


Specification


https://drafts.csswg.org/css-writing-modes-4/#block-flow


Summary


CSS property writing-mode should be enabled for form
controls elements as it will allow lines of text to be
laid out horizontally or vertically. With this
feature, we are allowing the form control elements
input, textarea, select, meter, progress and button to
have vertical-rl or vertical-lr writing mode. This is
important for interopability.



Blink component


Blink>Forms




TAG review


None


TAG review status


Not applicable


Risks




Interoperability and Compatibility


If a developer set an element to have `writing-mode:
vertical-lr`: Currently, will default to
`writing-mode: horizontal-tb` and show the element as
horizontal writing mode. With feature, will have
`writing-mode: vertical-lr` and show the element as
vertical writing mode.



/Gecko/: Shipped/Shipping

/WebKit/: In development

/Web developers/: No signals

/Other signals/:


Ergonomics


No, there are no other platform APIs this feature will
be frequently be used in tandem with.



Activation


It should not be challenging for developers to take
advantage of this feature immediately as it is simply
using the CSS property on the desired form control
elements.



Security


This is a form control feature and I don't expect
security risks.



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?

There are no WebView specific changes with this feature.



Debuggability


This feature is debuggable by trying to access the
form control element's writing-mode CSS value in DevTools.



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


Flag name on chrome://flags


FormControlsVerticalWritingModeSupport


Finch feature name


FormControlsVerticalWritingModeSupport


Requires code in //chrome?


False


Tracking bug


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


Measurement


None


Availability expectation


Feature is available on Web Platform mainline within
12 months of launch in Chrome.


Adoption expectation


Feature is considered a best practice for some use
case within 12 months of reaching Web Platform baseline.


Adoption plan


We plan to release this feature in milestone 118.
Firefox has already implemented this feature and
Safari is working on it as it is part of Interop2023.


Non-OSS dependencies


Does the feature depend on any code or APIs outside
the Chromium open source repository and its
open-source dependencies to function?

No


Estimated milestones


Shipping on desktop 118
DevTrial on desktop 117

Shipping on Android 118
DevTrial on Android 118

Shipping on WebView 118



Anticipated spec changes


 

Re: [blink-dev] Re: Intent to Ship: Web Serial support for Bluetooth RFCOMM services

['Ajay Rahatekar' via blink-dev]

Thank you all for your comments and review.

-Ajay

On Wednesday, August 2, 2023 at 8:53:53 AM UTC-7 Daniel Bratell wrote:

> LGTM3
>
> /Daniel
> On 2023-08-02 17:52, Chris Harrelson wrote:
>
> LGTM2
>
> On Tue, Aug 1, 2023 at 2:48 PM 'Ajay Rahatekar' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Hello API Owners, 
>>
>> Please let us know if there are any questions we can answer. This feature 
>> is planned to ship in M117 (branching Aug 8).  Requesting approval to ship. 
>> Thanks in advance.
>>
>> -Ajay 
>>
>> On Tuesday, August 1, 2023 at 9:40:59 AM UTC-7 rei...@chromium.org wrote:
>>
>>> On Tue, Aug 1, 2023, 06:01 Balazs Engedy  wrote:
>>>
 For clarity, are the per-device permissions persisted across visits? If 
 so, what device attribute(s) do we use to form a device identifier to key 
 that permission on?

>>>
>>> Yes, the Bluetooth device MAC address.
>>>
>>> On Thursday, July 27, 2023 at 7:06:37 PM UTC+2 Reilly Grant wrote:

>>> That behavior is to be expected. The "2" and ":59:NN PM" are being 
> received as separate events based on how the converter chips decide to 
> pack 
> serial data (which arrives one byte at a time) into Bluetooth or USB 
> packets which contain multiple bytes.
> Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome 
> 
>
>
> On Thu, Jul 27, 2023 at 9:02 AM Mike Taylor  
> wrote:
>
 LGTM1 to ship.
>>
>> (I'll leave you to figure out why the BT Serial port sometimes sent 
>> "2:59:NN PM" and sometimes received ":59:NN PM" :))
>> On 7/26/23 6:15 PM, Matt Reynolds wrote:
>>
> Here's a short demo video that shows the permission UI:
>>
>> https://drive.google.com/file/d/1Y_Ito9P-EourYa7ofL_qQMOmmvBIhwpT/view
>>
>> Demo source:
>>
>> https://nondebug.github.io/bluetooth-serial-port-demo/
>>
>> Off-screen I connected a HC-06 wireless Bluetooth serial transceiver 
>>  to a USB serial adapter 
>> . The demo uses Web Serial API to 
>> connect to both devices, then sends data over USB and shows that it is 
>> received from the HC-06 over Bluetooth.
>>
>>
>> On Wed, Jul 26, 2023 at 2:13 PM Mike Taylor  
>> wrote:
>>
>> LGTM1 - thanks for the well-written explainer.
>>> On 7/26/23 4:20 PM, Alex Russell wrote:
>>>
>> Sounds good; thanks for explaining.
>>>
>>> On Wednesday, July 26, 2023 at 1:02:00 PM UTC-7 Reilly Grant wrote:
>>>
 On Wed, Jul 26, 2023 at 10:03 AM Alex Russell <
 sligh...@chromium.org> wrote:

> A screenshot would go a long way. 
>
> Exciting to hear there's a partner that want this.
>
> Also, was there consideration of an OT? A strong reason to avoid?
>

 The change to the API is very small and we had strong developer 
 feedback during development that the API worked for them. I also feel 
 that 
 this kind of feature is a poor fit for an Origin Trial because it's 
 not 
 something where you can measure the impact with or without the 
 capability 
 as the capability is fundamentallyﾠnecessary for the existenceﾠof the 
 web 
 app. At that point the only benefit of an OT would be to ship an 
 end-user 
 application early, but it wouldn't be a true experiment.
  

> On Wednesday, July 26, 2023 at 9:55:25 AM UTC-7 Reilly Grant wrote:
>
>> On Wed, Jul 26, 2023 at 9:05 AM Alex Russell <
>> sligh...@chromium.org> wrote:
>>
>>> I'm going to have to stay recused on this vote, but just want to 
>>> lend my fullest non-voting support to shipping ASAP. This is 
>>> excellent 
>>> work, and I can see you've dotted i's and crossed t's in 
>>> anticipation of a 
>>> full shakedown here. Thanks for doing it. 
>>>
>>> It might be helpful for others evaluating the proposal to have a 
>>> demo or video to look at regarding the permissions UI/UX that this 
>>> will sit 
>>> behind; is it possible to add something like that to your 
>>> Explainer? And 
>>> are there users who can vouch for the utility of this feature for 
>>> their 
>>> use-cases?
>>>
>>
>> Unfortunately the hardware our partner is working on is still 
>> confidential so I can't share a real-worldﾠuse case. They're very 
>> excited 
>> about being able to use a web app. We can put together a demo video 
>> with a 
>> generic Bluetooth serial device but it will be pretty boring because 
>> theﾠpermissions UIﾠlooks identical toﾠselecting a wired serial port. 
>> We 
>> only support connecting 

Re: [blink-dev] Re: Intent to Ship: Form Controls Support Vertical Writing Mode

[Chris Harrelson]

LGTM2

On Wed, Aug 2, 2023 at 9:01 AM Alex Russell 
wrote:

> LGTM1
>
> On Tuesday, August 1, 2023 at 4:31:20 PM UTC-7 Di Zhang wrote:
>
>> Contact emailsdizha...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.csswg.org/css-writing-modes-4/#block-flow
>>
>> Summary
>>
>> CSS property writing-mode should be enabled for form controls elements as
>> it will allow lines of text to be laid out horizontally or vertically. With
>> this feature, we are allowing the form control elements input, textarea,
>> select, meter, progress and button to have vertical-rl or vertical-lr
>> writing mode. This is important for interopability.
>>
>>
>> Blink componentBlink>Forms
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> If a developer set an element to have `writing-mode: vertical-lr`:
>> Currently, will default to `writing-mode: horizontal-tb` and show the
>> element as horizontal writing mode. With feature, will have `writing-mode:
>> vertical-lr` and show the element as vertical writing mode.
>>
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: In development
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> No, there are no other platform APIs this feature will be frequently be
>> used in tandem with.
>>
>>
>> Activation
>>
>> It should not be challenging for developers to take advantage of this
>> feature immediately as it is simply using the CSS property on the desired
>> form control elements.
>>
>>
>> Security
>>
>> This is a form control feature and I don't expect security risks.
>>
>>
>> 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?
>>
>> There are no WebView specific changes with this feature.
>>
>>
>> Debuggability
>>
>> This feature is debuggable by trying to access the form control element's
>> writing-mode CSS value in DevTools.
>>
>>
>> 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
>>
>> Flag name on chrome://flagsFormControlsVerticalWritingModeSupport
>>
>> Finch feature nameFormControlsVerticalWritingModeSupport
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=681917
>>
>> MeasurementNone
>>
>> Availability expectationFeature is available on Web Platform mainline
>> within 12 months of launch in Chrome.
>>
>> Adoption expectationFeature is considered a best practice for some use
>> case within 12 months of reaching Web Platform baseline.
>>
>> Adoption planWe plan to release this feature in milestone 118. Firefox
>> has already implemented this feature and Safari is working on it as it is
>> part of Interop2023.
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>> No
>>
>> Estimated milestones
>> Shipping on desktop 118
>> DevTrial on desktop 117
>> Shipping on Android 118
>> DevTrial on Android 118
>> Shipping on WebView 118
>>
>> 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).
>> https://github.com/whatwg/html/issues/8413
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5602118873907200
>>
>> 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/d0714fc1-e163-4b87-825c-541d54d31ab0n%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/CAOMQ%2Bw9H3atqsinHzW%2BwHCpkfrgR7oV5k6mne0YRcHA0Mq8nRQ%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Form Controls Support Vertical Writing Mode

[Alex Russell]

LGTM1

On Tuesday, August 1, 2023 at 4:31:20 PM UTC-7 Di Zhang wrote:

> Contact emailsdizha...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://drafts.csswg.org/css-writing-modes-4/#block-flow
>
> Summary
>
> CSS property writing-mode should be enabled for form controls elements as 
> it will allow lines of text to be laid out horizontally or vertically. With 
> this feature, we are allowing the form control elements input, textarea, 
> select, meter, progress and button to have vertical-rl or vertical-lr 
> writing mode. This is important for interopability.
>
>
> Blink componentBlink>Forms 
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> If a developer set an element to have `writing-mode: vertical-lr`: 
> Currently, will default to `writing-mode: horizontal-tb` and show the 
> element as horizontal writing mode. With feature, will have `writing-mode: 
> vertical-lr` and show the element as vertical writing mode.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: In development
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> No, there are no other platform APIs this feature will be frequently be 
> used in tandem with.
>
>
> Activation
>
> It should not be challenging for developers to take advantage of this 
> feature immediately as it is simply using the CSS property on the desired 
> form control elements.
>
>
> Security
>
> This is a form control feature and I don't expect security risks.
>
>
> 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?
>
> There are no WebView specific changes with this feature.
>
>
> Debuggability
>
> This feature is debuggable by trying to access the form control element's 
> writing-mode CSS value in DevTools.
>
>
> 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
>
> Flag name on chrome://flagsFormControlsVerticalWritingModeSupport
>
> Finch feature nameFormControlsVerticalWritingModeSupport
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=681917
>
> MeasurementNone
>
> Availability expectationFeature is available on Web Platform mainline 
> within 12 months of launch in Chrome.
>
> Adoption expectationFeature is considered a best practice for some use 
> case within 12 months of reaching Web Platform baseline.
>
> Adoption planWe plan to release this feature in milestone 118. Firefox 
> has already implemented this feature and Safari is working on it as it is 
> part of Interop2023.
>
> Non-OSS dependencies
>
> Does the feature depend on any code or APIs outside the Chromium open 
> source repository and its open-source dependencies to function?
> No
>
> Estimated milestones
> Shipping on desktop 118
> DevTrial on desktop 117
> Shipping on Android 118
> DevTrial on Android 118
> Shipping on WebView 118
>
> 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).
> https://github.com/whatwg/html/issues/8413
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5602118873907200
>
> 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/d0714fc1-e163-4b87-825c-541d54d31ab0n%40chromium.org.

Re: [blink-dev] Re: Intent to Prototype and Ship: Clip-path geometry-box values

[Mike Taylor]

LGTM3

On 8/2/23 12:00 PM, Chris Harrelson wrote:

LGTM2

On Tue, Aug 1, 2023 at 2:19 PM Alex Russell  
wrote:


LGTM1

On Tuesday, August 1, 2023 at 1:27:31 PM UTC-7 Philip Rogers wrote:


Contact emails

p...@chromium.org


Explainer

None


Specification

https://drafts.fxtf.org/css-masking/#the-clip-path


Summary

Clip-path supports  values to control the clip's
reference box, making clip-path easier to use. These box
values can be used alongside basic shapes (for example,
clip-path: circle(50%) margin-box), or they can be used alone
to clip to the specified box (for example, clip-path:
content-box).


Blink component

Blink>Paint




Search tags

clip-path ,
clipPath ,
geometry-box
,
geometryBox 


TAG review

None


TAG review status

Not applicable


Risks


Interoperability and Compatibility

Low, as this has already shipped in both Firefox and Safari.


/Gecko/: Shipped/Shipping

/WebKit/: Shipped/Shipping

/Web developers/: Positive
(https://github.com/web-platform-tests/interop/issues/148)

/Other signals/:


WebView application risks

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

None



Debuggability

This is debuggable with existing basic CSS tooling.


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


Flag name on chrome://flags

None


Finch feature name

ClipPathGeometryBox


Requires code in //chrome?

False


Tracking bug

https://crbug.com/694218


Measurement

Overall clip-path usage is tracked with
https://chromestatus.com/metrics/css/timeline/popularity/355.


Sample links

https://pr.gg/clip-path-geometry-box-examples.html


Estimated milestones

Shipping on desktop 118

Shipping on Android 118

Shipping on WebView 118



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

None


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5068167415595008

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/0afff51b-0ee7-45c2-8ec9-6ae7eeed0f97n%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/CAOMQ%2Bw-gw%2BH4i8EFfPTif3iDo3NYbQPuxg1ksTofmiFFJ9q%2Brg%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+unsub

Re: [blink-dev] Re: Intent to Prototype and Ship: Clip-path geometry-box values

[Chris Harrelson]

LGTM2

On Tue, Aug 1, 2023 at 2:19 PM Alex Russell 
wrote:

> LGTM1
>
> On Tuesday, August 1, 2023 at 1:27:31 PM UTC-7 Philip Rogers wrote:
>
>> Contact emails...@chromium.org
>>
>> ExplainerNone
>>
>> Specificationhttps://drafts.fxtf.org/css-masking/#the-clip-path
>>
>> Summary
>>
>> Clip-path supports  values to control the clip's reference
>> box, making clip-path easier to use. These box values can be used alongside
>> basic shapes (for example, clip-path: circle(50%) margin-box), or they can
>> be used alone to clip to the specified box (for example, clip-path:
>> content-box).
>>
>> Blink componentBlink>Paint
>> 
>>
>> Search tagsclip-path ,
>> clipPath , geometry-box
>> , geometryBox
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>> Interoperability and Compatibility
>>
>> Low, as this has already shipped in both Firefox and Safari.
>>
>> *Gecko*: Shipped/Shipping
>>
>> *WebKit*: Shipped/Shipping
>>
>> *Web developers*: Positive (
>> https://github.com/web-platform-tests/interop/issues/148)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> This is debuggable with existing basic CSS tooling.
>>
>> 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
>>
>> Flag name on chrome://flagsNone
>>
>> Finch feature nameClipPathGeometryBox
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/694218
>>
>> MeasurementOverall clip-path usage is tracked with
>> https://chromestatus.com/metrics/css/timeline/popularity/355.
>>
>> Sample linkshttps://pr.gg/clip-path-geometry-box-examples.html
>>
>> Estimated milestones
>> Shipping on desktop 118
>> Shipping on Android 118
>> Shipping on WebView 118
>>
>> 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).
>> None
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5068167415595008
>>
>> 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/0afff51b-0ee7-45c2-8ec9-6ae7eeed0f97n%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/CAOMQ%2Bw-gw%2BH4i8EFfPTif3iDo3NYbQPuxg1ksTofmiFFJ9q%2Brg%40mail.gmail.com.

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

[Alex Russell]

Hey Emanuel,

Sorry for the slow follow-up, and thanks for the background.

Avoiding breaking changes when we haven't shipped yet is against the spirit 
of OT. None of this meant to enable soft-launches of the sort you're 
describing.

This is our one and only opportunity to get the API shape right; we won't 
get another moment at which we can iterate and improve the shape of the 
API. The constraints of OTs are designed to price in inconvenience for a 
small number of partners to iterate with us, including breaking changes. We 
can also run OTs in parallel to accommodate multiple variants.

With that as preamble, I'm going to -1 an extension of this OT until we 
have a lot more clarity. Please consider this a chance to make updates you 
would have proposed as post-launch breaking changes, with an opening to 
launch a new OT or I2S for the updated feature.

Are you able to perhaps join us at next week's Blink API OWNERS meeting? Or 
we can discuss as a one-off? Want to make sure we get on the same page and 
unblock you.

Best,

Alex

On Thursday, July 27, 2023 at 9:23:20 AM UTC-7 Emanuel Ziegler wrote:

> Hi Alex,
>
> Just to quickly reply on the breaking changes and what we've learnt: we 
> have been in an active collaboration with Sheets on this for over 2.5 years 
> now with a lot of development and measurements leading up to the origin 
> trial. This allowed us to shape the proposal and the implementation before 
> that. The main goal of the trial is to confirm that our expectations hold 
> up in real-world scenarios and the performance numbers that we got (~40% 
> calculation time improvement) are perfectly in line with our expectations. 
> Other findings are mostly integration issues in user space but have 
> fortunately not challenged the proposal nor our architecture. The extension 
> is meant to allow us longer and broader testing on a larger variety of 
> sheets.
>
> We have made several changes during the trial and evaluated them together 
> with J2CL and Sheets as well as other partners, but intentionally avoided 
> breaking changes as these need to be propagated to Binaryen, J2Wasm and 
> eventually Sheets which would require weeks of interruption every time. We 
> know that there will be a breaking change coming once the final version of 
> the proposal is merged in and that we will have to adapt our implementation 
> before its stable release. This does not affect the functionality as the 
> functionality is perfectly aligned, only the op codes are going to change 
> .
>
> I hope this helps alleviate your concerns.
>
> Best,
> Emanuel
>
> On Thu, Jul 27, 2023 at 2:19 AM Alex Russell  
> wrote:
>
>> I'd be much more likely to support the extension if there was a 
>> report-out on what we've learned this far, particularly given the 
>> increasing risks presented by big products using it (Sheets) given that 
>> we're proposing to stretch to 8 months with no breaking changes.
>>
>> Best,
>>
>> Alex
>>
>> On Wednesday, July 26, 2023 at 11:16:42 AM UTC-7 Emanuel Ziegler wrote:
>>
>>> On Wed, Jul 26, 2023 at 7:22 PM Chris Harrelson  
>>> wrote:
>>>
 On Wed, Jul 26, 2023 at 9:43 AM Emanuel Ziegler <
 ecmzieg...@chromium.org> wrote:

> Hi Chris,
>
> There is an extensive summary document from the Sheets colleagues 
> (including a tl;dr section in the beginning): go/sheets-wasm-corp-50
> We believe that error count and crash rate (mostly OOM) regressions 
> are caused by user space code but investigations are ongoing and we 
> expect 
> improvements over the next weeks.
>

 Thanks! This is a Google-internal document, can some of it be shared 
 publicly?

>>>
>>> I can ask, but since these numbers are WIP on a Google-internal trial 
>>> with a Google product, I would be cautious. Afterﾠall, they might not tell 
>>> that much about the state of WasmGC as a lot of this is still heavily 
>>> influenced by user space code as mentioned above. The numbers are going to 
>>> be more meaningful once we have reached a more stable state and are ready 
>>> to rollﾠit out to external users.
>>>
>>> Jetbrains is also using the OT for Kotlin, but I'm not aware of detailed 
> insights. They advertised it in a talk at WasmIO 
> ﾠa few months back.
>

 Would you mind asking them for feedback? Not blocking extending the OT, 
 but feedback from OT participants is important to gather.

>>>
>>> Sure. Jetbrains themselves surely have feedback on WasmGC in general but 
>>> likely limited insights from the trial itself. They might have received 
>>> feedback from their partners though that I can ask them about.
>>>
>>> Best regards,
> Emanuel
>
> On Wed, Jul 26, 2023 at 6:03 PM Chris Harrelson  
> wrote:
>
>> Hi,
>>
>> Could you share summary feedback and learnings from the OT so far? 
>> The Sheets pe

Re: [blink-dev] Intent to Ship: Clear BFCache during browsing data removal

[Mike Taylor]

LGTM3

On 8/2/23 11:56 AM, Chris Harrelson wrote:

LGTM2 conditioned on landing the spec.

On Wed, Aug 2, 2023 at 12:12 AM Daniel Bratell  
wrote:


Ex post facto LGTM1

Just try to get that spec updated so that developers will know
what to expect.

/Daniel


On 2023-08-02 00:32, 'Fergal Daly' via blink-dev wrote:

On Tue, 1 Aug 2023 at 23:44, Mike Taylor 
wrote:

On 8/1/23 7:54 AM, 'Mingyu Lei' via blink-dev wrote:



Contact emails

le...@chromium.org, fer...@chromium.org


Explainer

None


Specification

None

Given that WebKit is shipping this and we would like to, any
reason to not document this behavior to the Clear-Site-Data spec?


There's an issue here
.
Hopefully we can update the spec shortly,

F



Summary

When performing browsing data removal (e.g. via
chrome://settings/clearBrowserData, hard reload, or the
`Clear-Site-Data ` header), the disk and in-memory cache for
the HTTP response will be cleared. In addition to this, if
the browsing data removal's data type is "cache", then all
the BFCache entries matching the origin will be cleared as well.



Blink component

UI>Browser>Navigation>BFCache




Search tags

bfcache 


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: N/A
(https://bugzilla.mozilla.org/show_bug.cgi?id=1671182)
Firefox has removed the cache type data removal for
Clear-Site-Data header.

/WebKit/: Shipped/Shipping
(https://github.com/WebKit/WebKit/pull/4617)

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

None



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

No


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

The feature has already been released.



Requires code in //chrome?

False


Tracking bug

https://crbug.com/1428640


Estimated milestones

Shipping on desktop 115

Shipping on Android 115



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

https://github.com/w3c/webappsec-clear-site-data/issues/73


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5096684790480896

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/CAN_fHtn%3DJ5E7Hdcpv9Ojyhrf0AUdoL3PY%3DJxq7jByp5O5pPNgw%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/CAAozHLk7H%2BeZS3WH4ZuicW3oDsadWTg6CYc_0pFXhM7aJdxU5w%40mail.gmail.c

Re: [blink-dev] Intent to Ship: Clear BFCache during browsing data removal

[Chris Harrelson]

LGTM2 conditioned on landing the spec.

On Wed, Aug 2, 2023 at 12:12 AM Daniel Bratell  wrote:

> Ex post facto LGTM1
>
> Just try to get that spec updated so that developers will know what to
> expect.
>
> /Daniel
>
>
> On 2023-08-02 00:32, 'Fergal Daly' via blink-dev wrote:
>
> On Tue, 1 Aug 2023 at 23:44, Mike Taylor  wrote:
>
>> On 8/1/23 7:54 AM, 'Mingyu Lei' via blink-dev wrote:
>>
>> Contact emails le...@chromium.org, fer...@chromium.org
>>
>> Explainer None
>>
>> Specification None
>>
>> Given that WebKit is shipping this and we would like to, any reason to
>> not document this behavior to the Clear-Site-Data spec?
>>
>
> There's an issue here
> . Hopefully
> we can update the spec shortly,
>
> F
>
>
>>
>> Summary
>>
>> When performing browsing data removal (e.g. via
>> chrome://settings/clearBrowserData, hard reload, or the `Clear-Site-Data
>> ` header), the disk and in-memory cache for the HTTP response will be
>> cleared. In addition to this, if the browsing data removal's data type is
>> "cache", then all the BFCache entries matching the origin will be cleared
>> as well.
>>
>>
>> Blink component UI>Browser>Navigation>BFCache
>> 
>>
>> Search tags bfcache 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: N/A (https://bugzilla.mozilla.org/show_bug.cgi?id=1671182)
>> Firefox has removed the cache type data removal for Clear-Site-Data header.
>>
>> *WebKit*: Shipped/Shipping (https://github.com/WebKit/WebKit/pull/4617)
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)? No
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? No
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name None
>>
>> Non-finch justification
>>
>> The feature has already been released.
>>
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1428640
>>
>> Estimated milestones
>> Shipping on desktop 115
>> Shipping on Android 115
>>
>> 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).
>> https://github.com/w3c/webappsec-clear-site-data/issues/73
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5096684790480896
>>
>> 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/CAN_fHtn%3DJ5E7Hdcpv9Ojyhrf0AUdoL3PY%3DJxq7jByp5O5pPNgw%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/CAAozHLk7H%2BeZS3WH4ZuicW3oDsadWTg6CYc_0pFXhM7aJdxU5w%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/5f493d03-bd3c-6e93-8d5f-d7e7c9ac8821%40gmail.com
> 
> .
>

-- 
You 

Re: [blink-dev] Re: Intent to Ship: Web Serial support for Bluetooth RFCOMM services

[Daniel Bratell]

LGTM3

/Daniel

On 2023-08-02 17:52, Chris Harrelson wrote:

LGTM2

On Tue, Aug 1, 2023 at 2:48 PM 'Ajay Rahatekar' via blink-dev 
 wrote:


Hello API Owners,

Please let us know if there are any questions we can answer. This
feature is planned to ship in M117 (branching Aug 8).  Requesting
approval to ship. Thanks in advance.

-Ajay

On Tuesday, August 1, 2023 at 9:40:59 AM UTC-7 rei...@chromium.org
wrote:

On Tue, Aug 1, 2023, 06:01 Balazs Engedy 
wrote:

For clarity, are the per-device permissions persisted
across visits? If so, what device attribute(s) do we use
to form a device identifier to key that permission on?


Yes, the Bluetooth device MAC address.

On Thursday, July 27, 2023 at 7:06:37 PM UTC+2 Reilly
Grant wrote:

That behavior is to be expected. The "2" and ":59:NN
PM" are being received as separate events based on how
the converter chips decide to pack serial data (which
arrives one byte at a time) into Bluetooth or USB
packets which contain multiple bytes.
Reilly Grant | Software Engineer
|rei...@chromium.org |Google Chrome



On Thu, Jul 27, 2023 at 9:02 AM Mike Taylor
 wrote:

LGTM1 to ship.

(I'll leave you to figure out why the BT Serial
port sometimes sent "2:59:NN PM" and sometimes
received ":59:NN PM" :))

On 7/26/23 6:15 PM, Matt Reynolds wrote:


Here's a short demo video that shows the
permission UI:


https://drive.google.com/file/d/1Y_Ito9P-EourYa7ofL_qQMOmmvBIhwpT/view

Demo source:

https://nondebug.github.io/bluetooth-serial-port-demo/

Off-screen I connected a HC-06 wireless Bluetooth
serial transceiver
 to a USB serial
adapter . The
demo uses Web Serial API to connect to both
devices, then sends data over USB and shows that
it is received from the HC-06 over Bluetooth.


On Wed, Jul 26, 2023 at 2:13 PM Mike Taylor
 wrote:



LGTM1 - thanks for the well-written explainer.

On 7/26/23 4:20 PM, Alex Russell wrote:


Sounds good; thanks for explaining.

On Wednesday, July 26, 2023 at 1:02:00 PM
UTC-7 Reilly Grant wrote:

On Wed, Jul 26, 2023 at 10:03 AM Alex
Russell  wrote:

A screenshot would go a long way.

Exciting to hear there's a partner
that want this.

Also, was there consideration of an
OT? A strong reason to avoid?


The change to the API is very small and
we had strong developer feedback during
development that the API worked for
them. I also feel that this kind of
feature is a poor fit for an Origin
Trial because it's not something where
you can measure the impact with or
without the capability as the capability
is fundamentallyﾠnecessary for the
existenceﾠof the web app. At that point
the only benefit of an OT would be to
ship an end-user application early, but
it wouldn't be a true experiment.

On Wednesday, July 26, 2023 at
9:55:25 AM UTC-7 Reilly Grant wrote:

On Wed, Jul 26, 2023 at 9:05 AM
Alex Russell
 wrote:

I'm going to have to stay
recused on this vote, but
just want to lend my fullest
non-voting support to
shipping ASAP. This is
excellent work, and I can
see you've dotted i's and
crossed t's in anticipation
of a

Re: [blink-dev] Intent to Ship: Protected Audience features: recency, rounding bids & scores

[Alex Russell]

LGTM3

On Wednesday, July 26, 2023 at 10:21:53 AM UTC-7 Mike Taylor wrote:

> LGTM2
> On 7/26/23 12:10 PM, Chris Harrelson wrote:
>
> LGTM1
>
> On Tue, Jul 25, 2023 at 5:31 PM Paul Jensen  
> wrote:
>
>> Contact emails 
>>
>> pauljen...@chromium.org
>>
>> Explainer 
>>
>>
>> https://github.com/WICG/turtledove/pull/639/files?short_path=d65ba97#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624
>>
>>
>> https://github.com/WICG/turtledove/pull/486/files?short_path=d65ba97#diff-d65ba9778fe3af46de3edfce2266b5b035192f8869280ec07179963b81f4e624
>>
>> Specification 
>>
>> https://github.com/WICG/turtledove/pull/711
>>
>> https://github.com/WICG/turtledove/pull/636
>>
>> Summary 
>>
>> This I2S covers two features extending Protected Audience:
>>
>> Recency:
>>
>> The “recency” signal for Protected Audience interest groups indicates how 
>> long ago the user was joined to an interest group, which can be a useful 
>> signal when calculating an ad auction bid (e.g. recently expressed interest 
>> likely indicates more interest).  Previously we provided this signal in 
>> a strictly bucketed and noised form to buyers’ win reporting function, 
>> reportWin().   This 
>> change additionally exposes this signal to the buyers’ bidding function, 
>> generateBid().  It can be provided without bucketing or noising to 
>> generateBid() like other signals available in that function. In fact, 
>> Protected Audience already allows developers to calculate this signal (e.g. 
>> by storing join time in the interest group), but developers have asked (see 
>> “Web Developers” section below) to have the browser supply it to 
>> generateBid() to ensure it’s calculated identically to the value supplied 
>> to the reporting function, so that models training on the reported data are 
>> compatible with bidding.
>>
>> Rounding bids and scores:
>>
>> In Protected Audience, the bid price and desirability score pass from 
>> functions that have access to cross-site data (generateBid() and scoreAd()) 
>> to the reporting worklets that have access to first party data (reportWin() 
>> and reportResult()), so to prevent event-level win reports from 
>> facilitating cross-site identity joins, we need to limit this data as much 
>> as possible.  This change limits the information in the bid price and 
>> desirability score by rounding them from 64-bit floating-point numbers to 
>> 16-bit floating point numbers. Previously these numbers were not rounded.
>>
>> Blink component 
>>
>> Blink>InterestGroups 
>> 
>>
>> TAG review 
>>
>> The parent proposal, Protected Audience, is still pending: 
>> https://github.com/w3ctag/design-reviews/issues/723
>>
>> TAG review status 
>>
>> Pending
>>
>> Risks 
>> Interoperability and Compatibility 
>>
>> Recency: This is unlikely to break existing sites as it’s only adding a 
>> new field to an object the browser provides to Protected Audience bidding 
>> and scoring scripts.
>>
>> Rounding: This is unlikely to break existing sites as it’s only clearing 
>> some of the less significant bits of the bid and score values, while not 
>> changing the most significant bits or where the values flow from and to.
>>
>> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked 
>> here  and here 
>> .
>>
>> Web developers:
>>
>> Recency: Adtechs asked for the recency feature here 
>>  
>> as part of the larger ask 
>> .
>>
>> Rounding: This has been part of Protected Audience’s plan to accomplish 
>> our privacy goals for some time.  We haven’t heard significant resistance.
>>
>> Debuggability 
>>
>> These features affect values provided to Protected Audience scripts 
>> (generateBid(), reportResult(), reportWin()) which are debuggable via 
>> Chrome DevTools.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)? 
>>
>> It will be supported on all platforms that support Protected Audience, so 
>> all but WebView.
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? 
>>
>> These are in progress and hope to land before M116 stable release.
>>
>> Finch feature name 
>>
>> FledgeRounding
>>
>> Requires code in //chrome? 
>>
>> False
>>
>> Estimated milestones 
>>
>> Shipping on desktop and Android in M116.
>>
>> Anticipated spec changes 
>>
>> None related to these two features.
>>
>> Link to entry on the Chrome Platform Status 
>>
>> https://chromestatus.com/feature/5084137479733248
>>
>> This intent message was generated by Chrome Platform Status 
>> 

Re: [blink-dev] Re: Intent to Ship: Web Serial support for Bluetooth RFCOMM services

[Chris Harrelson]

LGTM2

On Tue, Aug 1, 2023 at 2:48 PM 'Ajay Rahatekar' via blink-dev <
blink-dev@chromium.org> wrote:

> Hello API Owners,
>
> Please let us know if there are any questions we can answer. This feature
> is planned to ship in M117 (branching Aug 8).  Requesting approval to ship.
> Thanks in advance.
>
> -Ajay
>
> On Tuesday, August 1, 2023 at 9:40:59 AM UTC-7 rei...@chromium.org wrote:
>
>> On Tue, Aug 1, 2023, 06:01 Balazs Engedy  wrote:
>>
>>> For clarity, are the per-device permissions persisted across visits? If
>>> so, what device attribute(s) do we use to form a device identifier to key
>>> that permission on?
>>>
>>
>> Yes, the Bluetooth device MAC address.
>>
>> On Thursday, July 27, 2023 at 7:06:37 PM UTC+2 Reilly Grant wrote:
>>>
>> That behavior is to be expected. The "2" and ":59:NN PM" are being
 received as separate events based on how the converter chips decide to pack
 serial data (which arrives one byte at a time) into Bluetooth or USB
 packets which contain multiple bytes.
 Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome
 


 On Thu, Jul 27, 2023 at 9:02 AM Mike Taylor 
 wrote:

>>> LGTM1 to ship.
>
> (I'll leave you to figure out why the BT Serial port sometimes sent
> "2:59:NN PM" and sometimes received ":59:NN PM" :))
> On 7/26/23 6:15 PM, Matt Reynolds wrote:
>
 Here's a short demo video that shows the permission UI:
>
> https://drive.google.com/file/d/1Y_Ito9P-EourYa7ofL_qQMOmmvBIhwpT/view
>
> Demo source:
>
> https://nondebug.github.io/bluetooth-serial-port-demo/
>
> Off-screen I connected a HC-06 wireless Bluetooth serial transceiver
>  to a USB serial adapter
> . The demo uses Web Serial API to
> connect to both devices, then sends data over USB and shows that it is
> received from the HC-06 over Bluetooth.
>
>
> On Wed, Jul 26, 2023 at 2:13 PM Mike Taylor 
> wrote:
>
> LGTM1 - thanks for the well-written explainer.
>> On 7/26/23 4:20 PM, Alex Russell wrote:
>>
> Sounds good; thanks for explaining.
>>
>> On Wednesday, July 26, 2023 at 1:02:00 PM UTC-7 Reilly Grant wrote:
>>
>>> On Wed, Jul 26, 2023 at 10:03 AM Alex Russell 
>>> wrote:
>>>
 A screenshot would go a long way.

 Exciting to hear there's a partner that want this.

 Also, was there consideration of an OT? A strong reason to avoid?

>>>
>>> The change to the API is very small and we had strong developer
>>> feedback during development that the API worked for them. I also feel 
>>> that
>>> this kind of feature is a poor fit for an Origin Trial because it's not
>>> something where you can measure the impact with or without the 
>>> capability
>>> as the capability is fundamentallyﾠnecessary for the existenceﾠof the 
>>> web
>>> app. At that point the only benefit of an OT would be to ship an 
>>> end-user
>>> application early, but it wouldn't be a true experiment.
>>>
>>>
 On Wednesday, July 26, 2023 at 9:55:25 AM UTC-7 Reilly Grant wrote:

> On Wed, Jul 26, 2023 at 9:05 AM Alex Russell <
> sligh...@chromium.org> wrote:
>
>> I'm going to have to stay recused on this vote, but just want to
>> lend my fullest non-voting support to shipping ASAP. This is 
>> excellent
>> work, and I can see you've dotted i's and crossed t's in 
>> anticipation of a
>> full shakedown here. Thanks for doing it.
>>
>> It might be helpful for others evaluating the proposal to have a
>> demo or video to look at regarding the permissions UI/UX that this 
>> will sit
>> behind; is it possible to add something like that to your Explainer? 
>> And
>> are there users who can vouch for the utility of this feature for 
>> their
>> use-cases?
>>
>
> Unfortunately the hardware our partner is working on is still
> confidential so I can't share a real-worldﾠuse case. They're very 
> excited
> about being able to use a web app. We can put together a demo video 
> with a
> generic Bluetooth serial device but it will be pretty boring because
> theﾠpermissions UIﾠlooks identical toﾠselecting a wired serial port. 
> We
> only support connecting to devices that are already paired with the 
> system
> so it doesn't use the more complex scanning UX that you see for Web
> Bluetooth.ﾠﾠ
>
>
>> Thanks,
>>
>> Alex
>>
>> On Tuesday, July 25, 2023 at 1:47:30 PM UTC-7
>> ajayra...@google.com wrote:
>>
>>> Contact emails
>>>
>

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Tim Williams]

Hey Mike,
Thanks for the update!
I totally understand your timing, and it's on us to blame for missing this 
out (or at least we thought that it would be together with the cookie 
update which was postponed several times).

Anyway, I encourage you to postpone the timing until the trial bug will be 
fixed to enable us, and other developers who would like to use the trial 
meta tag to be able to do so.

Thanks!

On Monday, July 31, 2023 at 7:55:33 PM UTC+3 Mike Taylor wrote:

> Thanks for the bug report! We'll triage it in our regular meeting tomorrow.
>
> And yes, your understanding of the timing is correct (we've been working 
> on this project for 2+ years 
> ,
>  
> and in dev-trial since September 
>  of 
> last year). Note that advancing to a higher percentage will depend on the 
> stability and web-compatibility of partitioned 3P storage.
>
> thanks,
> Mike
> On 7/30/23 12:04 PM, Tim Williams wrote:
>
> I've submitted the following bug: 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1468811 since the 
> trial isn't working while I did everything right.
>
> On Saturday, July 29, 2023 at 2:52:22 AM UTC+3 Tim Williams wrote:
>
>> Hey There, 
>> I am truly struggling to understand the timing here.
>> Currently, the partitioning is under a flag.
>> Are you saying that the flag would be turned on to 100% of Desktop and 
>> Android users on Sept 8th THIS YEAR??
>>
>> That's a huge and extremely fast change, wow.
>>
>> On Thursday, July 27, 2023 at 10:33:01 PM UTC+3 Kyra Seevers wrote:
>>
>>> Hi all, 
>>>
>>> M115 is now being served at 100% on Desktop and Android. We will begin 
>>> the rollout to Stable 1% shortly - the approximate rollout schedule is now 
>>> as follows:
>>>
>>> Stable 1%: July 28th
>>> Stable 10%: Aug 11th
>>> Stable 50%: Aug 25th
>>> Stable 100%: Sept 8th
>>>
>>> On Thu, Jul 27, 2023 at 11:52 AM Mike Taylor  
>>> wrote:
>>>
 No, we don't know with certainty. 

 You can watch 
 https://chromiumdash.appspot.com/releases?platform=Windows to see when 
 115 is being served to 100% for all platforms. Today it's at 50% for 
 Windows, for example.
 On 7/26/23 5:39 PM, Jagadeesha B Y wrote:

 Do we know when does M115 will hit 100%?  Exact date would help us to 
 communicate on the storage partition impact to our customers. 


 On Wednesday, July 26, 2023 at 2:12:10 PM UTC-7 mike...@chromium.org 
 wrote:

> On 7/26/23 4:01 PM, Vi S wrote:
>
> Hi Kyra, 
>
> Per your message here (
> https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/tu0i5OmhCAAJ)
>  
> it sounds like as of 7/26/2023, the Storage Partitioning change has not 
> been released yet since M115 is not served to 100% of users. Is that 
> correct? My understanding of this message is that M115 is currently 
> served 
> to 12.5% of users and that once M115 is served to 100% of users (which 
> will 
> happen in the next ~4 weeks), only then will the storage partition change 
> be rolled out in a gradual manner. Is this understanding accurate?
>
> That's correct.
>
>
> Additionally, would you be able to provide an updated schedule for the 
> rollout of the storage partitioning change (similar to the one linked 
> here: 
> https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/Tts2gjrEBwAJ)
>  
> ?
>
> Once we begin the gradual roll-out, we'll provide a estimated rollout 
> schedule on this thread (I hesitate to do so now - it's hard to know when 
> we will begin exactly).
>
> thanks,
> Mike
>
>
> Thank you
>
> On Monday, July 24, 2023 at 10:18:26 AM UTC-4 Kyra Seevers wrote:
>
>> Hi there,
>>
>> Thank you for your email - as of today (Monday 7/24/23), the feature 
>> is not rolled-out to stable.
>>
>> However, I can confirm that the rollout schedule for this feature 
>> begins in M115 at Stable 1% (once M115 is served to 100% of users). M115 
>> is 
>> currently served to 12.5% of users - you can track the status at 
>> https://chromiumdash.appspot.com/releases?platform=Windows. Two 
>> weeks after that, we'll go to 10%, assuming no large stability or 
>> compatibility regressions. Then 50 and 100% at additional 2 week 
>> increments.
>>
>>
>> In the meantime, we have a deprecation trial (
>> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials)
>>  
>> running in M115+ that allows sites who opt-in to maintain unpartitioned 
>> storage for a few milestones while they develop a 
>> storage-partitioning-compatible solution. 
>>
>> Thanks,
>>
>> Kyra
>>
>> On Sun, Jul 23, 2023 at 7:0

Re: [blink-dev] Intent to Ship: Clear BFCache during browsing data removal

[Daniel Bratell]

Ex post facto LGTM1

Just try to get that spec updated so that developers will know what to 
expect.


/Daniel


On 2023-08-02 00:32, 'Fergal Daly' via blink-dev wrote:

On Tue, 1 Aug 2023 at 23:44, Mike Taylor  wrote:

On 8/1/23 7:54 AM, 'Mingyu Lei' via blink-dev wrote:



Contact emails

le...@chromium.org, fer...@chromium.org


Explainer

None


Specification

None

Given that WebKit is shipping this and we would like to, any
reason to not document this behavior to the Clear-Site-Data spec?


There's an issue here 
. 
Hopefully we can update the spec shortly,


F



Summary

When performing browsing data removal (e.g. via
chrome://settings/clearBrowserData, hard reload, or the
`Clear-Site-Data ` header), the disk and in-memory cache for the
HTTP response will be cleared. In addition to this, if the
browsing data removal's data type is "cache", then all the
BFCache entries matching the origin will be cleared as well.



Blink component

UI>Browser>Navigation>BFCache




Search tags

bfcache 


TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: N/A
(https://bugzilla.mozilla.org/show_bug.cgi?id=1671182) Firefox
has removed the cache type data removal for Clear-Site-Data header.

/WebKit/: Shipped/Shipping
(https://github.com/WebKit/WebKit/pull/4617)

/Web developers/: No signals

/Other signals/:


WebView application risks

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

None



Debuggability

None



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

No


Is this feature fully tested by web-platform-tests

?

No


Flag name on chrome://flags

None


Finch feature name

None


Non-finch justification

The feature has already been released.



Requires code in //chrome?

False


Tracking bug

https://crbug.com/1428640


Estimated milestones

Shipping on desktop 115

Shipping on Android 115



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

https://github.com/w3c/webappsec-clear-site-data/issues/73


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5096684790480896

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/CAN_fHtn%3DJ5E7Hdcpv9Ojyhrf0AUdoL3PY%3DJxq7jByp5O5pPNgw%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/CAAozHLk7H%2BeZS3WH4ZuicW3oDsadWTg6CYc_0pFXhM7aJdxU5w%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/5f493d03-bd3c-6e93-8d5f-d7e7c9ac8821%40gmail.com.