Re: [blink-dev] Intent to Continue Experimenting: Tabbed Web Apps

[Domenic Denicola]

LGTM to extend. The recent spec progress looks significant, and other areas
are in good shape.

On Wed, Mar 13, 2024 at 11:36 AM Matt Giuca  wrote:

> The original trial was from 118 to 123, inclusive.
>
> We want to extend it so it continues running from 124 to 126, inclusive.
>
> On Fri, 8 Mar 2024 at 16:52, Domenic Denicola 
> wrote:
>
>> For what milestones do you want to extend the experiment for?
>>
>> On Thu, Mar 7, 2024 at 3:39 PM Matt Giuca  wrote:
>>
>>> Contact emailsloubr...@google.com, glen...@chromium.org
>>> , mgi...@chromium.org, bre...@chromium.org
>>>
>>> Explainer
>>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>>
>>> Specificationhttps://github.com/WICG/manifest-incubations/pull/95
>>>  (draft)
>>>
>>> Summary
>>>
>>> Allow web app windows to have a tab strip. This adds a new display mode
>>> "tabbed" and a new manifest field to allow customizations to the tab strip.
>>>
>>> Following a 6-milestone origin trial, we would like to continue
>>> experimenting as the feature team is not ready to commit to shipping, and
>>> gathered very little data from the initial experiment (as partners we have
>>> lined up have not yet started their experiment).
>>>
>>> Per the Blink policy, we have made substantial progress in these five
>>> areas:
>>>
>>>- Draft spec: https://github.com/WICG/manifest-incubations/pull/95
>>>- TAG review: https://github.com/w3ctag/design-reviews/issues/841
>>>(closed with "unsatisfied"; I have sent a follow-up comment).
>>>- Signals requests:
>>>   - WebKit: https://github.com/WebKit/standards-positions/issues/195
>>>   (ignored)
>>>   - Mozilla:
>>>   https://github.com/mozilla/standards-positions/issues/811 (closed
>>>   as not interested in any of "these sorts of features")
>>>- Outreach for feedback from spec community:
>>>https://developer.chrome.com/docs/capabilities/tabbed-application-mode
>>>- WPT tests:
>>>
>>> https://github.com/web-platform-tests/wpt/blob/master/appmanifest/display-override-member/display-override-member-media-feature-tabbed-manual.tentative.html
>>>
>>> Blink componentBlink>AppManifest
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>>
>>> TAG review statusClosed ("Unsatisfied")
>>>
>>> Chromium Trial NameWebAppTabStrip
>>>
>>> Origin trial feedback summary
>>> Only a small number of signups, most look like individuals wanting to
>>> experiment. A handful of small PWAs are using it. A few large sites signed
>>> up for the trial but do not appear to be using it.
>>>
>>> That said, we think this is a useful feature and want to keep exploring
>>> possible customers of the API.
>>>
>>> I was unable to see any qualitative feedback from registrants.
>>>
>>> Origin Trial documentation link
>>> https://developer.chrome.com/docs/capabilities/tabbed-application-mode
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: Defer (
>>> https://github.com/mozilla/standards-positions/issues/811)
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/195)
>>>
>>> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737)
>>>
>>> *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?
>>>
>>> N/A
>>>
>>>
>>>
>>> Goals for experimentation
>>>
>>> Roll out one major client and get developer and user feedback.
>>>
>>> Ongoing technical constraints
>>>
>>> Reuses browser tab strip code, adding further dependency between the
>>> browser tab strip and PWA windows.
>>>
>>> Debuggability
>>>
>>> chrome://web-app-internals can be used for debugging, and the new
>>> manifest field could also be added to the DevTools Application pane.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?No
>>>
>>> The origin trial is available on ChromeOS only. Support for other
>>> desktop platforms is planned but low priority.
>>>
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?Partial (more coming)
>>>
>>> Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip
>>>
>>> Finch feature name
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?True
>>>
>>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=897314
>>>
>>> Launch bughttps://launch.corp.google.com/launch/4253814
>>>
>>> Estimated milestones
>>> OriginTrial desktop last 126
>>> OriginTrial desktop first 118
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5128143454076928
>>>
>>> Links to previous Intent discussionsIntent to pro

Re: [blink-dev] Intent to Continue Experimenting: Tabbed Web Apps

[Matt Giuca]

The original trial was from 118 to 123, inclusive.

We want to extend it so it continues running from 124 to 126, inclusive.

On Fri, 8 Mar 2024 at 16:52, Domenic Denicola  wrote:

> For what milestones do you want to extend the experiment for?
>
> On Thu, Mar 7, 2024 at 3:39 PM Matt Giuca  wrote:
>
>> Contact emailsloubr...@google.com, glen...@chromium.org
>> , mgi...@chromium.org, bre...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Specificationhttps://github.com/WICG/manifest-incubations/pull/95 (draft)
>>
>> Summary
>>
>> Allow web app windows to have a tab strip. This adds a new display mode
>> "tabbed" and a new manifest field to allow customizations to the tab strip.
>>
>> Following a 6-milestone origin trial, we would like to continue
>> experimenting as the feature team is not ready to commit to shipping, and
>> gathered very little data from the initial experiment (as partners we have
>> lined up have not yet started their experiment).
>>
>> Per the Blink policy, we have made substantial progress in these five
>> areas:
>>
>>- Draft spec: https://github.com/WICG/manifest-incubations/pull/95
>>- TAG review: https://github.com/w3ctag/design-reviews/issues/841
>>(closed with "unsatisfied"; I have sent a follow-up comment).
>>- Signals requests:
>>   - WebKit: https://github.com/WebKit/standards-positions/issues/195
>>   (ignored)
>>   - Mozilla:
>>   https://github.com/mozilla/standards-positions/issues/811 (closed
>>   as not interested in any of "these sorts of features")
>>- Outreach for feedback from spec community:
>>https://developer.chrome.com/docs/capabilities/tabbed-application-mode
>>- WPT tests:
>>
>> https://github.com/web-platform-tests/wpt/blob/master/appmanifest/display-override-member/display-override-member-media-feature-tabbed-manual.tentative.html
>>
>> Blink componentBlink>AppManifest
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>
>> TAG review statusClosed ("Unsatisfied")
>>
>> Chromium Trial NameWebAppTabStrip
>>
>> Origin trial feedback summary
>> Only a small number of signups, most look like individuals wanting to
>> experiment. A handful of small PWAs are using it. A few large sites signed
>> up for the trial but do not appear to be using it.
>>
>> That said, we think this is a useful feature and want to keep exploring
>> possible customers of the API.
>>
>> I was unable to see any qualitative feedback from registrants.
>>
>> Origin Trial documentation link
>> https://developer.chrome.com/docs/capabilities/tabbed-application-mode
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: Defer (https://github.com/mozilla/standards-positions/issues/811
>> )
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/195)
>>
>> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737)
>>
>> *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?
>>
>> N/A
>>
>>
>>
>> Goals for experimentation
>>
>> Roll out one major client and get developer and user feedback.
>>
>> Ongoing technical constraints
>>
>> Reuses browser tab strip code, adding further dependency between the
>> browser tab strip and PWA windows.
>>
>> Debuggability
>>
>> chrome://web-app-internals can be used for debugging, and the new
>> manifest field could also be added to the DevTools Application pane.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?No
>>
>> The origin trial is available on ChromeOS only. Support for other desktop
>> platforms is planned but low priority.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?Partial (more coming)
>>
>> Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip
>>
>> Finch feature name
>>
>> Non-finch justificationNone
>>
>> Requires code in //chrome?True
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=897314
>>
>> Launch bughttps://launch.corp.google.com/launch/4253814
>>
>> Estimated milestones
>> OriginTrial desktop last 126
>> OriginTrial desktop first 118
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5128143454076928
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/IvfIkjvQYuY/m/cixwOyEeAAAJ
>> Intent to Experiment:
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/m16m2TEq-NM/m/0Bc10numCgAJ
>>
>>
>> This intent message was generated by Chrome Platform Status
>> 

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Domenic Denicola]

Can you fill out the interoperability and compatibility risks section here?
I don't think standards position requests are necessary, but saying how
this behavior might break existing sites that assume Chromium's current
behavior, and how this new behavior compares to WebKit and Gecko, would be
helpful.

Also, can you request the privacy/security/enterprise/debuggability/testing
gates on Chrome Status?

On Tue, Mar 12, 2024 at 10:12 PM Zheda Chen  wrote:

