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

[Stefan Zager]

On Tue, Sep 6, 2022 at 3:26 PM Morgaine (de la faye) 
wrote:

> I don't love this at all. A more flexible batching/coalescing that *can*
> batch/coalesce when it makes sense, but which preserves the desired/asked
> for wake-ups when they are all alone & there's nothing to coalesce to would
> be far more reasonable/kind. This feels like it applies a huge cudgel to
> all users because some users use too many wakeups. I think most of the
> expected power savings can be gotten for the bad users, without such a vast
> & sad negative impact for the responsible users. Linux gained a similar
> "Tickless" kernel support capability in 2.6.6, May 2004, and this feels
> like a significant reversion to a state of tech far predating that basic
> innovation. I cannot support the sacrifices made here. Please do a little
> more work on this to only impact bad users/places where this might help;
> not everyone.
>

Can you give an example where it's important to have greater precision?
Even now, timers are not guaranteed to be serviced exactly when they expire
-- a browser is not a real-time OS -- so what is actually lost?

I'm not sure what "media timing" is exactly, but if you need precise
elapsed time, then performance.now() is the recommended approach.

As for aligning with display refresh rate: a timer will never do better
than requestAnimationFrame in this regard.


>
> Couple other details:
>
> Can authors still expect long term guarantees? If I request 10ms
> setInterval, and then write a counter that counts to a thousand, will ~10s
> have passed to get there? Folks doing media-timing rely on their
> setIntervals being wall-clock stable-ish; does this significant change
> threaten that?
>
> 125Hz is going to serve up tick at least once per frame up to 120hHz. But
> the amount of available execution time before frame is going to phase in &
> out of sync (at almost any display rate frequency) such that there are
> times there is plenty of execution time, & times when it is happening right
> near where the frame tick would be. This spec seems like might increases
> the probability of jank occurring at regular intervals.
>
> In general I think this tick rate would have been a good target for 2015,
> but that we are hoping to build more snappy & responsive systems. 250Hz
> would be a better tick rate, coming with 4ms potential delays rather than
> 8ms.
> On Wednesday, August 3, 2022 at 9:50:48 AM UTC-4 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 support

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

[Morgaine (de la faye)]

 I don't love this at all. A more flexible batching/coalescing that *can* 
batch/coalesce when it makes sense, but which preserves the desired/asked 
for wake-ups when they are all alone & there's nothing to coalesce to would 
be far more reasonable/kind. This feels like it applies a huge cudgel to 
all users because some users use too many wakeups. I think most of the 
expected power savings can be gotten for the bad users, without such a vast 
& sad negative impact for the responsible users. Linux gained a similar 
"Tickless" kernel support capability in 2.6.6, May 2004, and this feels 
like a significant reversion to a state of tech far predating that basic 
innovation. I cannot support the sacrifices made here. Please do a little 
more work on this to only impact bad users/places where this might help; 
not everyone.

Couple other details:

Can authors still expect long term guarantees? If I request 10ms 
setInterval, and then write a counter that counts to a thousand, will ~10s 
have passed to get there? Folks doing media-timing rely on their 
setIntervals being wall-clock stable-ish; does this significant change 
threaten that?

125Hz is going to serve up tick at least once per frame up to 120hHz. But 
the amount of available execution time before frame is going to phase in & 
out of sync (at almost any display rate frequency) such that there are 
times there is plenty of execution time, & times when it is happening right 
near where the frame tick would be. This spec seems like might increases 
the probability of jank occurring at regular intervals.

In general I think this tick rate would have been a good target for 2015, 
but that we are hoping to build more snappy & responsive systems. 250Hz 
would be a better tick rate, coming with 4ms potential delays rather than 
8ms.
On Wednesday, August 3, 2022 at 9:50:48 AM UTC-4 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
> D

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

[Mike Taylor]

LGTM2

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

LGTM1. Thanks for catching us up here!

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

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

*Explainer*

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

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

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

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

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

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

*Blink component*
Blink>Accessibility

*TAG review*

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

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

