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

[Ari Chivukula]

Re-opening this since it's been a month and we're a week after the
September 6th cliff where cookies in stable that were limited to 400 days
as of M104 start expiring (if they were not subsequently renewed).

I haven't seen any negative feedback or questions around unexpected cookie
expirations in the past week and the latest metrics show < .035% of page
loads (and falling) sending cookies that had not been renewed in the last
350-400 days.

I think it's reasonable to impose the same limit on cookies that happened
to be stored before M104 as the limit imposed on those after (the 400 day
expiration cap) and we should do so in M119.

It's important to note this cap will *not* simply retroactively expire all
older cookies but instead cap any cookies with expirations more than 400
days after M119+ is first launched by a user to expire no more than 400
days after that time. For example:

Site X stored Cookie Y pre-M104 expires January 1, .
M119 first launched by user January 1, 2024.
Cookie Y now expires February 4, 2025.
Site X renews Cookie Y by storing it again January 1, 2025.
Cookie Y now expires February 5, 2026.

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


On Fri, Aug 11, 2023 at 6:23 PM Ari Chivukula  wrote:

> I have no objections to delaying until M119. I'll check back in a week or
> two after the September 6 cliff when cookies in stable that were limited to
> 400 days as of M104 start expiring. It's important to note we will only be
> able to discuss the presence of lack of bug reports from sites and users
> (there won't be other additional data available).
>
> ~ Ari Chivukula (Their/There/They're)
>
> On Fri, Aug 11, 2023, 07:14 Mike Taylor  wrote:
>
>> Perhaps we could delay this change until M119 as I understand that the
>> first cookies that were set more than 400 days ago are due to expire in the
>> M118 window. That should give us some time to understand the impact in more
>> concrete terms and mitigate some of the impact, were it to turn out to that
>> 400 days is not the right balance between utility and protecting users.
>>
>> (I should note that I'm supportive of this change as proposed as a net
>> positive for security, but am recused from voting on it.)
>> On 8/10/23 9:52 AM, Ari Chivukula wrote:
>>
>> It's true we don't have a lot of data on the impact of this specifically,
>> but part of that is due to 400 day lag between enforcement and anyone in
>> prod feeling the effects. We could try to produce data on the amount of
>> cookies already in the store that would be newly capped, but that won't
>> really tell us what will happen if they expire a year from now.
>>
>> Some sites may have to adapt their preferences to be re-written to the
>> cookie store if they haven't already, but this change is starting another
>> 400 day counter for sites to adapt the same way was done a year ago.
>>
>> ~ Ari Chivukula (Their/There/They're)
>>
>> On Thu, Aug 3, 2023, 05:45 Daniel Bratell  wrote:
>>
>>> So my assumption is the pessimistic one that most sites won't notice
>>> this policy change even if we publish posts about it. And even if users and
>>> sites can survive lost cookies, it might still be a disruption that was
>>> unexpected and unwanted. But I don't have any good idea of how disruptive
>>> and how common it will be. It might not be a real problem at all, but I am
>>> missing the knowledge and data to understand what the size of the risk is.
>>>
>>> My hope was that you would have some information or data that would show
>>> to me that there is nothing to be concerned about. I don't think I'm there
>>> yet, but if cookies are already limited to 400 days, that is a good
>>> indication it can't be too much of a problem.
>>>
>>> /Daniel
>>> On 2023-08-03 14:03, Ari Chivukula wrote:
>>>
>>> I guess I'm a little confused on the direction of the conversation. If a
>>> user starts using chrome today no cookie can set an expiration date more
>>> than 400 days in the future, so all sites must already adapt to that
>>> present reality.
>>>
>>> Some users with cookies stored before this limit was imposed around a
>>> year ago have cookies that expire years in the future. After this change
>>> via a DB migration, those cookies would be capped to 400 days after the DB
>>> migration was run. No user will lose cookies in the DB migration itself.
>>>
>>> I don't think we know how many sites depend on cookies that are set once
>>> and never again, but given cookie retention timelines are not guaranteed
>>> sites should not do this. The actual expiration time of the cookie isn't
>>> returned in the cookie header or document.cookie, so sites should already
>>> be refreshing cookies (by setting them again) on occasion.
>>>
>>> ~ Ari Chivukula (Their/There/They're)
>>>
>>> On Thu, Aug 3, 2023, 07:44 Daniel Bratell  wrote:
>>>
 I like the idea of automatically clearing out unused cookies, but I am
 unclear if that is what happens here.

 In an hypothetical scenario, a user of website awesomeapp.

Re: [blink-dev] Intent to Ship: Payment handler minimal header UX

[Mike Taylor]

LGTM1 (I'm not sure you need our approvals to ship this UX change, but 
you can have mine).


On 9/8/23 7:09 PM, Rouslan Solomakhin wrote:

*Contact emails
*nbur...@chromium.org

*Explainer*
https://crbug.com/1385136 - see comment 14 for screenshot

*Specification*
Not applicable

*Design docs*
(Google internal only, sorry): 
https://docs.google.com/document/d/1hCIzyBALzpFPuHQ_xCNvIpSrMThq8PA6Qgi0M2iF9vk/edit?resourcekey=0-VMUV90L2bb2OqlrBVepW4A#heading=h.bat9awopsp53 



*Summary*
This is a refresh of the browser UI associated with the Payment 
Handler API. There are no API changes. The origin trial is concluding 
and we'd like to ship this feature in M119. See R2E < 
https://groups.google.com/a/chromium.org/g/blink-dev/c/NQ-WLvfmPs8/m/hDKJNnmOBgAJ> 
for more details.


*Blink component*
Blink>Payments 



*TAG review*
Not applicable

*TAG review status*
Not applicable

*Risks*

*Interoperability and Compatibility*
None.

/Gecko: N/A/
/WebKit: N/A/

/Web developers: No signals/

/Other signals: No signals/


*WebView application risks*

/None/


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

No

*Debuggability*
N/A because it is a UI-only change.

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

No. Only desktop platforms - Windows, Mac, Linux, Chrome OS.

*Is this feature fully tested by web-platform-tests?*
No, because this is a UI-only change.

*Flag name*
PaymentHandlerMinimalHeaderUX

*Finch feature name*
None

*Non-finch justification*
None

*Requires code in //chrome?*
True

*Estimated milestones*
Shipping on desktop: 119

*Anticipated spec changes*
N/A, because there is no spec for a UI-only change.

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

*Links to previous Intent discussions*
Intent to Experiment: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/NQ-WLvfmPs8/m/hDKJNnmOBgAJ


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/CAMMzaWEp6JQOKeYBjkhGa_w%3DQvDuEOPZu590FrDLj3%2Bg2eWQWQ%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/4c3078ba-ab44-4c54-96d9-5a9ba36a5523%40chromium.org.

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

[Philip Jägenstedt]

LGTM1

If there is feedback on the TAG review or Mozilla issue while this feature
is on its way to stable, can you loop back to this thread?

On Thu, Sep 7, 2023 at 4:01 PM Philip Jägenstedt 
wrote:

> Thanks for investigating and fixing the failures, Koji!
>
> On the UA defined rules, if other vendors are happy with the examples
> used, then that's what matters in practice. If you do get pushback on
> specific examples I hope there are others that can be used that are a
> common ground.
>
> I think everything looks good here, but since the TAG review and Mozilla
> issue were filed recently, I'd like to give those a bit more time.
>
> On Thu, Sep 7, 2023 at 11:14 AM Koji Ishii  wrote:
>
>> I've got two updates on the questions:
>>
>> On Thu, Sep 7, 2023 at 2:46 AM Koji Ishii  wrote:
>>
>>> Good point, thanks for asking.
>>>
>>> Technically speaking, we can't write any tests because the
>>> language-specific content analysis is UA defined. Tests use common and easy
>>> words that most engines would analyze the same way, but you're right that
>>> we may need to modify tests if any engine analyzes them differently.
>>>
>>> Tests contain that in comments, like this
>>> 
>>> or this
>>> .
>>> I'm also talking to WebKit about tests, since there are currently two known
>>> engines; one in ICU and one in macOS/iOS. We'll work together to ensure
>>> words in tests are common and easy enough for both engines.
>>>
>>
>> In case this helps, the situation is the same as hyphenation tests. In
>> the past, wpt tests needed updates when one implementation hyphenates
>> differently from other browsers. I remember this happened at least once
>> before.
>>
>> Four tests failing is strange, thanks for pointing them out too, they all
>>> pass in Chromium bots. I'll check them and make sure they're all green
>>> before shipping.
>>>
>>
>> I've figured them out, all fixes landed, I'll watch when wpt.fyi will be
>> updated. One was a recent spec change I wasn't aware of, three were
>> differences between wpt bots and chromium bots (#41851
>> .)
>>
>

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

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

[Daniel Bratell]

LGTM1

There will be some day late in 2024, early in 2025 that will be the 
death of many cookies. I now believe the risk of that being a problem is 
low enough.


/Daniel

On 2023-09-13 13:12, Ari Chivukula wrote:
Re-opening this since it's been a month and we're a week after the 
September 6th cliff where cookies in stable that were limited to 400 
days as of M104 start expiring (if they were not subsequently renewed).


I haven't seen any negative feedback or questions around unexpected 
cookie expirations in the past week and the latest metrics show < 
.035% of page loads (and falling) sending cookies that had not been 
renewed in the last 350-400 days.


I think it's reasonable to impose the same limit on cookies that 
happened to be stored before M104 as the limit imposed on those after 
(the 400 day expiration cap) and we should do so in M119.


It's important to note this cap will *not* simply retroactively expire 
all older cookies but instead cap any cookies with expirations more 
than 400 days after M119+ is first launched by a user to expire no 
more than 400 days after that time. For example:


Site X stored Cookie Y pre-M104 expires January 1, .
M119 first launched by user January 1, 2024.
Cookie Y now expires February 4, 2025.
Site X renews Cookie Y by storing it again January 1, 2025.
Cookie Y now expires February 5, 2026.

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


On Fri, Aug 11, 2023 at 6:23 PM Ari Chivukula  
wrote:


I have no objections to delaying until M119. I'll check back in a
week or two after the September 6 cliff when cookies in stable
that were limited to 400 days as of M104 start expiring. It's
important to note we will only be able to discuss the presence of
lack of bug reports from sites and users (there won't be other
additional data available).

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

On Fri, Aug 11, 2023, 07:14 Mike Taylor 
wrote:

Perhaps we could delay this change until M119 as I understand
that the first cookies that were set more than 400 days ago
are due to expire in the M118 window. That should give us some
time to understand the impact in more concrete terms and
mitigate some of the impact, were it to turn out to that 400
days is not the right balance between utility and protecting
users.

(I should note that I'm supportive of this change as proposed
as a net positive for security, but am recused from voting on it.)

On 8/10/23 9:52 AM, Ari Chivukula wrote:

It's true we don't have a lot of data on the impact of this
specifically, but part of that is due to 400 day lag between
enforcement and anyone in prod feeling the effects. We could
try to produce data on the amount of cookies already in the
store that would be newly capped, but that won't really tell
us what will happen if they expire a year from now.

Some sites may have to adapt their preferences to be
re-written to the cookie store if they haven't already, but
this change is starting another 400 day counter for sites to
adapt the same way was done a year ago.

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

On Thu, Aug 3, 2023, 05:45 Daniel Bratell
 wrote:

So my assumption is the pessimistic one that most sites
won't notice this policy change even if we publish posts
about it. And even if users and sites can survive lost
cookies, it might still be a disruption that was
unexpected and unwanted. But I don't have any good idea
of how disruptive and how common it will be. It might not
be a real problem at all, but I am missing the knowledge
and data to understand what the size of the risk is.

My hope was that you would have some information or data
that would show to me that there is nothing to be
concerned about. I don't think I'm there yet, but if
cookies are already limited to 400 days, that is a good
indication it can't be too much of a problem.

/Daniel

On 2023-08-03 14:03, Ari Chivukula wrote:

I guess I'm a little confused on the direction of the
conversation. If a user starts using chrome today no
cookie can set an expiration date more than 400 days in
the future, so all sites must already adapt to that
present reality.

Some users with cookies stored before this limit was
imposed around a year ago have cookies that expire years
in the future. After this change via a DB migration,
those cookies would be capped to 400 days after the DB
migration was run. No user will lose cookies in the DB
migration itself.

I don't think we know how many sites depend on cookies

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

[Daniel Bratell]

LGTM2

/Daniel

On 2023-09-13 17:14, Philip Jägenstedt wrote:

LGTM1

If there is feedback on the TAG review or Mozilla issue while this 
feature is on its way to stable, can you loop back to this thread?


On Thu, Sep 7, 2023 at 4:01 PM Philip Jägenstedt  
wrote:


Thanks for investigating and fixing the failures, Koji!

On the UA defined rules, if other vendors are happy with the
examples used, then that's what matters in practice. If you do get
pushback on specific examples I hope there are others that can be
used that are a common ground.

I think everything looks good here, but since the TAG review and
Mozilla issue were filed recently, I'd like to give those a bit
more time.

On Thu, Sep 7, 2023 at 11:14 AM Koji Ishii  wrote:

I've got two updates on the questions:

On Thu, Sep 7, 2023 at 2:46 AM Koji Ishii 
wrote:

Good point, thanks for asking.

Technically speaking, we can't write any tests because the
language-specific content analysis is UA defined. Tests
use common and easy words that most engines would analyze
the same way, but you're right that we may need to modify
tests if any engine analyzes them differently.

Tests contain that in comments, like this


or this

.
I'm also talking to WebKit about tests, since there are
currently two known engines; one in ICU and one in
macOS/iOS. We'll work together to ensure words in tests
are common and easy enough for both engines.


In case this helps, the situation is the same as hyphenation
tests. In the past, wpt tests needed updates when one
implementation hyphenates differently from other browsers. I
remember this happened at least once before.

Four tests failing is strange, thanks for pointing them
out too, they all pass in Chromium bots. I'll check them
and make sure they're all green before shipping.


I've figured them out, all fixes landed, I'll watch when
wpt.fyi will be updated. One was a recent spec change I wasn't
aware of, three were differences between wpt bots and chromium
bots (#41851
.)

--
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/CAARdPYfPQhus6RhhrdbBuhzPQaQraqSLOhHfxAyQ5eMgoy1sOA%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/fd3bdb5b-d2a8-c524-d61f-f92ab90489ce%40gmail.com.

Re: [blink-dev] Intent to Experiment: WebAssembly JS String Builtins

[Daniel Bratell]

Do you plan to run it as a finch experiment or do you have partners 
prepared for an Origin Trial?


/Daniel

On 2023-09-12 21:24, 'Emanuel Ziegler' via blink-dev wrote:



Dear API Owners,


Many use cases for WasmGC require calling JS functions or
WebAPIs frequently. These calls suffer from substantial
overhead when strings are involved due to the
encoding/decoding required for changing in between the
non-standardized Wasm module representation and the
engine-internal JS string representation.


We previously evaluated native string operations in Wasm

which
would map to JS equivalents and use the same backend,
eliminating the need for re-encoding and copies. While the
performance of this approach was excellent (see e.g.
Kotlin/Wasm's DBMonster benchmark with
and without
stringref), the Wasm Community
Group preferred an alternative solution that uses imported JS
functions

for
creating and manipulating strings which could then be
optimized away by the engine. Our experiments show a similar
peak performance but slightly lower performance on startup as
Liftoff is not capable of doing such optimizations effectively
falling back to executing the call.


We would therefore like to launch a 6-month origin trial
starting in M119 for comparing the two approaches and, if
performance is good enough, encourage partners to switch over
to the new proposal to verify its viability.



Contact emails

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


Explainer

None


Specification

https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md


Summary

This feature exposes common JS string operations for easy import into 
WebAssembly and optimizations thereof. This allows creating and 
manipulating JS strings from WebAssembly without native support within 
WebAssembly while still allowing for a similar performance as native 
string references. The mechanism works by exposing suitably strict 
versions of JS string operations in the WebAssembly JS API. These can 
be imported by modules using externref as a generic data type for 
storing the strings. The engine can identify that these imports can be 
represented by native graph operators without the need for calling 
into JS. This leads to a comparable peak performance as native string 
operations while allowing quick interoperability with JS since no 
copying at the boundary is required when calling into arbitrary JS 
functions that consume strings.




Blink component

Blink>JavaScript>WebAssembly 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Positive

/WebKit/: No signal

/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



Goals for experimentation



Ongoing technical constraints

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

None


Requires code in //chrome?

False


Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6695587390423040
--
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/CAPAU7RyzxKa0Pj6q7B_jyfT%3DH%2BSK264%3Dx8wn1ans%3D8UjHRhctQ%40mail.gmail.com 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubsc

Re: [blink-dev] Intent to Ship: Payment handler minimal header UX

[Daniel Bratell]

LGTM2 (Also not sure you need this approval, but you can have mine as well)

/Daniel

On 2023-09-13 16:46, Mike Taylor wrote:


LGTM1 (I'm not sure you need our approvals to ship this UX change, but 
you can have mine).


On 9/8/23 7:09 PM, Rouslan Solomakhin wrote:

*Contact emails
*nbur...@chromium.org

*Explainer*
https://crbug.com/1385136 - see comment 14 for screenshot

*Specification*
Not applicable

*Design docs*
(Google internal only, sorry): 
https://docs.google.com/document/d/1hCIzyBALzpFPuHQ_xCNvIpSrMThq8PA6Qgi0M2iF9vk/edit?resourcekey=0-VMUV90L2bb2OqlrBVepW4A#heading=h.bat9awopsp53 



*Summary*
This is a refresh of the browser UI associated with the Payment 
Handler API. There are no API changes. The origin trial is concluding 
and we'd like to ship this feature in M119. See R2E < 
https://groups.google.com/a/chromium.org/g/blink-dev/c/NQ-WLvfmPs8/m/hDKJNnmOBgAJ> 
for more details.


*Blink component*
Blink>Payments 



*TAG review*
Not applicable

*TAG review status*
Not applicable

*Risks*

*Interoperability and Compatibility*
None.

/Gecko: N/A/
/WebKit: N/A/

/Web developers: No signals/

/Other signals: No signals/


*WebView application risks*

/None/


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

No

*Debuggability*
N/A because it is a UI-only change.

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

No. Only desktop platforms - Windows, Mac, Linux, Chrome OS.

*Is this feature fully tested by web-platform-tests?*
No, because this is a UI-only change.

*Flag name*
PaymentHandlerMinimalHeaderUX

*Finch feature name*
None

*Non-finch justification*
None

*Requires code in //chrome?*
True

*Estimated milestones*
Shipping on desktop: 119

*Anticipated spec changes*
N/A, because there is no spec for a UI-only change.

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

*Links to previous Intent discussions*
Intent to Experiment: 
https://groups.google.com/a/chromium.org/g/blink-dev/c/NQ-WLvfmPs8/m/hDKJNnmOBgAJ


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/CAMMzaWEp6JQOKeYBjkhGa_w%3DQvDuEOPZu590FrDLj3%2Bg2eWQWQ%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/4c3078ba-ab44-4c54-96d9-5a9ba36a5523%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/9798b4f2-c14a-aaf9-71ec-f59a2a31232c%40gmail.com.

Re: [blink-dev] Intent to Ship: Payment handler minimal header UX

[Stephen Mcgruer]

Thanks Mike! We were following through on the I2S process because we did an
I2E for this feature as a way to let folks verify that the UX change
wouldn't cause regressions.

I still think that is correct as follow-through, but we could probably have
made it clearer than we hope this I2S will be a rubber stamp for API
owners. (Or... maybe we should have just sent a PSA? Anyhow, we are here
now).


On Wed, Sep 13, 2023, 4:46 p.m. Mike Taylor  wrote:

> LGTM1 (I'm not sure you need our approvals to ship this UX change, but you
> can have mine).
> On 9/8/23 7:09 PM, Rouslan Solomakhin wrote:
>
>
> *Contact emails *nbur...@chromium.org
>
> *Explainer*
> https://crbug.com/1385136 - see comment 14 for screenshot
>
> *Specification*
> Not applicable
>
> *Design docs*
> (Google internal only, sorry):
> https://docs.google.com/document/d/1hCIzyBALzpFPuHQ_xCNvIpSrMThq8PA6Qgi0M2iF9vk/edit?resourcekey=0-VMUV90L2bb2OqlrBVepW4A#heading=h.bat9awopsp53
>
> *Summary*
> This is a refresh of the browser UI associated with the Payment Handler
> API. There are no API changes. The origin trial is concluding and we'd like
> to ship this feature in M119. See R2E
> 
> for more details.
>
> *Blink component*
> Blink>Payments
> 
>
> *TAG review*
> Not applicable
>
> *TAG review status*
> Not applicable
>
> *Risks*
>
> *Interoperability and Compatibility*
> None.
>
> *Gecko: N/A*
> *WebKit: N/A*
>
> *Web developers: No signals*
>
> *Other signals: No signals*
>
>
> *WebView application risks*
>
> *None*
>
>
> *Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?*
> No
>
> *Debuggability*
> N/A because it is a UI-only change.
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?*
> No. Only desktop platforms - Windows, Mac, Linux, Chrome OS.
>
> *Is this feature fully tested by web-platform-tests?*
> No, because this is a UI-only change.
>
> *Flag name*
> PaymentHandlerMinimalHeaderUX
>
> *Finch feature name*
> None
>
> *Non-finch justification*
> None
>
> *Requires code in //chrome?*
> True
>
> *Estimated milestones*
> Shipping on desktop: 119
>
> *Anticipated spec changes*
> N/A, because there is no spec for a UI-only change.
>
> *Link to entry on the Chrome Platform Status*
> https://chromestatus.com/feature/5079275637571584
>
> *Links to previous Intent discussions*
> Intent to Experiment:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/NQ-WLvfmPs8/m/hDKJNnmOBgAJ
>
> 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/CAMMzaWEp6JQOKeYBjkhGa_w%3DQvDuEOPZu590FrDLj3%2Bg2eWQWQ%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/CADY3MaebhFbQuF5SF4NbzXS0Gbc3vb3SCgmc%3DE9KKKQ7VGG1Uw%40mail.gmail.com.

Re: [blink-dev] Intent to Experiment: WebAssembly JS String Builtins

['Emanuel Ziegler' via blink-dev]

Hi Daniel,

This feature has no impact without the Wasm moduled specifically compiled
for it. So we are dependent on partners implementing this and measuring the
impact. We have concrete plans with Google Sheets to run A/B trials based
on an origin trial, but hope that other partners like Kotlin or Dart would
follow soon to provide more data points.

Best regards,
Emanuel

On Wed, Sep 13, 2023 at 5:48 PM Daniel Bratell  wrote:

> Do you plan to run it as a finch experiment or do you have partners
> prepared for an Origin Trial?
>
> /Daniel
> On 2023-09-12 21:24, 'Emanuel Ziegler' via blink-dev wrote:
>
> Dear API Owners,
>
>
> Many use cases for WasmGC require calling JS functions or WebAPIs
> frequently. These calls suffer from substantial overhead when strings are
> involved due to the encoding/decoding required for changing in between the
> non-standardized Wasm module representation and the engine-internal JS
> string representation.
>
> We previously evaluated native string operations in Wasm
> 
> which would map to JS equivalents and use the same backend, eliminating the
> need for re-encoding and copies. While the performance of this approach was
> excellent (see e.g. Kotlin/Wasm's DBMonster benchmark with
>  and without
>  stringref), the Wasm Community Group
> preferred an alternative solution that uses imported JS functions
> 
> for creating and manipulating strings which could then be optimized away by
> the engine. Our experiments show a similar peak performance but slightly
> lower performance on startup as Liftoff is not capable of doing such
> optimizations effectively falling back to executing the call.
>
> We would therefore like to launch a 6-month origin trial starting in M119
> for comparing the two approaches and, if performance is good enough,
> encourage partners to switch over to the new proposal to verify its
> viability.
>
>
> Contact emails ecmzieg...@chromium.org, jkumme...@chromium.org,
> ad...@chromium.org
>
> Explainer None
>
> Specification
> https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md
>
> Summary
>
> This feature exposes common JS string operations for easy import into
> WebAssembly and optimizations thereof. This allows creating and
> manipulating JS strings from WebAssembly without native support within
> WebAssembly while still allowing for a similar performance as native string
> references. The mechanism works by exposing suitably strict versions of JS
> string operations in the WebAssembly JS API. These can be imported by
> modules using externref as a generic data type for storing the strings. The
> engine can identify that these imports can be represented by native graph
> operators without the need for calling into JS. This leads to a comparable
> peak performance as native string operations while allowing quick
> interoperability with JS since no copying at the boundary is required when
> calling into arbitrary JS functions that consume strings.
>
>
> Blink component Blink>JavaScript>WebAssembly
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive
>
> *WebKit*: No signal
>
> *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
>
>
> Goals for experimentation
>
> Ongoing technical constraints
>
> 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 None
>
> Requires code in //chrome? False
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6695587390423040
> --
> 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/CAPAU7RyzxKa0Pj6q7B_jyfT%3DH%2BSK264%3Dx8wn1ans%3D8UjHRhctQ%40mail.gmail.com
> 

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

[Madanagopal Damodharan]

An update on the issue I am facing: We have a static html in web server 
called signon.html. Users access this static html page first which has a 
refresh directive with content=1. As soon as the user invokes this html 
page first time from the origin, this redirects to a login form page. This 
response contains the header too. But still chrome console says the origin 
was in origin-keyed cluster. If I change the refresh directive content=5, 
it takes 5 sec to redirect from signon.html to login form, this time I 
don't get the console warning. Now I can login and dont see any errors. I 
am not sure why the refresh directive 5 works but not 1. Is it because 
Chrome could not capture request and place the origin in appropriate 
cluster within its 1 second?

Modified the CONTENT=5 from CONTENT=1 in the below line to get it working - 


Any thoughts?

On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal Damodharan 
wrote:

Thanks for response. In my case, I am getting the error when a new tab is 
opened from an existing tab. My existing tab did not throw this error 
whereas the new tab shows the error on the first request itself. So based 
on what you mentioned, my parent tab should have been part of Origin-Keyed 
cluster, right? I am seeing console warning as follows on my new tab that 
was opened from an existing tab:

"The page did not request an Origin-Keyed agent cluster but was put in one 
anyway because the origin had previously been placed in an origin-keyed 
agent cluster. Update your headers to uniformly request origin-keying for 
all pages on the origin"

I am currently trying to figure out which server response did not have the 
header ""Origin-Agent-Cluster: ?0" that led my pages to get in origin-keyed 
cluster. Is there a way (debug tool etc) I can check which response decided 
Origin-Keying? I think this will be crucial for applications to debug the 
issues. 

One other question: My parent tab has a wss (web socket) request that does 
not have its response with this OAC header. Do we need the header in wss 
response as well?


On Thursday, 7 September 2023 at 23:00:32 UTC+5:30 W. James MacLean wrote:

If the application is getting loaded inside a tab that has previously 
loaded other pages from the same origin (i.e. pages not part of the app) 
that do not have the header, then for consistency the new loads will get 
OAC isolation even if the header is present. Essentially, the first time 
the tab loads anything from a particular origin, that determines how it 
will treat the origin for the remainder of the tab's lifetime. This 
consistency will also extend to other tabs opened by the tab (as they live 
in the same "BrowsingInstance").

Also, there may be issues where pages can be loaded from cache without the 
?0 version of the header, so two useful steps would be

1) Clear the cache, and
2) open the app directly in a newly opened tab.

I don't think the header needs to be sent on script/css/image requests, as 
they're used within the context of the .html resource that should have the 
header.

[image: GoogleAnimated.gif]

⭘ W. James MacLean

⭘ Software Engineer

⭘ Google Waterloo 
, 
Canada



On Thu, 7 Sept 2023 at 11:27, Madanagopal Damodharan  
wrote:

Hi All, 

Is the feature launched in Chrome 115 as updated in 
https://developer.chrome.com/blog/document-domain-setter-deprecation? I 
have some of the customers reporting inconsistent behavior. Our application 
sends  "Origin-Agent-Cluster: ?0" in response headers to opt-out of Origin 
Agent clusters since we rely on document.domain. Is this header needed only 
on document requests or even for script, image, css requests? For some 
customer, their pages get inside origin-keyed cluster even though the 
responses contain the header   "Origin-Agent-Cluster: ?0". Is there a bug 
in the chrome behavior that puts pages in specific cluster? How do we debug 
what caused the pages to get inside origin-keyed cluster?

On Friday, 26 May 2023 at 20:55:52 UTC+5:30 Eiji Kitamura wrote:

@Maud Nalpas is taking over the DevRel work.

On Sat, May 27, 2023 at 12:21 AM Rick Byers  wrote:

Thanks for the update Daniel. Still LGTM. Good luck!

On Fri, May 26, 2023 at 10:25 AM Daniel Vogelheim  
wrote:

Hello all, it's been a while... The bug reports should now be resolved, and 
we'd like to have another go at this in the M115 milestone. That is: Remain 
at 50% on beta; starting with 115 ramp up on stable to 1% / 10% / 50% / 
100%, every 14d. Let's hope it sticks this time.

Daniel

On Fri, Mar 31, 2023 at 3:54 PM Daniel Vogelheim  wrote:

Hello all, I'm afraid I have to delay this a bit more. :(

We have a bug report (tracked in crbug.com/1429587) that breaks existing 
apps. The important thing here is that it does not break document.domain 
setting and subsequent cross-origin access, but that instead -- if the 
conditions are just right; or arguably just wrong -- the app can get in

Re: [blink-dev] Intent to Ship: Origin Isolation By Default / Deprecate document.domain on stable

['W. James MacLean' via blink-dev]

Perhaps try this:
1) open a new tab page (or about:blank if you prefer)
2) right-click and select "Inspect" at the bottom of the popup menu
3) in the DevTools menu at the top, click "Network"
4) then check the "Preserve Logs" checkbox in the row under that menu
5) finally, manually type the url for your app/site in the url bar