> Okay I update the process stage in Chrome Platform Status, and paste the
> newly-generated Intent above. Please take a look.
>
> https://chromestatus.com/feature/5106220399853568
>
> On Tuesday, March 12, 2024 at 8:57:59 PM UTC+8 Zheda Chen wrote:
>
>> *Intent to Ship: Add JavaScript timer wake up alignment for unimportant
>> cross-origin frames*
>>
>> Contact emails
>> zheda...@intel.com, fdo...@chromium.org
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>
>> Summary
>>
>> Align wake ups of JavaScript timers for unimportant cross-origin frames.
>> Currently, DOM timers <32ms are all opt-out from AlignWakeUps [1] due to
>> performance concerns. This is very conservative and actually some
>> unimportant frames are eligible to use JS timer alignment. WebKit uses the
>> policy to align DOM timer of non-interacted cross origin frames to 30ms.
>> This feature adds JavaScript timer wake up alignment for unimportant frames
>> on foreground pages. Unimportant frames means they are cross origin,
>> visible but have non-large proportion of page’s visible area, and have no
>> user interaction. [1]
>> https://chromium-review.googlesource.com/c/chromium/src/+/4589092
>>
>>
>> Blink component
>> Blink>PerformanceAPIs>Timers
>> 
>>
>> TAG review
>> None
>>
>> TAG review status
>> Not applicable
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> None
>>
>> *Gecko*: No signal
>>
>> *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
>>
>> Debuggability
>>
>> None
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>> Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>> No
>>
>> Flag name on chrome://flags
>> None
>>
>> Finch feature name
>> ThrottleUnimportantFrameTimers
>>
>> Requires code in //chrome?
>> False
>>
>> Tracking bug
>> https://issues.chromium.org/issues/40942028
>>
>> Estimated milestones
>>
>> Shipping on desktop
>> 123
>> DevTrial on desktop
>> 121
>> Shipping on Android
>> 123
>> DevTrial on Android
>> 121
>>
>> 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/5106220399853568
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> On Thursday, March 7, 2024 at 12:15:41 PM UTC+8 dom...@chromium.org
>> wrote:
>>
>>> Switching to an Intent to Ship sounds good. Can you update the process
>>> stage in the ChromeStatus tool, fill out any necessary fields that differ
>>> between the stages, and either start a new thread, or paste the
>>> newly-generated Intent here?
>>>
>>> On Thu, Mar 7, 2024 at 2:48 AM Etienne Pierre-doray 
>>> wrote:
>>>
 I'm working with Zheda and Francois to get this feature out, chiming in

 In general, I think it's best to file a formal Intent to Ship if you
> want to go to 50% stable.
>
 I agree, I'd consider this feature ready to ship, we have enough
 confidence from previous stable experiments to roll it out.
 The main reason for doing a 50/50 experiment first is to more
 accurately measure impact on CWV.
 There aren't clear guidelines from finch otherwise on the exact % when
 ramping up from 1% to 100%, or when intermediate steps are needed at all;
 our team has been following a 1/50/100 pattern (we received feedback for
 other features that fewer intermediate steps was desirable for web devs).
 For blink purpose, I'd suggest we switch this to an 'Intent to ship'.

 On Mon, Mar 4, 2024 at 5:06 PM Domenic Denicola 
 wrote:

> In general, I think it's best to file a formal Intent to Ship if you
> want to go to 50% stable. To me it sounds like t

Re: [blink-dev] Intent to Ship: 'pageswap' event

[Domenic Denicola]

Assuming that change gets appropriate spec updates and web platform tests
coverage, that should be no problem. Thanks to you and the security team
for looking out for our users!

On Wed, Mar 13, 2024 at 7:26 AM 'Khushal Sagar' via blink-dev <
blink-dev@chromium.org> wrote:

> Hey folks,
>
> There's a minor change to the semantics of this event based on security
> feedback: https://github.com/whatwg/html/issues/10196. Originally we
> provided the activation info if the navigation is same-origin. The proposed
> change is to limit it further to same-origin navigations with no
> cross-origin redirects. I'll wait for this issue to be resolved before
> shipping the feature.
>
> Let me know if another review is needed for the proposed change or this
> intent is still good to go.
>
> Thanks.
> Khushal
>
> On Wed, Mar 6, 2024 at 11:27 AM Chris Harrelson 
> wrote:
>
>> LGTM3
>>
>> On Wed, Mar 6, 2024 at 8:21 AM Daniel Bratell 
>> wrote:
>>
>>> LGTM2
>>>
>>> /Daniel
>>> On 2024-03-06 16:58, 'Khushal Sagar' via blink-dev wrote:
>>>
>>>
>>>
>>> On Wed, Mar 6, 2024 at 6:32 AM Manuel Rego Casasnovas 
>>> wrote:
>>>
 What's going on with the tests?


 https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pageswap?label=master&label=experimental&product=chrome&product=firefox&product=safari
>>>
>>>
>>> The code to dispatch this event is partly in the browser process, so
>>> turning on experimental web features doesn't enable the flag there. We have
>>> a virtual tests suite
>>> 
>>>  to
>>> run the test on the bots, won't be necessary once we switch runtime feature
>>> status to stable.
>>>
>>>


 Thanks,
Rego

 On 06/03/2024 11:57, Yoav Weiss (@Shopify) wrote:
 > LGTM1
 >
 > On Wed, Mar 6, 2024 at 11:54 AM Noam Rosenthal <
 nrosent...@chromium.org
 > > wrote:
 >
 >
 >
 > Summary
 >
 > The `pageswap` event is fired on a Document's window
 > object when a navigation will replace this Document
 with
 > a new Document. The event provides activation info
 about
 > the navigation (type, NavigationHistoryEntry for the
 new
 > Document). If the navigation has a cross-document
 > ViewTransition, the event is dispatched before
 capturing
 > state for the old Document. This allows the
 page-author
 > to configure the old state captured for the transition
 > based on the navigation's activation info and the
 > current visual state of the old Document. This feature
 > is split out from the larger
 > ViewTransition-on-Navigation project.
 >
 >
 > Why is it split out? Is there some utility for this regardless
 > of view transitions?
 >
 > Absolutely! For example it's a place where you can figure out that
 > you're navigating away to a different same-origin document (after
 > redirects), and act on it in some way, e.g. put something in
 > `sessionStorage` like a video playback position.
 > It's different from `pagehide` in that sense, because with
 > `pagehide` you don't know you're going to a new document.
 >
 > Also by having a generic event with an optional viewTransition
 > property, it can tell the author that a view transition *didn't*
 > take place, which we can't do with a view-transition event.
 >
 > The design for this (as for `pagerveal`) started from
 > view-transition-specific events and ended up gravitating towards
 > this kind of event with an optional attribute for this reason, and
 > also to avoid a situation where people create fake view
 transitions
 > for the purpose of getting these events.
 >
 >
 > Makes sense!
 >
 >
 > Blink component
 >
 > Blink>ViewTransitions
 > <
 https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EViewTransitions
 >
 >
 >
 > TAG review
 >
 >
 https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258
 <
 https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258
 >
 >
 >
 > TAG review status
 >
 > Pending
 >
 >
 > Risks
 >
 >
 > Interoperability and Compatibility
 >
 > None
 >
 >
 > /G

Re: [blink-dev] Intent to Ship: 'pageswap' event

['Khushal Sagar' via blink-dev]

Hey folks,

There's a minor change to the semantics of this event based on security
feedback: https://github.com/whatwg/html/issues/10196. Originally we
provided the activation info if the navigation is same-origin. The proposed
change is to limit it further to same-origin navigations with no
cross-origin redirects. I'll wait for this issue to be resolved before
shipping the feature.

Let me know if another review is needed for the proposed change or this
intent is still good to go.

Thanks.
Khushal

On Wed, Mar 6, 2024 at 11:27 AM Chris Harrelson 
wrote:

