Re: [blink-dev] Re: Intent to Experiment: Align Timers (including DOM timers) at 125 Hz

[Yoav Weiss]

On Wed, Aug 3, 2022 at 7:07 PM Etienne Pierre-doray 
wrote:

> What's the plan for monitoring potential breakage? Looking at incoming
>> bugs?
>
>  Yes, there's been a few breakage on earlier channel (all addressed as of
> now). This one was related to DOM timer:
> https://buganizer.corp.google.com/issues/220682826
>

For folks outside of Google, the bug describes a site that relied on timer
accuracy to schedule tasks, and saw a degradation in their performance
metrics. The site in question then fixed it by moving away from those
methods. (I hope I'm capturing that correctly. I only skimmed through the
issue so please correct me if I got it wrong)

I suspect many non-Google properties run similar code, and would similarly
be surprised by this change. e.g. I know that many JS driven animations
used to rely on timers, and I'm not sure that's no longer the case.
Similarly, performance measurements that rely on timer accuracy as a proxy
for "CPU busyness" are common.


> Might be worthwhile to ask: https://bit.ly/blink-signals
>
> There's anecdotal evidence that Webkit is aligning timers at 10ms; all I
> could find re. DOM timers is this
> 
>  throttling
> at 30Hz in low power mode.
> Does https://bit.ly/blink-signals apply even if this chromestatus doesn't
> change the spec?
>

The web-exposed behavior is changing here, with potential compatibility and
interoperability implications. So even if the spec allows for that, I think
it's worthwhile to ask other vendors for their opinions on this.


>
> Question: What about APIs that have no proper flow control support, e.g.
>> WebSocket? They rely on (ab)use of setTimeout to avoid writing too much
>> into the underlying buffer. I wouldn't consider a 1s flow disruption delay
>> to be acceptable for this use case, not even in the background. Are there
>> any plans to prevent such issues?
>>
> Although that was meant for another proposal, this blog post
> 
> suggests an alternative to some setTimeout abuses.
> Note that this proposal only concerns the 8ms delay. The 1s throttling was
> done in this previous chromestatus
>  for background pages
> and shipped in M86.
>
> On Wed, Aug 3, 2022 at 11:42 AM Lennart Grahl 
> wrote:
>
>> Question: What about APIs that have no proper flow control support, e.g.
>> WebSocket? They rely on (ab)use of setTimeout to avoid writing too much
>> into the underlying buffer. I wouldn't consider a 1s flow disruption delay
>> to be acceptable for this use case, not even in the background. Are there
>> any plans to prevent such issues?
>>
>> On Wednesday, 3 August 2022 at 15:50:48 UTC+2 Etienne Pierre-doray wrote:
>>
>>> etie...@chromium.org
>>>
>>> ExplainerNone
>>>
>>> Specification
>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>>
>>> Design docs
>>>
>>> https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit
>>>
>>> Summary
>>>
>>> Run all timers (with a few exceptions) with a non-zero delay on a
>>> regular 8ms aligned wake up (125 Hz), instead of as soon as their delay has
>>> passed. This affect DOM timers; On foreground pages, run DOM timers with a
>>> non-zero delay on a regular 8ms aligned wake up, instead of as soon as
>>> their delay has passed. On background pages, DOM timers already run on a
>>> regular 1s aligned wake up (1 Hz), or even less frequently after 5 minutes.
>>>
>>>
>>> Blink componentBlink>Scheduling
>>> 
>>>
>>> TAG review
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> This feature changes the behavior of an existing API in a way that is
>>> spec-compliant (the spec says "Optionally, wait a further
>>> implementation-defined length of time", ref.:
>>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout).
>>> Content that relies on precise timing for DOM Timers may stop working
>>> properly in Chromium with this feature. The risk is mitigated by delaying
>>> DOM Timers by at most 8 ms, and by disabling the feature when WebRTC has
>>> active connections in the process. Content that cannot support a 8 ms delay
>>> would probably be better served by alternative APIs described at
>>> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds.
>>> Due to the significant battery savings that come with this feature, we
>>> expect that most browsers will decide to implement it after some time.
>>>
>>>
>>> *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 ha

Re: [blink-dev] Intent to Extend Experiment 2: Web app launch handler

[Alan Cutter]

Thanks! I consider the broken interaction with share target bad enough 
(side note, twitter.com is currently affected) that it's a blocking spec 
issue that needs fixing before we ship, once that's resolved I'll be 
sending an I2S for a gapless launch.

On Thursday, 4 August 2022 at 1:44:47 am UTC+10 Alex Russell wrote:

> LGTM to extend but want to note that this is about to bump up against a 
> year total runtime under experimentation, and the API OWNERS don't 
> generally like things to run so long.
>
> What's in the way of shipping? Is it possible that you'll have enough 
> feedback before 110 to go for a gapless launch? Would be great to get this 
> into the world.
>
> Thanks,
>
> Alex
>
> On Wednesday, August 3, 2022 at 12:59:20 AM UTC-7 tste...@google.com 
> wrote:
>
>> Updated the developer-facing article according to the changes: 
>> https://github.com/GoogleChrome/developer.chrome.com/pull/3368. Note 
>> that the explainer still mentions the old syntax.
>>
>> On Wed, Aug 3, 2022 at 9:49 AM Alan Cutter  
>> wrote:
>>
>>>
>>> *Contact emails*alancut...@chromium.org
>>>
>>>
>>> *Original I2E*
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/wNOClobsLrs
>>>
>>>
>>> *Explainer*https://github.com/WICG/sw-launch/blob/main/launch_handler.md
>>>
>>>
>>> *Specification*Draft: https://wicg.github.io/sw-launch/
>>>
>>>
>>> *Summary*Adds a "launch_handler" app manifest member that enables web 
>>> apps to customise their launch behaviour across all types of app launch 
>>> triggers (start menu launch, link capture, share target, etc.).
>>>
>>> Example usage:
>>> {
>>>   "name": "Example app",
>>>   "start_url": "/index.html",
>>>   "launch_handler": {
>>> "client_mode": "navigate-existing"
>>>   }
>>> }
>>> This will cause all launches of the Example app to focus an existing app 
>>> window and navigate it (if it exists) instead of always launching a new app 
>>> window.
>>>
>>>
>>> *Blink component*Blink>AppManifest 
>>> 
>>>
>>> *TAG review*
>>> https://github.com/w3ctag/design-reviews/issues/683
>>>
>>>
>>> *TAG review status*Closed. Satisfied to see this move ahead but keeping 
>>> in mind compatibility with the MiniApp lifecycle 
>>> .
>>>
>>> *Risks:*
>>> *Interoperability and Compatibility*
>>>  - Gecko: No signal 
>>> 
>>>  - WebKit: No signal 
>>> 
>>>  - Web developers: Strong positive signals on the previous Declarative 
>>> Link Capturing origin trial 
>>> ,
>>>  
>>> strong positive signals from the origin trial so far 
>>> 
>>> .
>>>
>>>
>>> *Experiment Summary*Web App Launch Handler Origin Trial 1 Developer 
>>> Feedback 
>>> 
>>>
>>>
>>> *Experiment Goals* - Expose the new client_mode 
>>>  syntax.
>>>  - Validate attempts to fix bad interactions with share target 
>>> .
>>>
>>>
>>> *Experiment Timeline*Previous: M103 to M106.
>>> Requested: M107 to M110.
>>>
>>>
>>> *Reason this experiment is being extended*- The route_to field has been 
>>> renamed to client_mode along with all its values (breaking change).
>>> - We uncovered a bad interaction with share target 
>>>  that requires spec change 
>>> to resolve.
>>>
>>>
>>> *Will this feature be supported on all six Blink platforms (Windows, 
>>> Mac, Linux, Chrome OS, Android, and Android WebView)?*No, desktop only.
>>>
>>> *Is this feature fully tested by* web-platform-tests 
>>> 
>>> *?*No, this requires browser_tests 
>>> 
>>>  as 
>>> it involves managing windows.
>>> Have raised an issue 
>>>  with 
>>> testdriver.js for web app specific support.
>>>
>>>
>>> *Flag name*chrome://flags/#enable-desktop-pwas-launch-handler
>>> kWebAppEnableLaunchHandler 
>>> 
>>>
>>>
>>> *Tracking bug*
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1231886
>>>
>>>
>>> *Link to entry on the Chrome Platform Statu

[blink-dev] Re: Intent to Ship: HTTP->HTTPS redirect for HTTPS DNS records

[Anon ymous]

whats the status of this now? how can I use it?

On Tuesday, April 19, 2022 at 11:10:09 AM UTC-4 Eric Orth wrote:

> Long-overdue update:
> After discovering a blocking bug that would have prevented the upgrade 
> from working successfully in many cases as well as the Fetch PR mentioned 
> above taking much longer than expected, we are now looking ready for this 
> launch again, now targeting Chrome 102.  The behavior has been rolled back 
> to 50% on Chrome Dev/Canary and 0% on Beta, in anticipation of rolling to 
> 50% Beta when Chrome 102 is widely available there in the next week or two.
>
> On Thu, Oct 28, 2021 at 4:47 PM Eric Orth  wrote:
>
>> We just started rolling the behavior to 50% on Chrome Beta.
>>
>> On Tue, Oct 19, 2021 at 1:09 PM Ralf Weber  wrote:
>>
>>> Moin!
>>>
>>> On 19 Oct 2021, at 17:22, Eric Orth wrote:
>>>
>>> > Yes.  Chrome 96 should start going to Beta this week, and we will most
>>> > likely be turning the experiment up to 50% on Beta sometime next 
>>> week.  And
>>> > sometime after Chrome 96 hits Stable (late November), we will begin a
>>> > careful and gradual rollout of the feature, but the details and 
>>> timeline
>>> > there are very much still TBD.
>>> Thanks a lot for the quick reply. I will continue to watch traffic. I 
>>> assume
>>> that the details will be announced here so I continue to watch this 
>>> space.
>>>
>>> So long
>>> -Ralf
>>> —--
>>> Ralf Weber
>>>
>>

-- 
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/cd211565-f97d-4e09-b004-6ce39d84cc9dn%40chromium.org.

Re: [blink-dev] Intent to Experiment: The Pop-Up API

[Yoav Weiss]

LGTM to experiment M106 to M110 inclusive.

This is super exciting! Thanks for working on this!!

On Wed, Aug 3, 2022 at 8:18 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> Explainerhttps://open-ui.org/components/popup.research.explainer
>
> Specification
>
> Summary
>
> An API that can be used to build transient user interface (UI) elements
> that are displayed on top of all other web app UI. These include
> user-interactive elements like action menus, form element suggestions,
> content pickers, and teaching UI. This API uses a new `popup` content
> attribute to enable any element to be displayed in the top layer. This is
> similar to the  element, but has several important differences,
> including light-dismiss behavior, pop-up interaction management, animation
> and event support, and the lack of a "modal" mode.
>
>
> Blink componentBlink>HTML>Popup
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/743
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>

Worthwhile to ask?