*WebKit:* Shipped/Shipping
(https://bugs.webkit.org/show_bug.cgi?id=220719)
*
**Web developers: *No signals

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

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

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

*Is this feature fully tested by web-platform-tests?*
Yes, https://github.com/web-platform-tests/wpt/pull/35323

*Flag name*

*Requires code in //chrome?*
False

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

*Estimated milestones*
No milestones specified

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

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

This intent message was generated by Chrome Platform Status.
-- 
You received this message because you are subscribed to the Google

Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0364a0d-8acc-7507-d765-8134f5efa50b%40igalia.com

.

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


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/178d519b-0cf0-15ee-21cc-10053819a9cd%40chromium.org.

[blink-dev] Intent to Prototype: Bounce Tracking Mitigations

[Ben Kelly]

Contact emailswanderv...@chromium.org, b...@chromium.org,
rtarp...@chromium.org, j...@chromium.org

Explainer
https://github.com/wanderview/bounce-tracking-mitigations/blob/main/explainer.md

Specification

Summary

We intend to prototype browser changes to mitigate bounce tracking on the
web. We do not have a final design yet, but this will likely involve
deleting storage from sites that appear to be bounce trackers when users
have blocked third-party cookies. See the explainer for more details.


Blink componentInternals>Network>Cookies


Motivation

Redirects can be used to implement cross-site tracking of users. In
addition, redirects can be used to simulate third-party cookies even when
the user has chosen to block third-party cookies. The primary goal of this
effort is to mitigate these privacy issues.


Initial public proposal

TAG review

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?



Debuggability



Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?True

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1360489

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1318210

Estimated milestones

No milestones specified


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

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/CAK7rkMi_7z0-yeTbBiE43V5SD1ri4jSVxrkR8Gs%3DD0NRoRKivA%40mail.gmail.com.

[blink-dev] PSA: Custom Handlers testing automation in ChromeDriver

[Javier Fernandez]

*Contact emails*
jfernan...@igalia.com

*Specification*
https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers

*Summary*
The proposed `setRPHRegistrationMode` WebDriver extension command places
the user agent in a mode where it will automatically accept or reject
(depending on the mode) future Custom Protocol Handlers registrations.
This allows full end-to-end testing of Custom Handlers API (eg,
registerProtocolHandler), which normally requires user interaction to
confirm the user's consent to the protocol registration.

I'm planning to implement and ship this testing feature, if there are no
objections.

There is an WIP PR that is still under consideration, and pending of
positive signals, or lack of objections, from implementors.
See https://github.com/whatwg/html/pull/8267 for more details.

*Motivation*
The HTML spec states in the Custom Handler section that user agents may
launch a prompt dialog during the registration of a custom protocol handler:

A user agent could, for instance, prompt the user and offer the user the
opportunity to add the site to a shortlist of handlers, or make the
handlers their default, or cancel the request. User agents could also
silently collect the information, providing it only when relevant to the
user.

Currently, there are only manual tests for the registerProtocolHandler
method:

https://github.com/web-platform-tests/wpt/blob/master/html/webappapis/system-state-and-capabilities/the-navigator-object/protocol-handler-fragment-nosw-manual.https.html

The main problem is that Chrome, and also Firefox, launch a prompt
dialog to ask the user for confirmation to register the protocol handler.

We could provide testing automation if we had a WebDriver extension
command that would autogrant or autoreject the registration request.

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

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

-- 
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/1ab06321-ce64-ccb5-08fb-05e42a38ebde%40igalia.com.

[blink-dev] Re: Ready for Trial: TLS ClientHello extension permutation

[Dennis Jackson]

We (Mozilla) are supportive of this experiment and are looking at doing 
something similar in Firefox. This work is tracked in 1789436 
. 

Kind regards,
Dennis

On Thursday, August 25, 2022 at 5:40:34 PM UTC+1 dad...@google.com wrote:

> Contact emailsdavi...@chromium.org, dad...@google.com
>
> Specificationhttps://datatracker.ietf.org/doc/rfc8446
>
> Design docs
>
> https://docs.google.com/document/d/1NIeWj_xFE3p7Q2IxVjnztO4_Aqih3VAskHlLYqDFjvk/edit?resourcekey=0-FCsdas1l23L830egKOun4A
>
> https://github.com/dadrian/clienthello-randomization/blob/main/EXPLAINER.md
>
> Summary
>
> Randomize the order of TLS ClientHello extensions, to reduce ossification.
>
>
> Blink componentInternals>Network>SSL 
> 
>
> TAG review
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> It is possible that Chrome’s ClientHello extension ordering is already 
> ossified. This change may cause compatibility issues with middleboxes or 
> other network monitoring software. We will do a slow rollout and monitor 
> breakage.
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> n/a, not developer facing
>
>
> Activation
>
> n/a, not developer facing
>
>
> Security
>
> Using a fixed extension order can encourage server implementers to 
> fingerprint Chrome and then assume specific implementation behavior. This 
> can limit ecosystem agility when Chrome implements future modifications to 
> TLS, if the server implementations are not prepared for Chrome to change 
> its ClientHello. Chrome will randomly order extensions, subject to the 
> pre_shared_key constraint in the RFC. This will reduce the risk of server 
> and middleboxes fixating on details of our current ClientHello. This should 
> make the TLS ecosystem more robust to changes. 
>
>
> 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
>
>
> Monitor breakage and complaints, if any.
>
> Ongoing technical constraints
>
>
> It is possible that the extension ordering is already ossified. This 
> change may cause compatibility issues with middleboxes. We will do a slow 
> rollout and monitor breakage.
>
> Debuggability
>
> n/a, inner function of TLS stack
>
>
> 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
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1351809
>
> Estimated milestones
> DevTrial on desktop 106
> DevTrial on Android 106
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5124606246518784
>
> 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/4cb933c7-3dac-4c98-8020-2398c8ed3775n%40chromium.org.

[blink-dev] Finish signing up to Help Center

[Help Center]

Almost done!

Follow the link below to finish signing up to Help Center. For security, don't 
share this link with anyone.

https://jirahieu.atlassian.net/servicedesk/customer/user/complete-signup?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJxc2giOiJjYzczNjQ0YTcwMTJlYWIyYjgzZTEwNWZmZDVjZWJmY2VmMzYwNGFlMTlkNDI0M2I4MTUwOWMzOGM4MzA0YzU2IiwiaXNzIjoic2VydmljZWRlc2stand0LXRva2VuLWlzc3VlciIsImNvbnRleHQiOnsidXNlciI6IjEwMDMxIiwiZXhwaXJ5IjoiMTY2MzA1Nzc5MCIsInBvcnRhbElkIjoiMiJ9LCJleHAiOjE2NzgwMDQ5OTAsImlhdCI6MTY2MjQ1Mjk5MH0.oWIxXh29gWCq7TCH0V-aAaI5XYa_I6WvG7I1CV4GpOk




-
Powered by Jira Service Management
https://www.atlassian.com/software/jira/service-desk/powered-by?utm_medium=jira-in-product&utm_source=jira_service_desk_email_footer&utm_content=jirahieu

-- 
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/JIRA.b6c635dc-d9c3-4fc2-83a5-f1cc097a739c.1662452990998%40Atlassian.JIRA.

[blink-dev] Finish signing up to Help Center

[Help Center]

Almost done!

Follow the link below to finish signing up to Help Center. For security, don't 
share this link with anyone.

https://jirahieu.atlassian.net/servicedesk/customer/user/complete-signup?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJxc2giOiJjYzczNjQ0YTcwMTJlYWIyYjgzZTEwNWZmZDVjZWJmY2VmMzYwNGFlMTlkNDI0M2I4MTUwOWMzOGM4MzA0YzU2IiwiaXNzIjoic2VydmljZWRlc2stand0LXRva2VuLWlzc3VlciIsImNvbnRleHQiOnsidXNlciI6IjEwMDMxIiwiZXhwaXJ5IjoiMTY2MzA1Nzc5NCIsInBvcnRhbElkIjoiMiJ9LCJleHAiOjE2NzgwMDQ5OTQsImlhdCI6MTY2MjQ1Mjk5NH0.VHMJ1x1YoL146qXf2lDmJ2_giaKwdHwWujLzO-lKUD8




-
Powered by Jira Service Management
https://www.atlassian.com/software/jira/service-desk/powered-by?utm_medium=jira-in-product&utm_source=jira_service_desk_email_footer&utm_content=jirahieu

-- 
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/JIRA.01f6482e-2bbc-43de-a0ee-16009f0ba4bd.1662452994716%40Atlassian.JIRA.

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Yoav Weiss]