As your content loads, the DevTools window will populate with an (in order)
list of all the network transactions. You can click on each element in the
list and see the response headers for each request. This should help you
determine which request is missing the Origin-Agent-Cluster:?0 header and
causing the origin keying to be applied for the tab.

Let me know if that helps.


[image: GoogleAnimated.gif]

⭘ W. James MacLean

⭘ Software Engineer

⭘ Google Waterloo
,
Canada



On Wed, 13 Sept 2023 at 12:44, Madanagopal Damodharan <
dmadanago...@gmail.com> wrote:

> An update on the issue I am facing: We have a static html in web server
> called signon.html. Users access this static html page first which has a
> refresh directive with content=1. As soon as the user invokes this html
> page first time from the origin, this redirects to a login form page. This
> response contains the header too. But still chrome console says the origin
> was in origin-keyed cluster. If I change the refresh directive content=5,
> it takes 5 sec to redirect from signon.html to login form, this time I
> don't get the console warning. Now I can login and dont see any errors. I
> am not sure why the refresh directive 5 works but not 1. Is it because
> Chrome could not capture request and place the origin in appropriate
> cluster within its 1 second?
>
> Modified the CONTENT=5 from CONTENT=1 in the below line to get it working
> - 
>
> Any thoughts?
>
> On Sunday, 10 September 2023 at 20:53:42 UTC+5:30 Madanagopal Damodharan
> wrote:
>
> Thanks for response. In my case, I am getting the error when a new tab is
> opened from an existing tab. My existing tab did not throw this error
> whereas the new tab shows the error on the first request itself. So based
> on what you mentioned, my parent tab should have been part of Origin-Keyed
> cluster, right? I am seeing console warning as follows on my new tab that
> was opened from an existing tab:
>
> "The page did not request an Origin-Keyed agent cluster but was put in one
> anyway because the origin had previously been placed in an origin-keyed
> agent cluster. Update your headers to uniformly request origin-keying for
> all pages on the origin"
>
> I am currently trying to figure out which server response did not have the
> header ""Origin-Agent-Cluster: ?0" that led my pages to get in origin-keyed
> cluster. Is there a way (debug tool etc) I can check which response decided
> Origin-Keying? I think this will be crucial for applications to debug the
> issues.
>
> One other question: My parent tab has a wss (web socket) request that does
> not have its response with this OAC header. Do we need the header in wss
> response as well?
>
>
> On Thursday, 7 September 2023 at 23:00:32 UTC+5:30 W. James MacLean wrote:
>
> If the application is getting loaded inside a tab that has previously
> loaded other pages from the same origin (i.e. pages not part of the app)
> that do not have the header, then for consistency the new loads will get
> OAC isolation even if the header is present. Essentially, the first time
> the tab loads anything from a particular origin, that determines how it
> will treat the origin for the remainder of the tab's lifetime. This
> consistency will also extend to other tabs opened by the tab (as they live
> in the same "BrowsingInstance").
>
> Also, there may be issues where pages can be loaded from cache without the
> ?0 version of the header, so two useful steps would be
>
> 1) Clear the cache, and
> 2) open the app directly in a newly opened tab.
>
> I don't think the header needs to be sent on script/css/image requests, as
> they're used within the context of the .html resource that should have the
> header.
>
> [image: GoogleAnimated.gif]
>
> ⭘ W. James MacLean
>
> ⭘ Software Engineer
>
> ⭘ Google Waterloo
> ,
> Canada
>
>
>
> On Thu, 7 Sept 2023 at 11:27, Madanagopal Damodharan 
> wrote:
>
> Hi All,
>
> Is the feature launched in Chrome 115 as updated in
> https://developer.chrome.com/blog/document-domain-setter-deprecation? I
> have some of the customers reporting inconsistent behavior. Our application
> sends  "Origin-Agent-Cluster: ?0" in response headers to opt-out of
> Origin Agent clusters since we rely on document.domain. Is this header
> needed only on document requests or even for script, image, css requests?
> For some customer, their pages get inside origin-keyed cluster even though
> the responses contain the header   "Origin-Agent-Cluster: ?0". Is there a
> bug in the chrome behavior that 