> LGTM3
>
> On Wed, Mar 6, 2024 at 8:21 AM Daniel Bratell  wrote:
>
>> LGTM2
>>
>> /Daniel
>> On 2024-03-06 16:58, 'Khushal Sagar' via blink-dev wrote:
>>
>>
>>
>> On Wed, Mar 6, 2024 at 6:32 AM Manuel Rego Casasnovas 
>> wrote:
>>
>>> What's going on with the tests?
>>>
>>>
>>> https://wpt.fyi/results/html/browsers/browsing-the-web/history-traversal/pageswap?label=master&label=experimental&product=chrome&product=firefox&product=safari
>>
>>
>> The code to dispatch this event is partly in the browser process, so
>> turning on experimental web features doesn't enable the flag there. We have
>> a virtual tests suite
>> 
>>  to
>> run the test on the bots, won't be necessary once we switch runtime feature
>> status to stable.
>>
>>
>>>
>>>
>>> Thanks,
>>>Rego
>>>
>>> On 06/03/2024 11:57, Yoav Weiss (@Shopify) wrote:
>>> > LGTM1
>>> >
>>> > On Wed, Mar 6, 2024 at 11:54 AM Noam Rosenthal <
>>> nrosent...@chromium.org
>>> > > wrote:
>>> >
>>> >
>>> >
>>> > Summary
>>> >
>>> > The `pageswap` event is fired on a Document's window
>>> > object when a navigation will replace this Document
>>> with
>>> > a new Document. The event provides activation info
>>> about
>>> > the navigation (type, NavigationHistoryEntry for the
>>> new
>>> > Document). If the navigation has a cross-document
>>> > ViewTransition, the event is dispatched before
>>> capturing
>>> > state for the old Document. This allows the page-author
>>> > to configure the old state captured for the transition
>>> > based on the navigation's activation info and the
>>> > current visual state of the old Document. This feature
>>> > is split out from the larger
>>> > ViewTransition-on-Navigation project.
>>> >
>>> >
>>> > Why is it split out? Is there some utility for this regardless
>>> > of view transitions?
>>> >
>>> > Absolutely! For example it's a place where you can figure out that
>>> > you're navigating away to a different same-origin document (after
>>> > redirects), and act on it in some way, e.g. put something in
>>> > `sessionStorage` like a video playback position.
>>> > It's different from `pagehide` in that sense, because with
>>> > `pagehide` you don't know you're going to a new document.
>>> >
>>> > Also by having a generic event with an optional viewTransition
>>> > property, it can tell the author that a view transition *didn't*
>>> > take place, which we can't do with a view-transition event.
>>> >
>>> > The design for this (as for `pagerveal`) started from
>>> > view-transition-specific events and ended up gravitating towards
>>> > this kind of event with an optional attribute for this reason, and
>>> > also to avoid a situation where people create fake view transitions
>>> > for the purpose of getting these events.
>>> >
>>> >
>>> > Makes sense!
>>> >
>>> >
>>> > Blink component
>>> >
>>> > Blink>ViewTransitions
>>> > <
>>> https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EViewTransitions
>>> >
>>> >
>>> >
>>> > TAG review
>>> >
>>> >
>>> https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258
>>> <
>>> https://github.com/w3ctag/design-reviews/issues/851#issuecomment-1924730258
>>> >
>>> >
>>> >
>>> > TAG review status
>>> >
>>> > Pending
>>> >
>>> >
>>> > Risks
>>> >
>>> >
>>> > Interoperability and Compatibility
>>> >
>>> > None
>>> >
>>> >
>>> > /Gecko/: Positive
>>> > (
>>> https://github.com/mozilla/standards-positions/issues/969 <
>>> https://github.com/mozilla/standards-positions/issues/969>)
>>> >
>>> >
>>> > Is that the right position?
>>> >
>>> > Yes, the name was changed while iterating, but it's the same
>>> feature
>>> > and Gecko folks took active part in the design and reviews.
>>> >
>>> >
>>> > Ooh, got it!
>>> >
>>> > --
>>> > You 

Re: [blink-dev] Intent to Ship: Interoperable mousemove default action

[Yoav Weiss (@Shopify)]

LGTM2

On Tue, Mar 12, 2024, 13:03 Chris Harrelson  wrote:

> Sounds good to me! LGTM1
>
> On Tue, Mar 12, 2024 at 9:53 AM Mustaq Ahmed  wrote:
>
>> Hi API Owners:
>>
>> We concluded this feature is safe to ship after investigating the few sites
>> that are affecting our use-counter:
>> - None of UKM reported sites show any usability problem in our
>> investigation.
>> - On one of those sites, a mouse drag over menu items starts text
>> selection (w/o affecting usability).  The site shows the same problem with
>> Firefox and Safari; and even on Chrome Stable (w/o the feature) but for
>> certain menu-item drags.
>> - The UKM usage percentages for those sites add up to match the ~0.12%
>> usage shown by our use-counter.  So no sites affecting our use-counter
>> seem to have been left out by UKM.
>>
>> In case this is still needed, we are rolling out the 1% Stable experiment
>> that we promised on Jan 17.
>>
>> Mustaq
>>
>>
>> On Wed, Mar 6, 2024 at 10:06 AM Mustaq Ahmed  wrote:
>>
>>> No, issue 327409885 is related to the PSA on canceling mousedown in
>>> iframe
>>> 
>>> .
>>>
>>>
>>> On Wed, Mar 6, 2024 at 5:25 AM Yoav Weiss (@Shopify) <
>>> yoavwe...@chromium.org> wrote:
>>>
 Is https://issues.chromium.org/issues/327409885 related here?

 On Mon, Mar 4, 2024 at 6:09 PM Mustaq Ahmed 
 wrote:

> UKM data shows that only a few popular sites are affecting our
> use-counters.  We already confirmed that one of those sites is not broken
> at all, only showing text selection on menu items.  We are expecting to
> conclude soon after investigating all those sites.
>
> On Wed, Jan 17, 2024 at 1:48 PM Mustaq Ahmed 
> wrote:
>
>> A quick update: our use-counter on Chrome 122 Canary/Dev came out
>> higher than we expected---it is suggesting that at most 0.11% page loads
>> are affected.
>>
>> We will expand the finch trail to 50% Beta plus 1% Stable now to get
>> more data, and then look into other directions like adding UKM or fine
>> tuning the use-counter.
>>
>>
>> On Thu, Dec 7, 2023 at 10:14 AM Rick Byers 
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 6, 2023 at 5:08 PM Mustaq Ahmed 
>>> wrote:
>>>
 > I assume cancelling the mousedown (but not the mousemove) still
 prevents selection and drag-and-drop in all browsers, is that right? 
 That's
 the pattern I'd expect is most common. Also, what's the behavior of
 pointermove for mice today and after this change?

 I just confirmed 
 that Chrome (and Firefox and Safari too) already prevents both 
 selection
 and drag-and-drop when mousedown or pointerdown is cancelled.  So sites
 canceling all the mouse events will work fine.

>>>
>>> Great, thanks! That definitely lowers my concern.
>>>
>>> > We have landed a metric which specifically checks for cases where
 the mousemove is preventDefaulted but a selection starts (i.e. 
 selectstart
 wasn't prevented, there was no user-select: none, and so the selection 
 does
 change). Right now this is a UMA but we could also add UKM and get 
 sites
 from this. Mustaq WDYT about adding UKM for this and running the
 1% finch trial?

 Adding UKM and running a 1% finch trial sounds good.

 Perhaps we can run a Canary/Dev/Beta trial even now (on M121)?

>>>
>>> Yep, you can do whatever you want for canary/dev and you have API
>>> owner approval for Beta and Stable up to 1% if you want it. Perhaps beta
>>> data alone would be compelling enough for API owners to approve this 
>>> (with
>>> an understanding, like always, that we'd kill-switch it on reports of
>>> non-trivial stable breakage).
>>>
>>> On Wed, Dec 6, 2023 at 12:34 PM Robert Flack 
 wrote:

> On Wed, Dec 6, 2023 at 12:18 PM Rick Byers 
> wrote:
>
>> API owners met and discussed this one briefly today. There was
>> agreement that more work needs to be done to demonstrate the compat 
>> risk is
>> low enough to ship this breaking change. A few points:
>>
>>- If you'd like to do a finch trial to gather data (up to
>>stable 1%) we're supportive of that.
>>- Mike Taylor argued that you're not likely to learn too much
>>useful from a finch trial since people seem not to report bugs 
>> for things
>>that fail for a seemingly random 1% of their users, and perhaps 
>> the idea of
>>surveying a few sites would be more effective at finding real 
>> breakage. Of
>>course UKM + Finch might be a good way to find URLs to te

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

[Yoav Weiss (@Shopify)]

LGTM1

On Tue, Mar 12, 2024, 15:10 'François Beaufort' via blink-dev <
blink-dev@chromium.org> wrote:

>
>
> On Tue, Mar 12, 2024 at 6:58 PM Mike Taylor 
> wrote:
>
>> On 3/11/24 4:06 PM, 'François Beaufort' via blink-dev wrote:
>>
>> Contact emails fbeauf...@google.com
>>
>> Explainer None
>>
>> Could you write a few sentences why this is a useful addition?
>>
>
> Service Workers enable offline capabilities and background processing for
> WebGPU. This means graphics-intensive web applications or Chrome Extensions
> can cache resources and perform computations even when the user isn't
> actively interacting with the page.
> Shared Workers allow multiple tabs or extension contexts to coordinate and
> share WebGPU resources. This leads to smoother performance and more
> efficient use of the user's graphics hardware.
>
>>
>> Specification https://gpuweb.github.io/gpuweb/#navigator-gpu
>>
>> Summary
>>
>> Functionality added to the WebGPU spec after its first shipment in a
>> browser. ServiceWorker and SharedWorker support is added to WebGPU,
>> aligning with existing WebGL capabilities.
>>
>> Blink component Blink>WebGPU
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> ServiceWorker and SharedWorker support have not yet been implemented in
>> any browser, but have been approved by the GPU for the Web Community Group,
>> with representatives from Chrome, Firefox, and Safari. See minutes at
>> https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/971)
>>
>> Not officially a positive signal, but looking positive based on the
>> comments.
>>
>
> Indeed.
>
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933
>> )
>>
>> This is kind of an "N/A to positive", given it's WebGPU.
>>
>
> Agree ;)
>
>>
>> *Web developers*: Positive (https://github.com/gpuweb/gpuweb/issues/4197)
>>
>> *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, ChromeOS, Android, and Android WebView)? No
>> All platforms will eventually have support. Will immediately be available
>> on Android, ChromeOS, Mac, and Windows, since those platforms already
>> support WebGPU. Linux is planned to have WebGPU support in the future, so
>> this feature will become available when WebGPU does.
>>
>> What about WebView? Do we ship support for WebGPU there?
>>
>
> Yes. WebGPU is supported on Android WebView as well.
>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ? Yes
>>
>> WebGPU/WGSL have a conformance test suite (https://github.com/gpuweb/cts)
>> that is regularly pulled into Chromium and part of the testing of Dawn/Tint
>> in Chromium. PRs: https://github.com/gpuweb/cts/pull/3419 -
>> https://github.com/gpuweb/cts/pull/3345
>>
>>
>> Flag name on chrome://flags None
>>
>> Finch feature name WebGPUExperimentalFeatures
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1521763
>>
>> Estimated milestones
>> Shipping on desktop 124
>> Shipping on Android 124
>>
>> 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/4875951026733056
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2BewUL-PTEQ_ZQgdtViKU2fSVXeDNab2oEy6RsGqkgcGQ%40mail.gmail.com
>>
>> 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/CAPpwU5Lo3k-Gynt4M%2BwgV3yfg%2BFvM1npij%2BGTNZLW-VZHojXYA%40mail.gmail.com
>> 

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

['Aaron Selya' via blink-dev]

>
> The first mitigation listed here is to migrate existing
> partitioned cookies to include the new bit, and the second mitigation is to
> have a flag that can disable this feature. Would disabling the feature also
> include migrating the existing cookies back to exclude the new bit?
>

Disabling the flag would not migrate the existing cookies back to exclude
the new bit. It would make it so that the new bit value is not considered
when checking equivalence. Not considering the value of the bit when is the
current behavior so we anticipate no issues ignoring the bit if the flag
needs to disable the feature.


> And somewhat related, but does the format of the cookie request developers
> make have to change too, or is this bit determination purely done within
> the browser?
>

In almost all cases this is set within the browser. The only circumstance
I've run into where the value could be set by a developer is with the chrome
.cookies.set api for extensions.  This API allows the developer to set the
site associated with the cookie partition key and with this change would
allow for the bit value to be set as well.

On Tue, Mar 12, 2024 at 2:53 PM Vladimir Levin  wrote:

>
>
> On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya  wrote:
>
>> Contact emails
>>
>> se...@chromium.org, dylancut...@chromium.org, kaustub...@chromium.org
>>
>>
>> Explainer
>>
>> Keying of "CHIPS" cookies should align with other state:
>> 
>>
>>
>> Specification
>>
>> Add cross-site ancestor chain bit to spec:
>> https://github.com/explainers-by-googlers/CHIPS-spec/pull/13
>>
>>
>>
>> Summary
>>
>> We are looking to align the partition key
>> 
>> in CHIPS (Cookies Having Independent Partitioned State, aka partitioned
>> cookies) with the existing implementation of StorageKey.
>>
>>
>> The only sites that would experience different behavior, would be when a
>> top-level site “A” embeds an iframe to a cross-site document on site “B”,
>> and then the iframe B embeds an iframe that loads a document from site “A”
>> (shorthand: A1->B->A2). Previously, partitioned cookies sent or received in
>> the inner iframe A2 would be the same partitioned cookies sent or received
>> in the outer frame A1. This is no longer true.
>>
>>
>> This change is privacy neutral, but will have improved security
>> characteristics, because it prevents cross-site iframes from embedding
>> arbitrary endpoints of the top-level site with credentials, without first
>> being granted permission to do so through the Storage Access API (SAA) or
>> Cross-Origin Resource Sharing (CORS).
>>
>>
>>
>> The impact of this change is expected to be small as our metrics indicate
>> that only 0.2% of CHIPS (partitioned cookies) set by the first party are
>> currently being used in A1->B->A2 contexts. This constitutes 0.032% of all
>> page loads (calculated using the usage of PartitionedCookie
>> ).
>> For websites that do need access to the same cookies across A1 and A2 (in
>> the A1->B->A2 configuration), we recommend using SameSite=None cookies
>> *without* the Partitioned attribute, and invoking the Storage Access API
>> (SAA) or using the Cross-Origin Resource Sharing (CORS).
>>
>>
>>
>> Blink component
>>
>> Internals>Network>Cookies>PartitionedCookies
>> 
>>
>>
>>
>>
>> TAG review
>>
>> Not requested, as this does not differ in any significant way from the
>> original CHIPS design that was already reviewed by TAG
>> .
>>
>>
>> TAG review status
>>
>> N/A
>>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> The inclusion of a new element in the partition key will mean that
>> partitioned cookies (CHIPS) created after the launch of this change will
>> not be compatible with the partitioned cookies that already exist in users
>> cookie jars. To address this, existing partitioned cookies will be migrated
>> (without any need for developer action) to include the new cross-site
>> ancestor chain bit value, which will be set with a value of true if the
>> existing partition key does not match the host key (indicating a cross site
>> ancestor is present) and false if the partition key does match the host
>> key. This will ensure that most existing CHIPS have the same scope as they
>> did prior to the change.
>>
>>
>> Only 0.2% of partitioned cookies are utilized from within A1->B->A2
>> scenarios, but developers who need to be able to access cookies in
>> A1->B->A2 scenarios wi

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint

[Nicolás Peña]

Regarding risk: we are going to implement this and test the IDPs we know 
are currently using FedCM, but we do not anticipate them to break since 
they are currently already relying on using third-party cookies in iframes. 
We also plan to have developer outreach/blogpost for this change so 
developers currently testing out FedCM are not caught by surprise.

Regarding vendor alignment: we have been working with Firefox and Apple to 
align on the correct behavior of the FedCM fetches: see 
https://github.com/fedidcg/FedCM/issues/320 and 
https://github.com/fedidcg/FedCM/issues/428. This I2S is a result of a lot 
of discussions, and the small addition was a result of a very recent 
discussion occurring on our FedCM CORS breakout session 

.

Regarding spec, during our breakout Anne also mentioned that the small 
addition is not possible to specify properly, as it depends on the ongoing 
cookie layering work. I will add a note 
 on the spec in that fetch so 
IDPs know which cookies should be sent.

Anyways, I understand it is a bit late to add something to this I2S so if 
you prefer that we send a separate I2S/PSA for the SameSite change, we can 
do that instead.

On Tuesday, March 12, 2024 at 1:34:56 PM UTC-4 Mike Taylor wrote:

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:

Thanks for the suggestion, Yoav! It seems something fetch experts have some 
concerns about, so we do not plan to proceed with that suggestion at the 
moment.

I'd like to append a small addition to this I2S (mainly to avoid having an 
additional PSA since it is very related to this one): we would also like 
approval to only send Same-Site=None cookies in the accounts endpoint, 
instead of all cookies (so not Same-Site=Lax or Same-Site=Strict). This is 
also a breaking change but we do not anticipate IDPs to break, and also 
plan to work with them to ensure that they are aware of this change and are 
not caught by surprise.

To my non-FedCM expert brain, this doesn't feel like a small addition 
(happy to be wrong!), beyond not understanding the scale of the risk, the 
normal process questions come to mind i.e., is it specced, do we have 
tests, what do other vendors think about it?


On Monday, March 11, 2024 at 6:39:14 AM UTC-4 Yoav Weiss wrote:


I left a comment 
 around 
potentially adding a CORS mode that would help IDP servers statically 
protect themselves from destination-change attacks. I don't *think* it's a 
blocker, but it's worth considering something along those lines to increase 
the solution's robustness to configuration errors, and ensure it fails 
closed. (and ask IDPs' security teams about their thoughts)

On Wed, Mar 6, 2024 at 5:51 PM Nicolás Peña  wrote:

No, Sec-Fetch-Dest 
 
is not changing. Sec-Fetch-Mode 
 
is.

On Wednesday, March 6, 2024 at 11:31:35 AM UTC-5 Chris Harrelson wrote:

On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña  wrote:



On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav Weiss wrote:

On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss (@Shopify)  
wrote:



On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor  wrote:

LGTM1
On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails 

n...@chromium.org

Explainer 

https://github.com/fedidcg/FedCM/issues/428 


A few lines summarizing this issue would be most useful when evaluating 
this and understanding what y'all want to ship.
In particular, it'd be useful to understand the request flow, what is the 
request's origin (as IIUC, we're talking about requests issued from the 
browser), and what is the request destination that we may want IDPs to 
check.

Examples of the checks IDPs would have to make would also be helpful.


Sure! From the spec 
, here is a 
sample request:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true
 
With this change, Sec-Fetch-Mode will now be cors in this request and the 
IDP is expected to return the following in the response (no preflight is 
performed):


Do you mean Sec-Fetch-Dest?
 


Access-Control-Allow-Origin: https://rp.example/
Access-Control-Allow-Credentials: true
 


Also, is the "identity assertion" endpoint the same as the token endpoint 
?


Yea. I think that explainer doc is not super up to date.
 


Specification 

https://github.com/fedidcg/FedCM/pull/547 

Summary 

The fetches in the FedCM API are hard to reason about because of the 
propertie

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

['François Beaufort' via blink-dev]

On Tue, Mar 12, 2024 at 6:58 PM Mike Taylor  wrote:

> On 3/11/24 4:06 PM, 'François Beaufort' via blink-dev wrote:
>
> Contact emails fbeauf...@google.com
>
> Explainer None
>
> Could you write a few sentences why this is a useful addition?
>

Service Workers enable offline capabilities and background processing for
WebGPU. This means graphics-intensive web applications or Chrome Extensions
can cache resources and perform computations even when the user isn't
actively interacting with the page.
Shared Workers allow multiple tabs or extension contexts to coordinate and
share WebGPU resources. This leads to smoother performance and more
efficient use of the user's graphics hardware.