>
> *Web developers*: No signals
>

+Una Kravets  & +Nicole Sullivan  may
be able to help with gathering such 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?
>
>
>
> Goals for experimentation
>
> Validation of the shape and ergonomics of the overall pop-up API. Feedback
> should include use cases that do not work well (or that do work
> particularly well), performance issues, etc. Ideally, use cases should
> include as much of the API as possible, including multiple pop-up types
> (auto, hint, manual), nested pop-ups, declarative and imperative pop-up
> invocation, etc.
>
>
> Reason this experiment is being extended
>
>
>
> Ongoing technical constraints
>
> None
>
>
> Debuggability
>
> A feature has been added to devtools which shows all of the elements that
> are currently in the top layer, plus annotations of those elements in the
> Elements tree. Elements that use the pop-up API will be shown with this
> feature.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
> Flag name#enable-experimental-web-platform-features
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1307772
>
> Estimated milestones
> OriginTrial desktop last 110
> OriginTrial desktop first 106
> OriginTrial Android last 110
> OriginTrial Android first 106
> OriginTrial webView last 110
> OriginTrial webView first 106
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5463833265045504
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/9y-Thg9UCxY/m/_4gShWjQAAAJ
>
>
> 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/CAM%3DNeDjJOC2%2B5aHfAoN8wOx8T0gtm%3D-o6eNK5XD6Ps5iRet6zA%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/CAL5BFfWaVF2aNP-wE2MF%3D5%3DOm_e_BbQh_91dR6%3DqCLSLcbemHw%40mail.gmail.com.

[blink-dev] Intent to Prototype & Ship: Client Hints persistency in Android WebView

[Ari Chivukula]

Contact emails

aric...@chromium.org, miketa...@chromium.org, yoavw...@chromium.org


Specification

https://wicg.github.io/client-hints-infrastructure/

Explainer

When a page is loaded, the first response from an origin may include a
signal (in HTTP headers) for Client Hints to be included in future requests
to that origin. Without persisting this signal, Client Hints cannot be
included in the next request to load a page from this Origin. Android
WebView does not currently persist this signal.

Design Doc

https://docs.google.com/document/d/1r1AKHex1_UKh3wIp4ITkU4-J9-tdNZSOmUDeDVWw_AU/

Summary

We aim to add support for persistent Client Hints to Android Webview for
parity with the rest of the platform. For more details on the Client Hints
system see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Client_hints



Blink component

Blink>Network>ClientHints




Motivation

Without persisting the list of Client Hints a page requests the initial
load of a website will never include Client Hints, only subresources on a
given page can receive them. This undermines the use of the Client Hints
system which is to empower websites to adapt content to the User Agent. We
should add persistence in the interest of parity with the behavior of
Chrome on Android so that WebView stays viable as a platform.

TAG review

N/A (this change enables a feature that we already ship on desktop and
Android)

Compatibility

This expands persistent Client Hints to a platform that was missing it, no
existing implementation will change. The persisted Client Hints can be
cleared by clearing the Cookies for a given WebView, the same way that
Client Hints are cleared in Chrome for Android.


Interoperability

Other engines haven’t shipped Client Hints so this doesn’t increase
interoperability risk.



Gecko: Client Hints
 and User Agent
Client Hints 
considered non-harmful



WebKit: Mildly positive support for User Agent Client Hints




Web developers: Vendor interest from Huawei
,
interest from Cloudinary
 in User
Agent Client Hints

Debuggability

N/A (developers can use Chrome for Android to debug client hint requests,
though the values for user-agent related strings will differ within the
WebView context)

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

Android WebView is not a WPT platform, so this will only have chrome
internal tests

Tracking bug

https://crbug.com/921655

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4936247663919104

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

[blink-dev] Intent to Experiment: The Pop-Up API

[Mason Freed]

Contact emailsmas...@chromium.org

Explainerhttps://open-ui.org/components/popup.research.explainer

Specification

Summary

An API that can be used to build transient user interface (UI) elements
that are displayed on top of all other web app UI. These include
user-interactive elements like action menus, form element suggestions,
content pickers, and teaching UI. This API uses a new `popup` content
attribute to enable any element to be displayed in the top layer. This is
similar to the  element, but has several important differences,
including light-dismiss behavior, pop-up interaction management, animation
and event support, and the lack of a "modal" mode.


Blink componentBlink>HTML>Popup


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/743

TAG review statusPending

Risks


Interoperability and Compatibility



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



Goals for experimentation

Validation of the shape and ergonomics of the overall pop-up API. Feedback
should include use cases that do not work well (or that do work
particularly well), performance issues, etc. Ideally, use cases should
include as much of the API as possible, including multiple pop-up types
(auto, hint, manual), nested pop-ups, declarative and imperative pop-up
invocation, etc.


Reason this experiment is being extended



Ongoing technical constraints

None


Debuggability

A feature has been added to devtools which shows all of the elements that
are currently in the top layer, plus annotations of those elements in the
Elements tree. Elements that use the pop-up API will be shown with this
feature.


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

Is this feature fully tested by web-platform-tests

?Yes

Flag name#enable-experimental-web-platform-features

Requires code in //chrome?False

Tracking bughttps://crbug.com/1307772

Estimated milestones
OriginTrial desktop last 110
OriginTrial desktop first 106
OriginTrial Android last 110
OriginTrial Android first 106
OriginTrial webView last 110
OriginTrial webView first 106

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/9y-Thg9UCxY/m/_4gShWjQAAAJ


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/CAM%3DNeDjJOC2%2B5aHfAoN8wOx8T0gtm%3D-o6eNK5XD6Ps5iRet6zA%40mail.gmail.com.