Re: [blink-dev] Intent to Experiment: WebAssembly JS String Builtins

[Daniel Bratell]

LGTM for an origin trial M119-M124 (which I think is what you requested)

Good luck with your data collection!

/Daniel

On 2023-09-13 18:04, 'Emanuel Ziegler' via blink-dev wrote:

Hi Daniel,

This feature has no impact without the Wasm moduled specifically 
compiled for it. So we are dependent on partners implementing this and 
measuring the impact. We have concrete plans with Google Sheets to run 
A/B trials based on an origin trial, but hope that other partners like 
Kotlin or Dart would follow soon to provide more data points.


Best regards,
    Emanuel

On Wed, Sep 13, 2023 at 5:48 PM Daniel Bratell  
wrote:


Do you plan to run it as a finch experiment or do you have
partners prepared for an Origin Trial?

/Daniel

On 2023-09-12 21:24, 'Emanuel Ziegler' via blink-dev wrote:



Dear API Owners,


Many use cases for WasmGC require calling JS functions or
WebAPIs frequently. These calls suffer from substantial
overhead when strings are involved due to the
encoding/decoding required for changing in between the
non-standardized Wasm module representation and the
engine-internal JS string representation.


We previously evaluated native string operations in Wasm

which
would map to JS equivalents and use the same backend,
eliminating the need for re-encoding and copies. While
the performance of this approach was excellent (see e.g.
Kotlin/Wasm's DBMonster benchmark with
and without
stringref), the Wasm
Community Group preferred an alternative solution that
uses imported JS functions