>
> Specification https://gpuweb.github.io/gpuweb/#navigator-gpu
>
> Summary
>
> Functionality added to the WebGPU spec after its first shipment in a
> browser. ServiceWorker and SharedWorker support is added to WebGPU,
> aligning with existing WebGL capabilities.
>
> Blink component Blink>WebGPU
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> ServiceWorker and SharedWorker support have not yet been implemented in
> any browser, but have been approved by the GPU for the Web Community Group,
> with representatives from Chrome, Firefox, and Safari. See minutes at
> https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/971)
>
> Not officially a positive signal, but looking positive based on the
> comments.
>

Indeed.

>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933
> )
>
> This is kind of an "N/A to positive", given it's WebGPU.
>

Agree ;)

>
> *Web developers*: Positive (https://github.com/gpuweb/gpuweb/issues/4197)
>
> *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, ChromeOS, Android, and Android WebView)? No
> All platforms will eventually have support. Will immediately be available
> on Android, ChromeOS, Mac, and Windows, since those platforms already
> support WebGPU. Linux is planned to have WebGPU support in the future, so
> this feature will become available when WebGPU does.
>
> What about WebView? Do we ship support for WebGPU there?
>

Yes. WebGPU is supported on Android WebView as well.

>
> Is this feature fully tested by web-platform-tests
> 
> ? Yes
>
> WebGPU/WGSL have a conformance test suite (https://github.com/gpuweb/cts)
> that is regularly pulled into Chromium and part of the testing of Dawn/Tint
> in Chromium. PRs: https://github.com/gpuweb/cts/pull/3419 -
> https://github.com/gpuweb/cts/pull/3345
>
>
> Flag name on chrome://flags None
>
> Finch feature name WebGPUExperimentalFeatures
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1521763
>
> Estimated milestones
> Shipping on desktop 124
> Shipping on Android 124
>
> 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/4875951026733056
>
> Links to previous Intent discussions Intent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2BewUL-PTEQ_ZQgdtViKU2fSVXeDNab2oEy6RsGqkgcGQ%40mail.gmail.com
>
> 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/CAPpwU5Lo3k-Gynt4M%2BwgV3yfg%2BFvM1npij%2BGTNZLW-VZHojXYA%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.

Re: [blink-dev] Intent to Ship: Adding Cross-site Ancestor Chain Bit to CHIPS Partition Key

[Vladimir Levin]

On Mon, Mar 11, 2024 at 1:42 PM Aaron Selya  wrote:

> Contact emails
>
> se...@chromium.org, dylancut...@chromium.org, kaustub...@chromium.org
>
>
> Explainer
>
> Keying of "CHIPS" cookies should align with other state:
> 
>
>
> Specification
>
> Add cross-site ancestor chain bit to spec:
> https://github.com/explainers-by-googlers/CHIPS-spec/pull/13
>
>
>
> Summary
>
> We are looking to align the partition key
> 
> in CHIPS (Cookies Having Independent Partitioned State, aka partitioned
> cookies) with the existing implementation of StorageKey.
>
>
> The only sites that would experience different behavior, would be when a
> top-level site “A” embeds an iframe to a cross-site document on site “B”,
> and then the iframe B embeds an iframe that loads a document from site “A”
> (shorthand: A1->B->A2). Previously, partitioned cookies sent or received in
> the inner iframe A2 would be the same partitioned cookies sent or received
> in the outer frame A1. This is no longer true.
>
>
> This change is privacy neutral, but will have improved security
> characteristics, because it prevents cross-site iframes from embedding
> arbitrary endpoints of the top-level site with credentials, without first
> being granted permission to do so through the Storage Access API (SAA) or
> Cross-Origin Resource Sharing (CORS).
>
>
>
> The impact of this change is expected to be small as our metrics indicate
> that only 0.2% of CHIPS (partitioned cookies) set by the first party are
> currently being used in A1->B->A2 contexts. This constitutes 0.032% of all
> page loads (calculated using the usage of PartitionedCookie
> ). For
> websites that do need access to the same cookies across A1 and A2 (in the
> A1->B->A2 configuration), we recommend using SameSite=None cookies
> *without* the Partitioned attribute, and invoking the Storage Access API
> (SAA) or using the Cross-Origin Resource Sharing (CORS).
>
>
>
> Blink component
>
> Internals>Network>Cookies>PartitionedCookies
> 
>
>
>
>
> TAG review
>
> Not requested, as this does not differ in any significant way from the
> original CHIPS design that was already reviewed by TAG
> .
>
>
> TAG review status
>
> N/A
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> The inclusion of a new element in the partition key will mean that
> partitioned cookies (CHIPS) created after the launch of this change will
> not be compatible with the partitioned cookies that already exist in users
> cookie jars. To address this, existing partitioned cookies will be migrated
> (without any need for developer action) to include the new cross-site
> ancestor chain bit value, which will be set with a value of true if the
> existing partition key does not match the host key (indicating a cross site
> ancestor is present) and false if the partition key does match the host
> key. This will ensure that most existing CHIPS have the same scope as they
> did prior to the change.
>
>
> Only 0.2% of partitioned cookies are utilized from within A1->B->A2
> scenarios, but developers who need to be able to access cookies in
> A1->B->A2 scenarios will be able to use SAA, and CORS to gain access to
> those cookies, after transitioning to SameSite=None cookies without the
> Partitioned attribute.
>
>
> To limit the impact of any significant breakages that may occur when this
> is deployed, the new feature will be gated by a flag allowing for it to be
> turned off easily. Additionally metrics are being gathered to proactively
> identify the sites that are going to be impacted by this change, so that we
> can do outreach to potentially impacted sites. As this feature gets
> deployed, we will monitor the bug and breakage reports to help identify
> issues and assist developers in transitioning to one of the other
> mechanisms that will allow their sites to work in an A1->B->A2 context.
>

The first mitigation listed here is to migrate existing partitioned cookies
to include the new bit, and the second mitigation is to have a flag that
can disable this feature. Would disabling the feature also include
migrating the existing cookies back to exclude the new bit?

And somewhat related, but does the format of the cookie request developers
make have to change too, or is this bit determination purely done within
the browser?


>
> As this does not differ in any significant way from the original partitioned
> cookies design t

Re: [blink-dev] Intent to Ship: WebGPU: ServiceWorker and SharedWorker support

[Mike Taylor]

On 3/11/24 4:06 PM, 'François Beaufort' via blink-dev wrote:



Contact emails

fbeauf...@google.com


Explainer

None

Could you write a few sentences why this is a useful addition?



Specification

https://gpuweb.github.io/gpuweb/#navigator-gpu


Summary

Functionality added to the WebGPU spec after its first shipment in a 
browser. ServiceWorker and SharedWorker support is added to WebGPU, 
aligning with existing WebGL capabilities.



Blink component

Blink>WebGPU 




TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

ServiceWorker and SharedWorker support have not yet been implemented 
in any browser, but have been approved by the GPU for the Web 
Community Group, with representatives from Chrome, Firefox, and 
Safari. See minutes at 
https://docs.google.com/document/d/15w7nsvqWwITA5yvCrsO3SEIEuZziXzj7YsrHN4Jd2uM/edit#heading=h.jbe7pg8ebd43 




/Gecko/: No signal 
(https://github.com/mozilla/standards-positions/issues/971)
Not officially a positive signal, but looking positive based on the 
comments.


/WebKit/: No signal 
(https://github.com/WebKit/standards-positions/issues/294#issuecomment-1877411933)

This is kind of an "N/A to positive", given it's WebGPU.


/Web developers/: Positive (https://github.com/gpuweb/gpuweb/issues/4197)

/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, ChromeOS, Android, and Android WebView)?

No
All platforms will eventually have support. Will immediately be 
available on Android, ChromeOS, Mac, and Windows, since those 
platforms already support WebGPU. Linux is planned to have WebGPU 
support in the future, so this feature will become available when 
WebGPU does.

What about WebView? Do we ship support for WebGPU there?




Is this feature fully tested by web-platform-tests

?

Yes

WebGPU/WGSL have a conformance test suite 
(https://github.com/gpuweb/cts) that is regularly pulled into Chromium 
and part of the testing of Dawn/Tint in Chromium. PRs: 
https://github.com/gpuweb/cts/pull/3419 - 
https://github.com/gpuweb/cts/pull/3345



Flag name on chrome://flags

None


Finch feature name

WebGPUExperimentalFeatures


Requires code in //chrome?

False


Tracking bug

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


Estimated milestones

Shipping on desktop 124

Shipping on Android 124



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


Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPpwU5%2BewUL-PTEQ_ZQgdtViKU2fSVXeDNab2oEy6RsGqkgcGQ%40mail.gmail.com


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/CAPpwU5Lo3k-Gynt4M%2BwgV3yfg%2BFvM1npij%2BGTNZLW-VZHojXYA%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/b93b29a5-db02-4959-8406-b09ad10355e7%40chromium.org.

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint

[Mike Taylor]

On 3/12/24 11:33 AM, Nicolás Peña Moreno wrote:

Thanks for the suggestion, Yoav! It seems something fetch experts have 
some concerns about, so we do not plan to proceed with that suggestion 
at the moment.


I'd like to append a small addition to this I2S (mainly to avoid 
having an additional PSA since it is very related to this one): we 
would also like approval to only send Same-Site=None cookies in the 
accounts endpoint, instead of all cookies (so not Same-Site=Lax or 
Same-Site=Strict). This is also a breaking change but we do not 
anticipate IDPs to break, and also plan to work with them to ensure 
that they are aware of this change and are not caught by surprise.
To my non-FedCM expert brain, this doesn't feel like a small addition 
(happy to be wrong!), beyond not understanding the scale of the risk, 
the normal process questions come to mind i.e., is it specced, do we 
have tests, what do other vendors think about it?


On Monday, March 11, 2024 at 6:39:14 AM UTC-4 Yoav Weiss wrote:


I left a comment
 around
potentially adding a CORS mode that would help IDP servers
statically protect themselves from destination-change attacks. I
don't *think* it's a blocker, but it's worth considering something
along those lines to increase the solution's robustness to
configuration errors, and ensure it fails closed. (and ask IDPs'
security teams about their thoughts)

On Wed, Mar 6, 2024 at 5:51 PM Nicolás Peña  wrote:

No, Sec-Fetch-Dest


is not changing. Sec-Fetch-Mode


is.

On Wednesday, March 6, 2024 at 11:31:35 AM UTC-5 Chris
Harrelson wrote:

On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña
 wrote:



On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav
Weiss wrote:

On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss
(@Shopify)  wrote:



On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor
 wrote:

LGTM1

On 3/4/24 1:33 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org


Explainer

https://github.com/fedidcg/FedCM/issues/428




A few lines summarizing this issue would be
most useful when evaluating this and
understanding what y'all want to ship.
In particular, it'd be useful to understand
the request flow, what is the request's origin
(as IIUC, we're talking about requests issued
from the browser), and what is the request
destination that we may want IDPs to check.

Examples of the checks IDPs would have to make
would also be helpful.


Sure! From the spec

,
here is a sample request:

POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true
With this change, Sec-Fetch-Mode will now be cors in
this request and the IDP is expected to return the
following in the response (no preflight is performed):


Do you mean Sec-Fetch-Dest?


Access-Control-Allow-Origin: https://rp.example/
Access-Control-Allow-Credentials: true


Also, is the "identity assertion" endpoint the
same as the token endpoint

?


Yea. I think that explainer doc is not super up to date.



Specification

https://github.com/fedidcg/FedCM/pull/547



Summary

The fetches in the FedCM API are hard to
reason about because of the properties
required of them. While there is ongoing
discussion regarding the accounts
  

Re: [blink-dev] Intent to Ship: Interoperable mousemove default action

[Chris Harrelson]

Sounds good to me! LGTM1

On Tue, Mar 12, 2024 at 9:53 AM Mustaq Ahmed  wrote:

> Hi API Owners:
>
> We concluded this feature is safe to ship after investigating the few sites
> that are affecting our use-counter:
> - None of UKM reported sites show any usability problem in our
> investigation.
> - On one of those sites, a mouse drag over menu items starts text
> selection (w/o affecting usability).  The site shows the same problem with
> Firefox and Safari; and even on Chrome Stable (w/o the feature) but for
> certain menu-item drags.
> - The UKM usage percentages for those sites add up to match the ~0.12%
> usage shown by our use-counter.  So no sites affecting our use-counter
> seem to have been left out by UKM.
>
> In case this is still needed, we are rolling out the 1% Stable experiment
> that we promised on Jan 17.
>
> Mustaq
>
>
> On Wed, Mar 6, 2024 at 10:06 AM Mustaq Ahmed  wrote:
>
>> No, issue 327409885 is related to the PSA on canceling mousedown in
>> iframe
>> 
>> .
>>
>>
>> On Wed, Mar 6, 2024 at 5:25 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>> Is https://issues.chromium.org/issues/327409885 related here?
>>>
>>> On Mon, Mar 4, 2024 at 6:09 PM Mustaq Ahmed  wrote:
>>>
 UKM data shows that only a few popular sites are affecting our
 use-counters.  We already confirmed that one of those sites is not broken
 at all, only showing text selection on menu items.  We are expecting to
 conclude soon after investigating all those sites.

 On Wed, Jan 17, 2024 at 1:48 PM Mustaq Ahmed 
 wrote:

> A quick update: our use-counter on Chrome 122 Canary/Dev came out
> higher than we expected---it is suggesting that at most 0.11% page loads
> are affected.
>
> We will expand the finch trail to 50% Beta plus 1% Stable now to get
> more data, and then look into other directions like adding UKM or fine
> tuning the use-counter.
>
>
> On Thu, Dec 7, 2023 at 10:14 AM Rick Byers 
> wrote:
>
>>
>>
>> On Wed, Dec 6, 2023 at 5:08 PM Mustaq Ahmed 
>> wrote:
>>
>>> > I assume cancelling the mousedown (but not the mousemove) still
>>> prevents selection and drag-and-drop in all browsers, is that right? 
>>> That's
>>> the pattern I'd expect is most common. Also, what's the behavior of
>>> pointermove for mice today and after this change?
>>>
>>> I just confirmed  that
>>> Chrome (and Firefox and Safari too) already prevents both selection and
>>> drag-and-drop when mousedown or pointerdown is cancelled.  So sites
>>> canceling all the mouse events will work fine.
>>>
>>
>> Great, thanks! That definitely lowers my concern.
>>
>> > We have landed a metric which specifically checks for cases where
>>> the mousemove is preventDefaulted but a selection starts (i.e. 
>>> selectstart
>>> wasn't prevented, there was no user-select: none, and so the selection 
>>> does
>>> change). Right now this is a UMA but we could also add UKM and get sites
>>> from this. Mustaq WDYT about adding UKM for this and running the 1%
>>> finch trial?
>>>
>>> Adding UKM and running a 1% finch trial sounds good.
>>>
>>> Perhaps we can run a Canary/Dev/Beta trial even now (on M121)?
>>>
>>
>> Yep, you can do whatever you want for canary/dev and you have API
>> owner approval for Beta and Stable up to 1% if you want it. Perhaps beta
>> data alone would be compelling enough for API owners to approve this 
>> (with
>> an understanding, like always, that we'd kill-switch it on reports of
>> non-trivial stable breakage).
>>
>> On Wed, Dec 6, 2023 at 12:34 PM Robert Flack 
>>> wrote:
>>>
 On Wed, Dec 6, 2023 at 12:18 PM Rick Byers 
 wrote:

> API owners met and discussed this one briefly today. There was
> agreement that more work needs to be done to demonstrate the compat 
> risk is
> low enough to ship this breaking change. A few points:
>
>- If you'd like to do a finch trial to gather data (up to
>stable 1%) we're supportive of that.
>- Mike Taylor argued that you're not likely to learn too much
>useful from a finch trial since people seem not to report bugs for 
> things
>that fail for a seemingly random 1% of their users, and perhaps 
> the idea of
>surveying a few sites would be more effective at finding real 
> breakage. Of
>course UKM + Finch might be a good way to find URLs to test.
>
> We have landed a metric which specifically checks for cases where
 the mousemove is preventDefaulted but a selection starts (i.e. 
 selectstart
 wasn't prevent

Re: [blink-dev] Intent to Ship: Interoperable mousemove default action

[Mustaq Ahmed]

Hi API Owners:

We concluded this feature is safe to ship after investigating the few sites
that are affecting our use-counter:
- None of UKM reported sites show any usability problem in our
investigation.
- On one of those sites, a mouse drag over menu items starts text selection
(w/o affecting usability).  The site shows the same problem with Firefox
and Safari; and even on Chrome Stable (w/o the feature) but for certain
menu-item drags.
- The UKM usage percentages for those sites add up to match the ~0.12%
usage shown by our use-counter.  So no sites affecting our use-counter
seem to have been left out by UKM.

In case this is still needed, we are rolling out the 1% Stable experiment
that we promised on Jan 17.

Mustaq


On Wed, Mar 6, 2024 at 10:06 AM Mustaq Ahmed  wrote:

> No, issue 327409885 is related to the PSA on canceling mousedown in iframe
> 
> .
>
>
> On Wed, Mar 6, 2024 at 5:25 AM Yoav Weiss (@Shopify) <
> yoavwe...@chromium.org> wrote:
>
>> Is https://issues.chromium.org/issues/327409885 related here?
>>
>> On Mon, Mar 4, 2024 at 6:09 PM Mustaq Ahmed  wrote:
>>
>>> UKM data shows that only a few popular sites are affecting our
>>> use-counters.  We already confirmed that one of those sites is not broken
>>> at all, only showing text selection on menu items.  We are expecting to
>>> conclude soon after investigating all those sites.
>>>
>>> On Wed, Jan 17, 2024 at 1:48 PM Mustaq Ahmed 
>>> wrote:
>>>
 A quick update: our use-counter on Chrome 122 Canary/Dev came out
 higher than we expected---it is suggesting that at most 0.11% page loads
 are affected.

 We will expand the finch trail to 50% Beta plus 1% Stable now to get
 more data, and then look into other directions like adding UKM or fine
 tuning the use-counter.


 On Thu, Dec 7, 2023 at 10:14 AM Rick Byers  wrote:

>
>
> On Wed, Dec 6, 2023 at 5:08 PM Mustaq Ahmed 
> wrote:
>
>> > I assume cancelling the mousedown (but not the mousemove) still
>> prevents selection and drag-and-drop in all browsers, is that right? 
>> That's
>> the pattern I'd expect is most common. Also, what's the behavior of
>> pointermove for mice today and after this change?
>>
>> I just confirmed  that
>> Chrome (and Firefox and Safari too) already prevents both selection and
>> drag-and-drop when mousedown or pointerdown is cancelled.  So sites
>> canceling all the mouse events will work fine.
>>
>
> Great, thanks! That definitely lowers my concern.
>
> > We have landed a metric which specifically checks for cases where
>> the mousemove is preventDefaulted but a selection starts (i.e. 
>> selectstart
>> wasn't prevented, there was no user-select: none, and so the selection 
>> does
>> change). Right now this is a UMA but we could also add UKM and get sites
>> from this. Mustaq WDYT about adding UKM for this and running the 1%
>> finch trial?
>>
>> Adding UKM and running a 1% finch trial sounds good.
>>
>> Perhaps we can run a Canary/Dev/Beta trial even now (on M121)?
>>
>
> Yep, you can do whatever you want for canary/dev and you have API
> owner approval for Beta and Stable up to 1% if you want it. Perhaps beta
> data alone would be compelling enough for API owners to approve this (with
> an understanding, like always, that we'd kill-switch it on reports of
> non-trivial stable breakage).
>
> On Wed, Dec 6, 2023 at 12:34 PM Robert Flack 
>> wrote:
>>
>>> On Wed, Dec 6, 2023 at 12:18 PM Rick Byers 
>>> wrote:
>>>
 API owners met and discussed this one briefly today. There was
 agreement that more work needs to be done to demonstrate the compat 
 risk is
 low enough to ship this breaking change. A few points:

- If you'd like to do a finch trial to gather data (up to
stable 1%) we're supportive of that.
- Mike Taylor argued that you're not likely to learn too much
useful from a finch trial since people seem not to report bugs for 
 things
that fail for a seemingly random 1% of their users, and perhaps the 
 idea of
surveying a few sites would be more effective at finding real 
 breakage. Of
course UKM + Finch might be a good way to find URLs to test.

 We have landed a metric which specifically checks for cases where
>>> the mousemove is preventDefaulted but a selection starts (i.e. 
>>> selectstart
>>> wasn't prevented, there was no user-select: none, and so the selection 
>>> does
>>> change). Right now this is a UMA but we could also add UKM and get sites
>>> from this. Mustaq WDYT about adding UKM for this and running the 1% 
>>

Re: [blink-dev] Intent to Ship: FedCM CORS requirement on ID assertion endpoint

['Nicolás Peña Moreno' via blink-dev]

Thanks for the suggestion, Yoav! It seems something fetch experts have some 
concerns about, so we do not plan to proceed with that suggestion at the 
moment.

I'd like to append a small addition to this I2S (mainly to avoid having an 
additional PSA since it is very related to this one): we would also like 
approval to only send Same-Site=None cookies in the accounts endpoint, 
instead of all cookies (so not Same-Site=Lax or Same-Site=Strict). This is 
also a breaking change but we do not anticipate IDPs to break, and also 
plan to work with them to ensure that they are aware of this change and are 
not caught by surprise.

On Monday, March 11, 2024 at 6:39:14 AM UTC-4 Yoav Weiss wrote:

> 
> I left a comment 
>  around 
> potentially adding a CORS mode that would help IDP servers statically 
> protect themselves from destination-change attacks. I don't *think* it's a 
> blocker, but it's worth considering something along those lines to increase 
> the solution's robustness to configuration errors, and ensure it fails 
> closed. (and ask IDPs' security teams about their thoughts)
>
> On Wed, Mar 6, 2024 at 5:51 PM Nicolás Peña  wrote:
>
>> No, Sec-Fetch-Dest 
>>  
>> is not changing. Sec-Fetch-Mode 
>>  
>> is.
>>
>> On Wednesday, March 6, 2024 at 11:31:35 AM UTC-5 Chris Harrelson wrote:
>>
> On Wed, Mar 6, 2024 at 8:28 AM Nicolás Peña  wrote:
>>>


 On Wednesday, March 6, 2024 at 5:11:09 AM UTC-5 Yoav Weiss wrote:

 On Wed, Mar 6, 2024 at 10:21 AM Yoav Weiss (@Shopify) <
 yoav...@chromium.org> wrote:



 On Mon, Mar 4, 2024 at 9:36 PM Mike Taylor  
 wrote:

 LGTM1
 On 3/4/24 1:33 PM, Nicolás Peña wrote:

 Contact emails 

 n...@chromium.org

 Explainer 

 https://github.com/fedidcg/FedCM/issues/428 


 A few lines summarizing this issue would be most useful when evaluating 
 this and understanding what y'all want to ship.
 In particular, it'd be useful to understand the request flow, what is 
 the request's origin (as IIUC, we're talking about requests issued from 
 the 
 browser), and what is the request destination that we may want IDPs to 
 check.

 Examples of the checks IDPs would have to make would also be helpful.


 Sure! From the spec 
 , here 
 is a sample request:

 POST /fedcm_assertion_endpoint HTTP/1.1
 Host: idp.example
 Origin: https://rp.example/
 Content-Type: application/x-www-form-urlencoded
 Cookie: 0x23223
 Sec-Fetch-Dest: webidentity

 account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true
  
 With this change, Sec-Fetch-Mode will now be cors in this request and 
 the IDP is expected to return the following in the response (no preflight 
 is performed):

>>>
>>> Do you mean Sec-Fetch-Dest?
>>>  
>>>

 Access-Control-Allow-Origin: https://rp.example/
 Access-Control-Allow-Credentials: true
  


 Also, is the "identity assertion" endpoint the same as the token 
 endpoint 
 
 ?


 Yea. I think that explainer doc is not super up to date.
  


 Specification 

 https://github.com/fedidcg/FedCM/pull/547 

 Summary 

 The fetches in the FedCM API are hard to reason about because of the 
 properties required of them. While there is ongoing discussion regarding 
 the accounts endpoint, there is broad consensus that the ID assertion 
 endpoint should use CORS. This aligns security properties of this fetch 
 more closely to other fetches in the web platform.

 Blink component 

 Blink>Identity>FedCM 
 

 TAG review 

 Not requesting a TAG review. We have already had extensive discussions 
 with Fetch experts.

 TAG review status 

 N/A

 Risks

 Interoperability and Compatibility 

 This is a backwards incompatible feature, but one that is warranted due 
 to consensus reached by our security reviewers as well as other browser 
 vendor engineers. We have a manageable list of IDPs that we know are using 
 the FedCM API and we have reached out to all IDPs that are currently 
 deploying FedCM to make sure that they won’t break with this change.


 Gecko: Positive based on TPAC discussions and 
 https://github.com/fedidcg/FedCM/issues/428. Not filing a standards 
 position request for small additions at the explicit r

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

[Mike Taylor]

Hi Emanuel,

For OTs, we can approve extensions for 3 milestones at a time, depending 
on the criteria set at 
https://www.chromium.org/blink/launching-features/#origin-trials. Would 
you mind summarizing progress in the various areas? It sounds like there 
is good engagement from the "spec community" already.


thx,
Mike

On 3/12/24 8:35 AM, Emanuel Ziegler wrote:

Dear API owners,

Our origin trial on supporting JS Strings in Wasm 
 
(JS String Builtins 
 
for Wasm) has reached its final milestone and we would like to 
continue to experiment with it.


The current status of the proposal and our experiments 
 
is as follows:


  * The proposal is progressing well and has *reached phase 2* on
January 16 with overwhelming support by the community group (17
votes strongly in favor, 11 votes in favor, 4 neutral and no votes
against).
  * Performance of native support for JS strings in J2Wasm, Kotlin and
Dart continues to look highly promising, making this a top
priority for us to finalize the proposal and ship it in Chrome
this year.
  * There were a *series of changes


to the proposal* and its API leading up to the vote which since
then have all been implemented in V8.
  * *Sheets and J2Wasm started experimentation on the proposal* and we
expect in-the-wild performance numbers of the new API within the
next weeks, comparing this with the previous proposal (StringRef)


that this one will replace.
  * *More experimentation* *with respect to string constants *around
binary size, memory overhead and initialization performance is
required. Several options


are available regarding their implementation in the current proposal.
  * Rollout of Sheets experiments is currently at 20% of production
users offering us a wide number of real-world use cases.

We would therefore like to *extend the origin trial by another 6 
milestones*, effectively ending it with M130. This is taking into 
account the long turnaround times required to test any API change 
between proposal changes, their implementation in Chrome, Binaryen, 
J2Wasm and Sheets until we can update the experiment and gather new 
data. We expect to reach phase 3 within the next months and want to 
use the data to inform the final shape of the proposal to be voted to 
phase 4, hopefully before the end of the year.


Thank you,
    Emanuel


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


Chromium Trial Name

WebAssemblyJSStringBuiltins


Link to origin trial feedback summary

https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing


Origin Trial documentation link

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


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 application

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

Okay I update the process stage in Chrome Platform Status, and paste the 
newly-generated Intent above. Please take a look.

https://chromestatus.com/feature/5106220399853568

On Tuesday, March 12, 2024 at 8:57:59 PM UTC+8 Zheda Chen wrote:

> *Intent to Ship: Add JavaScript timer wake up alignment for unimportant 
> cross-origin frames*
>
> Contact emails
> zheda...@intel.com, fdo...@chromium.org
>
> Specification
> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>
> Summary
>
> Align wake ups of JavaScript timers for unimportant cross-origin frames. 
> Currently, DOM timers <32ms are all opt-out from AlignWakeUps [1] due to 
> performance concerns. This is very conservative and actually some 
> unimportant frames are eligible to use JS timer alignment. WebKit uses the 
> policy to align DOM timer of non-interacted cross origin frames to 30ms. 
> This feature adds JavaScript timer wake up alignment for unimportant frames 
> on foreground pages. Unimportant frames means they are cross origin, 
> visible but have non-large proportion of page’s visible area, and have no 
> user interaction. [1] 
> https://chromium-review.googlesource.com/c/chromium/src/+/4589092
>
>
> Blink component
> Blink>PerformanceAPIs>Timers 
> 
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks
>
> Interoperability and Compatibility
>
> None
>
> *Gecko*: No signal
>
> *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
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?
> Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
> No
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> ThrottleUnimportantFrameTimers
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://issues.chromium.org/issues/40942028
>
> Estimated milestones
>
> Shipping on desktop
> 123
> DevTrial on desktop
> 121
> Shipping on Android
> 123
> DevTrial on Android
> 121
>
> 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/5106220399853568
>
> This intent message was generated by Chrome Platform Status 
> .
>
> On Thursday, March 7, 2024 at 12:15:41 PM UTC+8 dom...@chromium.org wrote:
>
>> Switching to an Intent to Ship sounds good. Can you update the process 
>> stage in the ChromeStatus tool, fill out any necessary fields that differ 
>> between the stages, and either start a new thread, or paste the 
>> newly-generated Intent here?
>>
>> On Thu, Mar 7, 2024 at 2:48 AM Etienne Pierre-doray  
>> wrote:
>>
>>> I'm working with Zheda and Francois to get this feature out, chiming in
>>>
>>> In general, I think it's best to file a formal Intent to Ship if you 
 want to go to 50% stable.

>>> I agree, I'd consider this feature ready to ship, we have enough 
>>> confidence from previous stable experiments to roll it out.
>>> The main reason for doing a 50/50 experiment first is to more accurately 
>>> measure impact on CWV. 
>>> There aren't clear guidelines from finch otherwise on the exact % when 
>>> ramping up from 1% to 100%, or when intermediate steps are needed at all; 
>>> our team has been following a 1/50/100 pattern (we received feedback for 
>>> other features that fewer intermediate steps was desirable for web devs). 
>>> For blink purpose, I'd suggest we switch this to an 'Intent to ship'.
>>>
>>> On Mon, Mar 4, 2024 at 5:06 PM Domenic Denicola  
>>> wrote:
>>>
 In general, I think it's best to file a formal Intent to Ship if you 
 want to go to 50% stable. To me it sounds like that might be reasonable 
 here? I.e. you're fairly confident that the feature is a good idea to 
 ship, 
 but you want to do a more cautious rollout. I think many Intent to Ships 
 go 
 through this sort of cautious rollout; they just don't necessarily discuss 
 the details of it on blink-dev.

 2024年3月5日(火) 5:19 Mike Taylor :

> My concern is going from 1% to 50% on stable - if something does go 
> wrong, that's a _lot_ of folks who will experience it. Are you open to 
> something smaller like 5%? If not, why not?
>
>

Re: [blink-dev] Intent to Ship: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

*Intent to Ship: Add JavaScript timer wake up alignment for unimportant 
cross-origin frames*

Contact emails
zheda.c...@intel.com, fdo...@chromium.org

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

Summary

Align wake ups of JavaScript timers for unimportant cross-origin frames. 
Currently, DOM timers <32ms are all opt-out from AlignWakeUps [1] due to 
performance concerns. This is very conservative and actually some 
unimportant frames are eligible to use JS timer alignment. WebKit uses the 
policy to align DOM timer of non-interacted cross origin frames to 30ms. 
This feature adds JavaScript timer wake up alignment for unimportant frames 
on foreground pages. Unimportant frames means they are cross origin, 
visible but have non-large proportion of page’s visible area, and have no 
user interaction. [1] 
https://chromium-review.googlesource.com/c/chromium/src/+/4589092


Blink component
Blink>PerformanceAPIs>Timers 


TAG review
None

TAG review status
Not applicable

Risks

Interoperability and Compatibility

None

*Gecko*: No signal

*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

Debuggability

None


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

Is this feature fully tested by web-platform-tests 

?
No

Flag name on chrome://flags
None

Finch feature name
ThrottleUnimportantFrameTimers

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40942028

Estimated milestones
Shipping on desktop
123
DevTrial on desktop
121
Shipping on Android
123
DevTrial on Android
121

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

This intent message was generated by Chrome Platform Status 
.

On Thursday, March 7, 2024 at 12:15:41 PM UTC+8 dom...@chromium.org wrote:

> Switching to an Intent to Ship sounds good. Can you update the process 
> stage in the ChromeStatus tool, fill out any necessary fields that differ 
> between the stages, and either start a new thread, or paste the 
> newly-generated Intent here?
>
> On Thu, Mar 7, 2024 at 2:48 AM Etienne Pierre-doray  
> wrote:
>
>> I'm working with Zheda and Francois to get this feature out, chiming in
>>
>> In general, I think it's best to file a formal Intent to Ship if you want 
>>> to go to 50% stable.
>>>
>> I agree, I'd consider this feature ready to ship, we have enough 
>> confidence from previous stable experiments to roll it out.
>> The main reason for doing a 50/50 experiment first is to more accurately 
>> measure impact on CWV. 
>> There aren't clear guidelines from finch otherwise on the exact % when 
>> ramping up from 1% to 100%, or when intermediate steps are needed at all; 
>> our team has been following a 1/50/100 pattern (we received feedback for 
>> other features that fewer intermediate steps was desirable for web devs). 
>> For blink purpose, I'd suggest we switch this to an 'Intent to ship'.
>>
>> On Mon, Mar 4, 2024 at 5:06 PM Domenic Denicola  
>> wrote:
>>
>>> In general, I think it's best to file a formal Intent to Ship if you 
>>> want to go to 50% stable. To me it sounds like that might be reasonable 
>>> here? I.e. you're fairly confident that the feature is a good idea to ship, 
>>> but you want to do a more cautious rollout. I think many Intent to Ships go 
>>> through this sort of cautious rollout; they just don't necessarily discuss 
>>> the details of it on blink-dev.
>>>
>>> 2024年3月5日(火) 5:19 Mike Taylor :
>>>
 My concern is going from 1% to 50% on stable - if something does go 
 wrong, that's a _lot_ of folks who will experience it. Are you open to 
 something smaller like 5%? If not, why not?

 thx
 On 2/29/24 12:34 AM, Zheda Chen wrote:

 The volume of data on Beta is too low to draw any conclusion. Although 
 the experiment on 1% stable shows some promising result, the data are not 
 enough and we'd like to gather more data via experiment on higher 
 percentage of stable. 
 After that, based on large volume of data, we can draw the conclusion 
 and decide next step (whether to ship the feature). 

 I contribute the 

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

[Emanuel Ziegler]

Dear API owners,

Our origin trial on supporting JS Strings in Wasm

(JS String Builtins

for Wasm) has reached its final milestone and we would like to continue to
experiment with it.

The current status of the proposal and our experiments

is as follows:

   - The proposal is progressing well and has *reached phase 2* on
   January 16 with overwhelming support by the community group (17 votes
   strongly in favor, 11 votes in favor, 4 neutral and no votes against).
   - Performance of native support for JS strings in J2Wasm, Kotlin and
   Dart continues to look highly promising, making this a top priority for us
   to finalize the proposal and ship it in Chrome this year.
   - There were a *series of changes
   

   to the proposal* and its API leading up to the vote which since then
   have all been implemented in V8.
   - *Sheets and J2Wasm started experimentation on the proposal* and we
   expect in-the-wild performance numbers of the new API within the next
   weeks, comparing this with the previous proposal (StringRef)
   

   that this one will replace.
   - *More experimentation* *with respect to string constants *around
   binary size, memory overhead and initialization performance is
required. Several
   options
   

   are available regarding their implementation in the current proposal.
   - Rollout of Sheets experiments is currently at 20% of production users
   offering us a wide number of real-world use cases.

We would therefore like to *extend the origin trial by another 6 milestones*,
effectively ending it with M130. This is taking into account the long
turnaround times required to test any API change between proposal changes,
their implementation in Chrome, Binaryen, J2Wasm and Sheets until we can
update the experiment and gather new data. We expect to reach phase 3
within the next months and want to use the data to inform the final shape
of the proposal to be voted to phase 4, hopefully before the end of the
year.

Thank you,
Emanuel


Contact emailsecmzieg...@chromium.org, jkumme...@chromium.org,
ad...@chromium.org

ExplainerNone

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 componentBlink>JavaScript>WebAssembly


TAG reviewNone

TAG review statusNot applicable

Chromium Trial NameWebAssemblyJSStringBuiltins

Link to origin trial feedback summary
https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing

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

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, ChromeOS, Android, and Android WebView)?Yes

Is this feature fully tested by web-platform-tests

?No

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

Estimated milestones
Origin trial desktop first 119
Origin tri