[blink-dev] Re: Intent to Experiment: Align Timers (including DOM timers) at 125 Hz

[Etienne Pierre-doray]

>
> What's the plan for monitoring potential breakage? Looking at incoming
> bugs?

 Yes, there's been a few breakage on earlier channel (all addressed as of
now). This one was related to DOM timer:
https://buganizer.corp.google.com/issues/220682826

Might be worthwhile to ask: https://bit.ly/blink-signals

There's anecdotal evidence that Webkit is aligning timers at 10ms; all I
could find re. DOM timers is this

throttling
at 30Hz in low power mode.
Does https://bit.ly/blink-signals apply even if this chromestatus doesn't
change the spec?

Question: What about APIs that have no proper flow control support, e.g.
> WebSocket? They rely on (ab)use of setTimeout to avoid writing too much
> into the underlying buffer. I wouldn't consider a 1s flow disruption delay
> to be acceptable for this use case, not even in the background. Are there
> any plans to prevent such issues?
>
Although that was meant for another proposal, this blog post

suggests an alternative to some setTimeout abuses.
Note that this proposal only concerns the 8ms delay. The 1s throttling was
done in this previous chromestatus
 for background pages
and shipped in M86.

On Wed, Aug 3, 2022 at 11:42 AM Lennart Grahl 
wrote:

> Question: What about APIs that have no proper flow control support, e.g.
> WebSocket? They rely on (ab)use of setTimeout to avoid writing too much
> into the underlying buffer. I wouldn't consider a 1s flow disruption delay
> to be acceptable for this use case, not even in the background. Are there
> any plans to prevent such issues?
>
> On Wednesday, 3 August 2022 at 15:50:48 UTC+2 Etienne Pierre-doray wrote:
>
>> etie...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>>
>> Design docs
>>
>> https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit
>>
>> Summary
>>
>> Run all timers (with a few exceptions) with a non-zero delay on a regular
>> 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed.
>> This affect DOM timers; On foreground pages, run DOM timers with a non-zero
>> delay on a regular 8ms aligned wake up, instead of as soon as their delay
>> has passed. On background pages, DOM timers already run on a regular 1s
>> aligned wake up (1 Hz), or even less frequently after 5 minutes.
>>
>>
>> Blink componentBlink>Scheduling
>> 
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> This feature changes the behavior of an existing API in a way that is
>> spec-compliant (the spec says "Optionally, wait a further
>> implementation-defined length of time", ref.:
>> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout).
>> Content that relies on precise timing for DOM Timers may stop working
>> properly in Chromium with this feature. The risk is mitigated by delaying
>> DOM Timers by at most 8 ms, and by disabling the feature when WebRTC has
>> active connections in the process. Content that cannot support a 8 ms delay
>> would probably be better served by alternative APIs described at
>> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds.
>> Due to the significant battery savings that come with this feature, we
>> expect that most browsers will decide to implement it after some time.
>>
>>
>> *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?
>>
>>
>>
>> Goals for experimentation
>>
>> Gain insight on potential compatibility issues and evaluate impact on
>> guardian metrics (page load, latency).
>>
>>
>> Reason this experiment is being extended
>>
>>
>>
>> Ongoing technical constraints
>>
>>
>>
>> Debuggability
>>
>> This changes the behavior of an existing API. No new debugging support is
>> added.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No
>>
>> DevTrial instructions
>> https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md
>>
>> Flag namealign-wakeups
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://crbug.com/1153139
>>
>> Estimated milestones
>> OriginTrial desktop last 105
>> OriginTrial desktop first 105
>> DevTrial on desktop 105
>> OriginTrial A

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

[Chris Harrelson]

LGTM

On Tue, Aug 2, 2022 at 10:44 AM Mike Taylor  wrote:

> *Hi there,*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * We would like to extend the User-Agent Reduction OT again, from M104 to
> M106 (inclusive). The original extension expired on July 26th. We’ve heard
> from several partners that they would like to have more time to test the
> fully reduced UA string ahead of Phase 5 and Phase 6 rollouts.  Original
> I2E https://groups.google.com/a/chromium.org/g/blink-dev/c/R0xKm1B7qoQ/
> 
> First I2EE
> https://groups.google.com/a/chromium.org/g/blink-dev/c/6x6WH2Odzfo/m/FkDjee5cHQAJ
> 
> Experiment Timeline M103-M106 inclusive Reason this experiment is being
> extended Like the previous extension, we believe the risks for burn-in
> don't apply, because this OT just enables what we are planning to ship as
> default behavior in the future (and the OT stopped working last week). We
> still have not received negative feedback or reports of breaking from OT
> participants, and are encouraged by that fact. Here’s the relevant info
> required for OT extensions beyond 6 milestones: Draft spec:  -
> https://compat.spec.whatwg.org/#ua-string-chrome
>   - We’ve made solid
> progress against the open UA string issues, and have documented the recent
> landing of “Phase 4” in Chromium. We plan to continue improving things
> here. TAG review: - https://github.com/w3ctag/design-reviews/issues/640
>  - closed as
> “Satisfied with concerns” bit.ly/blink-signals
>  requests - Gecko: Shipped/Shipping. Firefox
> has frozen (or capped) much of their UA string already. - WebKit:
> Shipped/Shipping. Safari has already frozen everything in their UA string
> except for version number info. - Web developers: Mixed signals. Reactions
> have ranged from positive to indifferent to negative, from various
> channels. WPT tests - None yet, since UAs have flexibility to diverge
> here. With more alignment, this may make sense in the future. Thanks, Mike *
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8484ed9c-dc87-5a46-a145-6289921c9b77%40chromium.org
> 
> .
>

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