for
creating and manipulating strings which could then be
optimized away by the engine. Our experiments show a
similar peak performance but slightly lower performance
on startup as Liftoff is not capable of doing such
optimizations effectively falling back to executing the call.


We would therefore like to launch a 6-month origin trial
starting in M119 for comparing the two approaches and, if
performance is good enough, encourage partners to switch
over to the new proposal to verify its viability.



Contact emails

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


Explainer

None


Specification


https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md


Summary

This feature exposes common JS string operations for easy import
into WebAssembly and optimizations thereof. This allows creating
and manipulating JS strings from WebAssembly without native
support within WebAssembly while still allowing for a similar
performance as native string references. The mechanism works by
exposing suitably strict versions of JS string operations in the
WebAssembly JS API. These can be imported by modules using
externref as a generic data type for storing the strings. The
engine can identify that these imports can be represented by
native graph operators without the need for calling into JS. This
leads to a comparable peak performance as native string
operations while allowing quick interoperability with JS since no
copying at the boundary is required when calling into arbitrary
JS functions that consume strings.



Blink component

Blink>JavaScript>WebAssembly




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

None



/Gecko/: Positive

/WebKit/: No signal

/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



Goals for experimentation



Ongoing technical constraints

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


 

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

[Mike Taylor]

LGTM3