SG! My LGTM still stands :)

On Tue, Sep 6, 2022 at 3:52 PM Dave Tapuska  wrote:

> BFCache has different behavior. Pages are evicted if an extension tries to
> communicate with something that is in the cache. We did outreach to help
> increase BFCache rates because we know what extensions cause eviction.
>
> In terms of prerender it is different because extensions can modify/block
> content on the page and you really need to do this during the prerender
> phase to really do what an extension wants. It is difficult to quantify
> which extensions could be broken, but we did do some testing of popular
> extensions and discovered no problems. We have finch and enterprise policy
> fail safes in place if we do run into something in the wild that is causing
> significant issues.
>
> dave.
>
> On Mon, Sep 5, 2022 at 5:33 AM Yoav Weiss  wrote:
>
>> Thanks!! Were extensions affected by previous multi-page arch shipped
>> features, such as BFCache?
>> Is there a way for us to scan the various extension stores, look for
>> patterns that would be affected by this change and notify the extension's
>> authors ahead of time?
>>
>> On Thu, Sep 1, 2022 at 4:23 PM Dave Tapuska 
>> wrote:
>>
>>> I drafted a blog post highlighting the additions/changes to the
>>> extension APIs. It is just going through reviews before being posted to
>>> developer.chrome.com, hopefully sometime next week.
>>>
>>> dave.
>>>
>>> On Thu, Sep 1, 2022 at 2:49 AM Yoav Weiss 
>>> wrote:
>>>


 On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
 wrote:

> Thank you for the feedback.
>
> Yes, the Extensions is the thing we have paid the biggest attention to
> support Prerendering on Desktop.
>
> https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
> This is the document we discussed especially on Prerendering and
> Extensions. In the design discussion we tried finding the best choice to
> minimize possible compatibility breakage for most Extensions, but at the
> same time, we understood it's unavoidable that some Extensions may be
> surprised to see unexpected prerendering pages.
>
> So, our prepared mitigations are
> - Enterprise Policy to disable Prerendering completely
> - Users' report based incompatible Chrome Extensions list that
> disables Prerendering when a user installs one in the list.
>

 That sounds reasonable, but I wonder if more communication to the
 extensions community is warranted.

 +Simeon Vincent  for thoughts


>
> It minimizes the risk to block the rollout for such unexpected
> Extensions compatibility breakages.
>
> For more visibility, here is the crbug entry to report such
> incompatible Extensions quickly.
> https://bugs.chromium.org/p/chromium/issues/detail?id=1351312
>
> 
> T 
> hanks!
>
> On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell 
> wrote:
>
>> In addition to the LGTM, I want to point out that during our
>> discussion among the API Owners, we did specifically wonder about 
>> extension
>> compatibility. Since this will change things for extensions, I think it
>> will be important to look for compatibility problems popping up, and, if
>> necessary, delay until any such problems are fully understood.
>>
>> /Daniel
>> On 2022-08-31 16:34, Daniel Bratell wrote:
>>
>> LGTM3
>>
>> /Daniel
>> On 2022-08-30 10:58, Yoav Weiss wrote:
>>
>> LGTM2 to expand support for desktop.
>>
>> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent 
>> wrote:
>>
>>> LGTM1.
>>> It's pretty safe to expand support to desktop platforms, and it
>>> seems there are no negative signals.
>>>
>>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

 toyos...@chromium.org, angelrapo...@google.com

 Explainer

 This I2S aims to expand our efforts on Prerender2 (currently
 shipped only on Android) to Desktop.

 The full prerendering revamped explainer can be found at

 https://github.com/WICG/nav-speculation/blob/main/README.md

 Specification

 https://wicg.github.io/nav-speculation/prerendering.html

 Design docs


 https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs

 Summary

 Prerendering is “pre”-rendering, it’s about pre-loading and
 rendering a Web page before the user actually navigates to it. The main
 goal of prerendering is to make the next page navigation faster, or 
 ideally
 nearly 

Re: [blink-dev] Intent to Ship: Prerender2 for Desktop

[Dave Tapuska]

BFCache has different behavior. Pages are evicted if an extension tries to
communicate with something that is in the cache. We did outreach to help
increase BFCache rates because we know what extensions cause eviction.

In terms of prerender it is different because extensions can modify/block
content on the page and you really need to do this during the prerender
phase to really do what an extension wants. It is difficult to quantify
which extensions could be broken, but we did do some testing of popular
extensions and discovered no problems. We have finch and enterprise policy
fail safes in place if we do run into something in the wild that is causing
significant issues.