[blink-dev] Re: Intent to Experiment: Align Timers (including DOM timers) at 125 Hz

[Lennart Grahl]

Question: What about APIs that have no proper flow control support, e.g. 
WebSocket? They rely on (ab)use of setTimeout to avoid writing too much 
into the underlying buffer. I wouldn't consider a 1s flow disruption delay 
to be acceptable for this use case, not even in the background. Are there 
any plans to prevent such issues?

On Wednesday, 3 August 2022 at 15:50:48 UTC+2 Etienne Pierre-doray wrote:

> etie...@chromium.org
>
> ExplainerNone
>
> Specification
> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>
> Design docs
>
> https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit
>
> Summary
>
> Run all timers (with a few exceptions) with a non-zero delay on a regular 
> 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed. 
> This affect DOM timers; On foreground pages, run DOM timers with a non-zero 
> delay on a regular 8ms aligned wake up, instead of as soon as their delay 
> has passed. On background pages, DOM timers already run on a regular 1s 
> aligned wake up (1 Hz), or even less frequently after 5 minutes.
>
>
> Blink componentBlink>Scheduling 
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> This feature changes the behavior of an existing API in a way that is 
> spec-compliant (the spec says "Optionally, wait a further 
> implementation-defined length of time", ref.: 
> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout).
>  
> Content that relies on precise timing for DOM Timers may stop working 
> properly in Chromium with this feature. The risk is mitigated by delaying 
> DOM Timers by at most 8 ms, and by disabling the feature when WebRTC has 
> active connections in the process. Content that cannot support a 8 ms delay 
> would probably be better served by alternative APIs described at 
> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds. 
> Due to the significant battery savings that come with this feature, we 
> expect that most browsers will decide to implement it after some time.
>
>
> *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?
>
>
>
> Goals for experimentation
>
> Gain insight on potential compatibility issues and evaluate impact on 
> guardian metrics (page load, latency).
>
>
> Reason this experiment is being extended
>
>
>
> Ongoing technical constraints
>
>
>
> Debuggability
>
> This changes the behavior of an existing API. No new debugging support is 
> added.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests 
> 
> ?No
>
> DevTrial instructions
> https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md
>
> Flag namealign-wakeups
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1153139
>
> Estimated milestones
> OriginTrial desktop last 105
> OriginTrial desktop first 105
> DevTrial on desktop 105
> OriginTrial Android last 105
> OriginTrial Android first 105
> DevTrial on Android 105
> OriginTrial webView last 105
> OriginTrial webView first 105We plan to do a 1% Stable experiment for 
> M105 stable.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5680188671655936
>

-- 
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/270fd347-17a4-4601-9715-ef6f9fe6b4a9n%40chromium.org.

Re: [blink-dev] Intent to Prototype & Ship: Syntax changes to markup based Client Hints delegation

[slightlyoff via Chromestatus]

LGTM; thanks for clarifying.

-- 
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/03e4d105e55804ef%40google.com.

Re: [blink-dev] Intent to Experiment: Align Timers (including DOM timers) at 125 Hz

[Yoav Weiss]

What's the plan for monitoring potential breakage? Looking at incoming bugs?

On Wed, Aug 3, 2022 at 3:50 PM Etienne Pierre-doray 
wrote:

> etien...@chromium.org
>
> ExplainerNone
>
> Specification
> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>
> Design docs
>
> https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit
>
> Summary
>
> Run all timers (with a few exceptions) with a non-zero delay on a regular
> 8ms aligned wake up (125 Hz), instead of as soon as their delay has passed.
> This affect DOM timers; On foreground pages, run DOM timers with a non-zero
> delay on a regular 8ms aligned wake up, instead of as soon as their delay
> has passed. On background pages, DOM timers already run on a regular 1s
> aligned wake up (1 Hz), or even less frequently after 5 minutes.
>
>
> Blink componentBlink>Scheduling
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> This feature changes the behavior of an existing API in a way that is
> spec-compliant (the spec says "Optionally, wait a further
> implementation-defined length of time", ref.:
> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout).
> Content that relies on precise timing for DOM Timers may stop working
> properly in Chromium with this feature. The risk is mitigated by delaying
> DOM Timers by at most 8 ms, and by disabling the feature when WebRTC has
> active connections in the process. Content that cannot support a 8 ms delay
> would probably be better served by alternative APIs described at
> https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds.
> Due to the significant battery savings that come with this feature, we
> expect that most browsers will decide to implement it after some time.
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>

Might be worthwhile to ask: https://bit.ly/blink-signals


>
> *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?
>
>
>
> Goals for experimentation
>
> Gain insight on potential compatibility issues and evaluate impact on
> guardian metrics (page load, latency).
>
>
> Reason this experiment is being extended
>
>
>
> Ongoing technical constraints
>
>
>
> Debuggability
>
> This changes the behavior of an existing API. No new debugging support is
> added.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> DevTrial instructions
> https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md
>
> Flag namealign-wakeups
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1153139
>
> Estimated milestones
> OriginTrial desktop last 105
> OriginTrial desktop first 105
> DevTrial on desktop 105
> OriginTrial Android last 105
> OriginTrial Android first 105
> DevTrial on Android 105
> OriginTrial webView last 105
> OriginTrial webView first 105We plan to do a 1% Stable experiment for
> M105 stable.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5680188671655936
>
> --
> 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/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%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/CAL5BFfX%2BV3Rx324m_-9TMrjHid%2BrQj1qMbFwjZyuY-%3Df5qpbnQ%40mail.gmail.com.