On 9/13/23 5:46 PM, Daniel Bratell wrote:


LGTM2

/Daniel

On 2023-09-13 17:14, Philip Jägenstedt wrote:

LGTM1

If there is feedback on the TAG review or Mozilla issue while this 
feature is on its way to stable, can you loop back to this thread?


On Thu, Sep 7, 2023 at 4:01 PM Philip Jägenstedt 
 wrote:


Thanks for investigating and fixing the failures, Koji!

On the UA defined rules, if other vendors are happy with the
examples used, then that's what matters in practice. If you do
get pushback on specific examples I hope there are others that
can be used that are a common ground.

I think everything looks good here, but since the TAG review and
Mozilla issue were filed recently, I'd like to give those a bit
more time.

On Thu, Sep 7, 2023 at 11:14 AM Koji Ishii 
wrote:

I've got two updates on the questions:

On Thu, Sep 7, 2023 at 2:46 AM Koji Ishii
 wrote:

Good point, thanks for asking.

Technically speaking, we can't write any tests because
the language-specific content analysis is UA defined.
Tests use common and easy words that most engines would
analyze the same way, but you're right that we may need
to modify tests if any engine analyzes them differently.

Tests contain that in comments, like this


or this

.
I'm also talking to WebKit about tests, since there are
currently two known engines; one in ICU and one in
macOS/iOS. We'll work together to ensure words in tests
are common and easy enough for both engines.


In case this helps, the situation is the same as hyphenation
tests. In the past, wpt tests needed updates when one
implementation hyphenates differently from other browsers. I
remember this happened at least once before.

Four tests failing is strange, thanks for pointing them
out too, they all pass in Chromium bots. I'll check them
and make sure they're all green before shipping.


I've figured them out, all fixes landed, I'll watch when
wpt.fyi will be updated. One was a recent spec change I
wasn't aware of, three were differences between wpt bots and
chromium bots (#41851
.)

--
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/CAARdPYfPQhus6RhhrdbBuhzPQaQraqSLOhHfxAyQ5eMgoy1sOA%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/ce7a4dba-0160-427b-905c-ad537021da2d%40chromium.org.

Re: [blink-dev] Intent to Ship: Japanese Phrase Line Breaking

[Koji Ishii]

On Thu, Sep 14, 2023 at 12:14 AM Philip Jägenstedt 
wrote:

> If there is feedback on the TAG review or Mozilla issue while this feature
> is on its way to stable, can you loop back to this thread?
>

Yes, I will. Thank you all.

>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHe_1dJHBoArmcxLAtJDQnWYPD-sDdvvCuv2cy3dpbyoDow2ug%40mail.gmail.com.