dave.

On Mon, Sep 5, 2022 at 5:33 AM Yoav Weiss  wrote:

> Thanks!! Were extensions affected by previous multi-page arch shipped
> features, such as BFCache?
> Is there a way for us to scan the various extension stores, look for
> patterns that would be affected by this change and notify the extension's
> authors ahead of time?
>
> On Thu, Sep 1, 2022 at 4:23 PM Dave Tapuska  wrote:
>
>> I drafted a blog post highlighting the additions/changes to the extension
>> APIs. It is just going through reviews before being posted to
>> developer.chrome.com, hopefully sometime next week.
>>
>> dave.
>>
>> On Thu, Sep 1, 2022 at 2:49 AM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Thu, Sep 1, 2022 at 8:24 AM Takashi Toyoshima 
>>> wrote:
>>>
 Thank you for the feedback.

 Yes, the Extensions is the thing we have paid the biggest attention to
 support Prerendering on Desktop.

 https://docs.google.com/document/d/16Sy2Xq-AcnhwnpC0q232OMSmxTpQYDANRAO-zJ8DKiA/edit?usp=sharing
 This is the document we discussed especially on Prerendering and
 Extensions. In the design discussion we tried finding the best choice to
 minimize possible compatibility breakage for most Extensions, but at the
 same time, we understood it's unavoidable that some Extensions may be
 surprised to see unexpected prerendering pages.

 So, our prepared mitigations are
 - Enterprise Policy to disable Prerendering completely
 - Users' report based incompatible Chrome Extensions list that disables
 Prerendering when a user installs one in the list.

>>>
>>> That sounds reasonable, but I wonder if more communication to the
>>> extensions community is warranted.
>>>
>>> +Simeon Vincent  for thoughts
>>>
>>>

 It minimizes the risk to block the rollout for such unexpected
 Extensions compatibility breakages.

 For more visibility, here is the crbug entry to report such
 incompatible Extensions quickly.
 https://bugs.chromium.org/p/chromium/issues/detail?id=1351312

 
 T hanks!

 On Thu, Sep 1, 2022 at 6:20 AM Daniel Bratell 
 wrote:

> In addition to the LGTM, I want to point out that during our
> discussion among the API Owners, we did specifically wonder about 
> extension
> compatibility. Since this will change things for extensions, I think it
> will be important to look for compatibility problems popping up, and, if
> necessary, delay until any such problems are fully understood.
>
> /Daniel
> On 2022-08-31 16:34, Daniel Bratell wrote:
>
> LGTM3
>
> /Daniel
> On 2022-08-30 10:58, Yoav Weiss wrote:
>
> LGTM2 to expand support for desktop.
>
> On Tue, Aug 30, 2022 at 8:53 AM TAMURA, Kent 
> wrote:
>
>> LGTM1.
>> It's pretty safe to expand support to desktop platforms, and it
>> seems there are no negative signals.
>>
>> On Thu, Aug 18, 2022 at 4:07 PM 'Angel Raposo' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emails
>>>
>>> toyos...@chromium.org, angelrapo...@google.com
>>>
>>> Explainer
>>>
>>> This I2S aims to expand our efforts on Prerender2 (currently shipped
>>> only on Android) to Desktop.
>>>
>>> The full prerendering revamped explainer can be found at
>>>
>>> https://github.com/WICG/nav-speculation/blob/main/README.md
>>>
>>> Specification
>>>
>>> https://wicg.github.io/nav-speculation/prerendering.html
>>>
>>> Design docs
>>>
>>>
>>> https://docs.google.com/document/d/1EpLshvc9RRW3vswmXsJGrbCkhlFmxDsWfbvgxmYDTfs
>>>
>>> Summary
>>>
>>> Prerendering is “pre”-rendering, it’s about pre-loading and
>>> rendering a Web page before the user actually navigates to it. The main
>>> goal of prerendering is to make the next page navigation faster, or 
>>> ideally
>>> nearly instant.
>>>
>>> Sites can inform the user agent about which pages the user may
>>> likely visit, by asking to trigger a ‘prerendering’ for a particular URL
>>> (e.g. user is at page A and will likely navigate to page B nex