[blink-dev] Intent to Experiment: Align Timers (including DOM timers) at 125 Hz

[Etienne Pierre-doray]

etien...@chromium.org

ExplainerNone

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

Design docs
https://docs.google.com/document/d/1OjZoHNvn_vz6bhyww68B_KZBi6_s5arT8xMupuNEnDM/edit

Summary

Run all timers (with a few exceptions) with a non-zero delay on a regular
8ms aligned wake up (125 Hz), instead of as soon as their delay has passed.
This affect DOM timers; On foreground pages, run DOM timers with a non-zero
delay on a regular 8ms aligned wake up, instead of as soon as their delay
has passed. On background pages, DOM timers already run on a regular 1s
aligned wake up (1 Hz), or even less frequently after 5 minutes.


Blink componentBlink>Scheduling


TAG review

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This feature changes the behavior of an existing API in a way that is
spec-compliant (the spec says "Optionally, wait a further
implementation-defined length of time", ref.:
https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#run-steps-after-a-timeout).
Content that relies on precise timing for DOM Timers may stop working
properly in Chromium with this feature. The risk is mitigated by delaying
DOM Timers by at most 8 ms, and by disabling the feature when WebRTC has
active connections in the process. Content that cannot support a 8 ms delay
would probably be better served by alternative APIs described at
https://developer.chrome.com/blog/timer-throttling-in-chrome-88/#workarounds.
Due to the significant battery savings that come with this feature, we
expect that most browsers will decide to implement it after some time.


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



Goals for experimentation

Gain insight on potential compatibility issues and evaluate impact on
guardian metrics (page load, latency).


Reason this experiment is being extended



Ongoing technical constraints



Debuggability

This changes the behavior of an existing API. No new debugging support is
added.


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

Is this feature fully tested by web-platform-tests

?No

DevTrial instructions
https://github.com/eti-p-doray/align-wakeups/blob/main/HOWTO.md

Flag namealign-wakeups

Requires code in //chrome?False

Tracking bughttps://crbug.com/1153139

Estimated milestones
OriginTrial desktop last 105
OriginTrial desktop first 105
DevTrial on desktop 105
OriginTrial Android last 105
OriginTrial Android first 105
DevTrial on Android 105
OriginTrial webView last 105
OriginTrial webView first 105We plan to do a 1% Stable experiment for M105
stable.

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

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

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

[Manuel Rego Casasnovas]

LGTM3

On 03/08/2022 10:12, Yoav Weiss wrote:
> LGTM2 to remove!
> 
> On Wed, Aug 3, 2022 at 3:41 AM Mike Taylor  > wrote:
> 
> Hi Ayu,
> 
> Thanks for digging into usage! I'm encouraged by the fact that
> browserfs (even if not actively maintained) does do internal feature
> detection
> 
> ,
> and supports multiple storage API backends
>  in case a site does
> run into trouble.
> 
> LGTM1 to remove window.webkitStorageInfo
> 
> 
> On 8/2/22 6:20 PM, Ayu Ishii wrote:
>> Hi Daniel,
>>
>> Looking through websites I was able to observe from HTTPArchive,
>> here are some usage patterns I was able to see.
>> Most were used via js libraries listed below. Most usages check if
>> window.webkitStorageInfo exists before usage.
>> Thanks!
>>
>> window.webkitStorageInfo.requestQuota (163 total urls)
>>
>>  *
>>
>> 90 urls - browserfs 
>> - not actively worked on
>>
>>  *
>>
>> 38 urls - dojo  - old
>> version / checks if exists first
>>
>>  *
>>
>> 12 urls - mymonero js
>>  - old version /
>> checks if exists first
>>
>>  *
>>
>> 6 urls - sencha ext js
>>  - old version?
>>
>>  *
>>
>> 16 urls remain (8 checks if exists first)
>>
>>
>> window.webkitStorageInfo.queryUsageAndQuota (285 total urls)
>>
>>  *
>>
>> 237 urls - twitter share js (example
>> )
>> - checks if exists first
>>
>>  *
>>
>> 38 urls - dojo  - checks if exists first
>>
>>  *
>>
>> 2 urls - meteor.js  - checks if
>> exists first
>>
>>  *
>>
>> 8 urls remain (6 checks if exists first)
>>
>>
>> On Wednesday, July 27, 2022 at 8:19:45 AM UTC-7 Daniel Bratell wrote:
>>
>> The low usage counters indicate that this is something that
>> could relatively safely be removed, though I wonder if you
>> have taken a look at any of the sites listed with the usage
>> counter?
>>
>> /Daniel
>>
>> On 2022-07-26 23:26, Ayu Ishii wrote:
>>> *Contact emails
>>> *a...@chromium.org  
>>>
>>> *Specification
>>> *https://storage.spec.whatwg.org/
>>> 
>>>
>>> *Summary
>>> *We propose to remove the following prefixed quota API,
>>> window.webkitStorageInfo in M106.
>>>
>>>  *
>>>
>>> window.webkitStorageInfo.queryUsageAndQuota()
>>>
>>>  *
>>>
>>> window.webkitStorageInfo.requestQuota()
>>>
>>> The deprecation thread predates the Intent process, but has
>>> been marked as deprecated since 2013
>>> (https://bugs.webkit.org/show_bug.cgi?id=88396
>>> ).
>>>
>>> *Blink component
>>> *Blink>Storage>Quota
>>> 
>>> 
>>>
>>> *Motivation
>>> *Chrome proposed and implemented
>>>  the prefixed quota API
>>> in 2011, which was immediately succeeded by the Quota API
>>>  which has
>>> since been deprecated as well. The legacy storage quota API
>>> was never implemented by any other browser, and has been
>>> showing a deprecation warning since 2013. Rather than
>>> investing more support on these legacy APIs, we propose to
>>> remove it entirely.
>>>
>>> *Search tags
>>> *legacy ,
>>> quota , storage
>>> 
>>>
>>> *TAG review
>>> *N/A
>>>
>>> *Risks
>>> *We previously made an attempt to remove
>>> window.webkitStorageInfo in 2017 (I2D
>>> 
>>> ).
>>> Since then, the modern quota API navigator.storage.estimate()
>>> shows increased adoption while window.webkitStorageInfo usage
>>> has decreased.
>>>
>>> The top level use counter (PrefixedStorageInfo
>>> )
>>> still reports 0.6% of page loads, but we think this can’t be
>>> trusted since enumeration of globa

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

[Yoav Weiss]

LGTM2 to remove!

On Wed, Aug 3, 2022 at 3:41 AM Mike Taylor  wrote:

> Hi Ayu,
>
> Thanks for digging into usage! I'm encouraged by the fact that browserfs
> (even if not actively maintained) does do internal feature detection
> ,
> and supports multiple storage API backends
>  in case a site does run
> into trouble.
>
> LGTM1 to remove window.webkitStorageInfo
>
>
> On 8/2/22 6:20 PM, Ayu Ishii wrote:
>
> Hi Daniel,
>
> Looking through websites I was able to observe from HTTPArchive, here are
> some usage patterns I was able to see.
> Most were used via js libraries listed below. Most usages check if
> window.webkitStorageInfo exists before usage.
> Thanks!
>
> window.webkitStorageInfo.requestQuota (163 total urls)
>
>-
>
>90 urls - browserfs  - not
>actively worked on
>-
>
>38 urls - dojo  - old version
>/ checks if exists first
>-
>
>12 urls - mymonero js  -
>old version / checks if exists first
>-
>
>6 urls - sencha ext js  - old
>version?
>-
>
>16 urls remain (8 checks if exists first)
>
>
> window.webkitStorageInfo.queryUsageAndQuota (285 total urls)
>
>-
>
>237 urls - twitter share js (example
>) -
>checks if exists first
>-
>
>38 urls - dojo - checks if exists first
>-
>
>2 urls - meteor.js  - checks if exists first
>-
>
>8 urls remain (6 checks if exists first)
>
>
> On Wednesday, July 27, 2022 at 8:19:45 AM UTC-7 Daniel Bratell wrote:
>
>> The low usage counters indicate that this is something that could
>> relatively safely be removed, though I wonder if you have taken a look at
>> any of the sites listed with the usage counter?
>>
>> /Daniel
>> On 2022-07-26 23:26, Ayu Ishii wrote:
>>
>>
>> *Contact emails *a...@chromium.org
>>
>>
>> *Specification *https://storage.spec.whatwg.org/
>>
>>
>> *Summary *We propose to remove the following prefixed quota API,
>> window.webkitStorageInfo in M106.
>>
>>-
>>
>>window.webkitStorageInfo.queryUsageAndQuota()
>>-
>>
>>window.webkitStorageInfo.requestQuota()
>>
>> The deprecation thread predates the Intent process, but has been marked
>> as deprecated since 2013 (https://bugs.webkit.org/show_bug.cgi?id=88396).
>>
>> *Blink component *Blink>Storage>Quota
>> 
>>
>>
>> *Motivation *Chrome proposed and implemented
>>  the prefixed quota API in 2011,
>> which was immediately succeeded by the Quota API
>>  which has since been
>> deprecated as well. The legacy storage quota API was never implemented by
>> any other browser, and has been showing a deprecation warning since 2013.
>> Rather than investing more support on these legacy APIs, we propose to
>> remove it entirely.
>>
>>
>> *Search tags *legacy ,
>> quota , storage
>> 
>>
>>
>> *TAG review *N/A
>>
>>
>> *Risks *We previously made an attempt to remove window.webkitStorageInfo
>> in 2017 (I2D
>> ).
>> Since then, the modern quota API navigator.storage.estimate() shows
>> increased adoption while window.webkitStorageInfo usage has decreased.
>>
>> The top level use counter (PrefixedStorageInfo
>> ) still
>> reports 0.6% of page loads, but we think this can’t be trusted since
>> enumeration of global properties is common and will tick the counter. The
>> actual  usage of the methods on webkitStorageInfo: is significantly lower:
>>
>>-
>>
>>window.webkitStorageInfo.queryUsageAndQuota()
>> -
>>0.000632%
>>-
>>
>>window.webkitStorageInfo.requestQuota()
>> -
>>0.000172%
>>
>> As a replacement for window.webkitStorageInfo.queryUsageAndQuota(), we
>> recommend using the now standardized navigator.storage.estimate()
>> .
>> This has been added to Chrome since M61, and adopted by Firefox since M57.
>>
>> window.webkitStorageinfo.requestQuota() will not have a recommended
>> replacement. Although navigator.webkitXXXStorage.requestQuota()
>> 

Re: [blink-dev] Intent to Extend Experiment 2: Web app launch handler

['Thomas Steiner' via blink-dev]

Updated the developer-facing article according to the changes:
https://github.com/GoogleChrome/developer.chrome.com/pull/3368. Note that
the explainer still mentions the old syntax.

On Wed, Aug 3, 2022 at 9:49 AM Alan Cutter  wrote:

>
> *Contact emails*alancut...@chromium.org
>
>
> *Original I2E*
> https://groups.google.com/a/chromium.org/g/blink-dev/c/wNOClobsLrs
>
>
> *Explainer*https://github.com/WICG/sw-launch/blob/main/launch_handler.md
>
>
> *Specification*Draft: https://wicg.github.io/sw-launch/
>
>
> *Summary*Adds a "launch_handler" app manifest member that enables web
> apps to customise their launch behaviour across all types of app launch
> triggers (start menu launch, link capture, share target, etc.).
>
> Example usage:
> {
>   "name": "Example app",
>   "start_url": "/index.html",
>   "launch_handler": {
> "client_mode": "navigate-existing"
>   }
> }
> This will cause all launches of the Example app to focus an existing app
> window and navigate it (if it exists) instead of always launching a new app
> window.
>
>
> *Blink component*Blink>AppManifest
> 
>
> *TAG review*
> https://github.com/w3ctag/design-reviews/issues/683
>
>
> *TAG review status*Closed. Satisfied to see this move ahead but keeping
> in mind compatibility with the MiniApp lifecycle
> .
>
> *Risks:*
> *Interoperability and Compatibility*
>  - Gecko: No signal
> 
>  - WebKit: No signal
> 
>  - Web developers: Strong positive signals on the previous Declarative
> Link Capturing origin trial
> ,
> strong positive signals from the origin trial so far
> 
> .
>
>
> *Experiment Summary*Web App Launch Handler Origin Trial 1 Developer
> Feedback
> 
>
>
> *Experiment Goals* - Expose the new client_mode
>  syntax.
>  - Validate attempts to fix bad interactions with share target
> .
>
>
> *Experiment Timeline*Previous: M103 to M106.
> Requested: M107 to M110.
>
>
> *Reason this experiment is being extended*- The route_to field has been
> renamed to client_mode along with all its values (breaking change).
> - We uncovered a bad interaction with share target
>  that requires spec change
> to resolve.
>
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?*No, desktop only.
>
> *Is this feature fully tested by* web-platform-tests
> 
> *?*No, this requires browser_tests
> 
>  as
> it involves managing windows.
> Have raised an issue
>  with
> testdriver.js for web app specific support.
>
>
> *Flag name*chrome://flags/#enable-desktop-pwas-launch-handler
> kWebAppEnableLaunchHandler
> 
>
>
> *Tracking bug*
> https://bugs.chromium.org/p/chromium/issues/detail?id=1231886
>
>
> *Link to entry on the Chrome Platform Status*
> https://www.chromestatus.com/feature/5722383233056768
>
> *Previous blink-dev threads*
> Intent to Prototype
> 
> Intent to Experiment
> 
> Request to Extend Experiment
> 
>  (rejected)
> Intent to Extend Experiment: Web app launch handler
>  (extended
> to M106)
> Since the last extension there is now a spec draft
> , some breaking API changes
>  and a broken interaction with 
> share
> target  that needs spec work.
>
> --
> 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.

[blink-dev] Intent to Extend Experiment 2: Web app launch handler

[Alan Cutter]

*Contact emails*alancut...@chromium.org


*Original I2E*
https://groups.google.com/a/chromium.org/g/blink-dev/c/wNOClobsLrs


*Explainer*https://github.com/WICG/sw-launch/blob/main/launch_handler.md


*Specification*Draft: https://wicg.github.io/sw-launch/


*Summary*Adds a "launch_handler" app manifest member that enables web apps
to customise their launch behaviour across all types of app launch triggers
(start menu launch, link capture, share target, etc.).

Example usage:
{
  "name": "Example app",
  "start_url": "/index.html",
  "launch_handler": {
"client_mode": "navigate-existing"
  }
}
This will cause all launches of the Example app to focus an existing app
window and navigate it (if it exists) instead of always launching a new app
window.


*Blink component*Blink>AppManifest


*TAG review*
https://github.com/w3ctag/design-reviews/issues/683


*TAG review status*Closed. Satisfied to see this move ahead but keeping in
mind compatibility with the MiniApp lifecycle
.

*Risks:*
*Interoperability and Compatibility*
 - Gecko: No signal

 - WebKit: No signal

 - Web developers: Strong positive signals on the previous Declarative Link
Capturing origin trial
,
strong positive signals from the origin trial so far

.


*Experiment Summary*Web App Launch Handler Origin Trial 1 Developer Feedback



*Experiment Goals* - Expose the new client_mode
 syntax.
 - Validate attempts to fix bad interactions with share target
.


*Experiment Timeline*Previous: M103 to M106.
Requested: M107 to M110.


*Reason this experiment is being extended*- The route_to field has been
renamed to client_mode along with all its values (breaking change).
- We uncovered a bad interaction with share target
 that requires spec change to
resolve.


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

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

*?*No, this requires browser_tests

as
it involves managing windows.
Have raised an issue
 with testdriver.js
for web app specific support.


*Flag name*chrome://flags/#enable-desktop-pwas-launch-handler
kWebAppEnableLaunchHandler



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


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

*Previous blink-dev threads*
Intent to Prototype

Intent to Experiment

Request to Extend Experiment

 (rejected)
Intent to Extend Experiment: Web app launch handler
 (extended
to M106)
Since the last extension there is now a spec draft
, some breaking API changes
 and a broken interaction with share
target  that needs spec work.

-- 
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/CANJJ2CmyiSPHr-f0RXVpmuja-H1bTQik-3B-hkBK90Q-FqwJag%40mail.gmail.com.