Re: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

['Olli Pettay' via blink-dev]

I am trying to land the change, so it should be in FF 128 Nightly soon, 
next week at latest. So hopefully we'll get feedback if it breaks something.
I don't think there is need for a standards-position for this particular 
small tweak.
(But the process of making this kind of breaking spec change was rather 
unusual.)


-Olli

On Friday, May 24, 2024 at 7:55:44 PM UTC+3 Daniel Clark wrote:

> Thanks Shuangshuang for clarifying what’s going on with these two separate 
> but related changes, and Olli for the update on 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343.
>
>  
>
> Since Gecko already implements the behavior of firing selectionchange on 
> input/textarea (confirmed here <https://glow-curvy-cerise.glitch.me/>), 
> sounds good to me to go ahead with shipping this change in Chromium (I’m 
> not an API owner though).
>
>  
>
> Separately, for the behavior of not firing duplicate selectionchange, it 
> might not hurt to go ahead and request an official Mozilla position on that 
> since it sounds like there’s still a bit of uncertainty about landing that 
> change given back compat concerns, unless Olli confirms here that the plan 
> is to go ahead and ship it.
>
>  
>
> -- Dan
>
>  
>
> *From:* Olli Pettay  
> *Sent:* Friday, May 24, 2024 12:26 AM
> *To:* blink-dev 
> *Cc:* Shuangshuang Zhou ; tk...@chromium.org <
> tk...@chromium.org>; mike...@chromium.org ; Daniel 
> Clark ; Olli Pettay 
> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch selectionchange event 
> per element
>
>  
>
> You don't often get email from ope...@mozilla.com. Learn why this is 
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> FWIW, I'm implementing the change in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1898343
>
> Need to still fix some tests, which do reveal how the spec change indeed 
> isn't fully backwards compatible.
>
> Hopefully it doesn't break any real web sites.
>
>  
>
>  
>
>  
>
> -Olli
>
>  
>
>  
>
> On Friday, May 24, 2024 at 10:05:47 AM UTC+3 Shuangshuang Zhou wrote:
>
> Hi Dan&Mike, I think we could submit a standard-position issue to Mozilla 
> for reducing duplicated events in our second CL(mentioned in my last 
> comment) for this feature. Because in the second CL, we might change the 
> current logic of dispatching selectionchange event. For this time, we might 
> just do it in chromium. WDYT? 
>
>  
>
> Thanks!
>
> On Friday, May 24, 2024 at 9:20:33 AM UTC+8 tk...@chromium.org wrote:
>
> LGTM1. 
>
> Firefox and Safari statuses are strong signals, and the compatibility risk 
> looks very low.
>
>  
>
>  
>
> On Thu, May 23, 2024 at 11:07 AM Shuangshuang Zhou  
> wrote:
>
> Hi Dan&Mike, for your concern that Firefox is still failing the WPTs at 
> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html,
>  
> that might be another issue. Let me make more explanation.
>
>  
>
> Actually, the final goal of w3c modifys the spec of selectionchange event 
> is to avoid firing duplicated selectionchange event which are not executed 
> yet on the same element(as Rniwa commented in his comment 
> <https://github.com/w3c/selection-api/issues/170#issuecomment-1956096554>). 
> Then in WebKit/WebCore, Rniwa submitted 2 CLs to achieve this ieda. The 
> first CL in WebKit is 276238@main <https://commits.webkit.org/276238@main>, 
> and in this CL they just modified the logic to fire selectionchange event 
> on input/textarea for the first step. Then the second CL in WebKit is 
> 276388@main <https://commits.webkit.org/276388@main>, which finally 
> avoided to fire duplicated selectionchange events according to the latest 
> spec on firing selectionchange event 
> <https://w3c.github.io/selection-api/#firing-selectionhange-event>.
>
>  
>
> So for this feature in Blink here , we also want to take 2 steps like 
> WebKit does that in the first CL we change to fire on input/textarea and 
> then sovle the duplicated events in the second CL. And those tests are 
> already modified to what both CLs are merged. So in the above test of 
> onselectionchange-on-distinct-text-controls.html, chrome and firefox should 
> be failed because only Safari has landed 2 CLs to avoid duplicated 
> selectionchange events. Or in other words, firefox might already dispatch 
> selectionchange event on elements but doesn't have the logic to avoid to 
> fire scheduled-but-not-executed events.  
>
>  
>
> For WebKit, currently the two CLs are both landed in Safari Technology 
> Preview 192(link 
> <https://developer.apple.com/documentation/sa

Re: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

['Olli Pettay' via blink-dev]

FWIW, I'm implementing the change in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1898343
Need to still fix some tests, which do reveal how the spec change indeed 
isn't fully backwards compatible.
Hopefully it doesn't break any real web sites.



-Olli


On Friday, May 24, 2024 at 10:05:47 AM UTC+3 Shuangshuang Zhou wrote:

> Hi Dan&Mike, I think we could submit a standard-position issue to Mozilla 
> for reducing duplicated events in our second CL(mentioned in my last 
> comment) for this feature. Because in the second CL, we might change the 
> current logic of dispatching selectionchange event. For this time, we might 
> just do it in chromium. WDYT?
>
> Thanks!
>
> On Friday, May 24, 2024 at 9:20:33 AM UTC+8 tk...@chromium.org wrote:
>
>> LGTM1.
>> Firefox and Safari statuses are strong signals, and the 
>> compatibility risk looks very low.
>>
>>
>> On Thu, May 23, 2024 at 11:07 AM Shuangshuang Zhou  
>> wrote:
>>
>>> Hi Dan&Mike, for your concern that Firefox is still failing the WPTs at 
>>> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html,
>>>  
>>> that might be another issue. Let me make more explanation.
>>>
>>> Actually, the final goal of w3c modifys the spec of selectionchange 
>>> event is to avoid firing duplicated selectionchange event which are not 
>>> executed yet on the same element(as Rniwa commented in his comment 
>>> <https://github.com/w3c/selection-api/issues/170#issuecomment-1956096554>). 
>>> Then in WebKit/WebCore, Rniwa submitted 2 CLs to achieve this ieda. The 
>>> first CL in WebKit is 276238@main 
>>> <https://commits.webkit.org/276238@main>, and in this CL they just 
>>> modified the logic to fire selectionchange event on input/textarea for the 
>>> first step. Then the second CL in WebKit is 276388@main 
>>> <https://commits.webkit.org/276388@main>, which finally avoided to fire 
>>> duplicated selectionchange events according to the latest spec on firing 
>>> selectionchange event 
>>> <https://w3c.github.io/selection-api/#firing-selectionhange-event>.
>>>
>>> So for this feature in Blink here , we also want to take 2 steps like 
>>> WebKit does that in the first CL we change to fire on input/textarea and 
>>> then sovle the duplicated events in the second CL. And those tests are 
>>> already modified to what both CLs are merged. So in the above test of 
>>> onselectionchange-on-distinct-text-controls.html, chrome and firefox should 
>>> be failed because only Safari has landed 2 CLs to avoid duplicated 
>>> selectionchange events. Or in other words, firefox might already dispatch 
>>> selectionchange event on elements but doesn't have the logic to avoid to 
>>> fire scheduled-but-not-executed events. 
>>>
>>> For WebKit, currently the two CLs are both landed in Safari Technology 
>>> Preview 192(link 
>>> <https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-192>),
>>>  
>>> but it might need some time to ship in Safari because Safari is updated 
>>> within OS updates.
>>> For the status in FireFox, I'll double-check and confirm with Tkent(one 
>>> reviewer of my first CL).
>>>
>>> Thanks,
>>> Shuangshuang
>>>
>>> On Thursday, May 23, 2024 at 9:29:59 AM UTC+8 mike...@chromium.org 
>>> wrote:
>>>
>>>> Yes, agree. Can we please request a position from Mozilla at 
>>>> https://github.com/mozilla/standards-positions/issues/new?
>>>> On 5/22/24 6:43 PM, 'Daniel Clark' via blink-dev wrote:
>>>>
>>>> Yeah, that’s what I was trying to get at – the Intent implies that 
>>>> Gecko has also shipped the breaking change but it seems that might not be 
>>>> the case.
>>>>
>>>>  
>>>>
>>>> If not, we should send a Request for Position to figure out whether 
>>>> there would be cross-browser alignment on shipping this.
>>>>
>>>>  
>>>>
>>>> -- Dan
>>>>
>>>>  
>>>>
>>>> *From:* Olli Pettay  
>>>> *Sent:* Wednesday, May 22, 2024 9:53 AM
>>>> *To:* blink-dev 
>>>> *Cc:* Daniel Clark ; Shuangshuang Zhou 
>>>> 
>>>> *Subject:* Re: [blink-dev] Intent to Ship: Dispatch selectionchange 
>>>> event per element
>>>>
>>>>  
>>>>
>>

Re: [blink-dev] Intent to Ship: Dispatch selectionchange event per element

['Olli Pettay' via blink-dev]

I think it is because of this rather surprising non-backwards compatible 
recent change.

On Wednesday, May 22, 2024 at 7:28:45 PM UTC+3 Daniel Clark wrote:

> The Gecko status is marked as Shipped/Shipping and the Interop/Compat 
> section mentions Firefox having shipped this, but Firefox is still failing 
> the WPTs at 
> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html
> .
>
> Can you help me understand the discrepancy there?
>
>  
>
> Thanks,
>
> Dan
>
>  
>
> *From:* blin...@chromium.org  *On Behalf Of 
> *Shuangshuang 
> Zhou
> *Sent:* Tuesday, May 21, 2024 10:24 PM
> *To:* blink-dev 
> *Subject:* [blink-dev] Intent to Ship: Dispatch selectionchange event per 
> element
>
>  
>
> You don't often get email from shuangsh...@intel.com. Learn why this is 
> important 
>
> *Contact emails*shuangsh...@intel.com
>
> *Explainer*None
>
> *Specification*https://w3c.github.io/selection-api/#selectionchange-event
>
> *Summary* 
>
> Dispatches selectionchange event per element when this 
> element(input/textarea) provides a text selection or its selection changes. 
> This is to match the latest specification of selectionchange event. This 
> also matches Safari behavior. 
>
>
>
> *Blink component*Blink>Editing>Selection 
> 
>
> *TAG review*None
>
> *TAG review status*Issues addressed
>
> *Risks* 
>
>
>
> *Interoperability and Compatibility* 
>
> Interoperability risk is low because Firefox and Safari have shipped this 
> according to the specification. Compatibility risk is low because the 
> selectionchange event targeting input/textarea would bubble up, and 
> existing codes listening on Document will work well as ever.
>
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping (https://commits.webkit.org/276238@main)
>
> *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?*
>
> Low WebView application risks.
>
>
>
> *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* 
> 
> *?*Yes 
>
>
> https://wpt.fyi/results/selection/onselectionchange-on-distinct-text-controls.html
>
>
>
> *Flag name on chrome://flags*None
>
> *Finch feature name*DispatchSelectionchangeEventPerElement
>
> *Requires code in //chrome?*False
>
> *Tracking bug*https://issues.chromium.org/issues/330766600
>
> *Estimated milestones*
> Shipping on desktop
> 127
>
> *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/5255454895898624?gate=6043023317401600
>
> 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+...@chromium.org.
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/de18f3c4-df5a-4423-80ec-e505e0c9fb2bn%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/b20c90aa-55df-456c-8587-732b4a96937fn%40chromium.org.

Re: [blink-dev] Intent to Ship: Opaque Response Blocking (ORB, aka CORB++) v0.2

[Olli Pettay]

Gecko has a variant of ORB enabled currently in early beta and earlier
https://bugzilla.mozilla.org/show_bug.cgi?id=1821682
We had full ORB, but had to relax the rules a bit similarly to what Blink
has done, if I understood correctly.
And there is also an experiment ongoing.

But I can't recall the details whether Gecko's implementation matches Blink
v0.2 exactly (and some folks are on vacation atm so I can't ask right now).


-Olli



On Tue, Jul 25, 2023 at 6:16 PM Dominic Farolino  wrote:

> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1532642)
>> In implementation.
>
>
> "In implementation" and "No signal" sound a little conflicting. Is the
> feature *definitely* being implemented in Firefox? Can we file for a
> proper standards signal to be sure?
>
> Specificationhttps://github.com/whatwg/fetch/pull/1442
>
>
> It looks like the spec PR here has been dormant for something like ~9
> months. Are there any plans to help drive it to the finish line,
> especially given the TODOs listed in the OP? How should we all think about
> whatever work might remain there, and possibly deviate from what Chrome
> plans on shipping?
>
> Is this feature fully tested by web-platform-tests
>> 
>> ?Yes (https://wpt.fyi/results/fetch/orb)
>>
>
> Just to double check, are we confident that the tests in that directory
> assert what the spec PR currently requires? I only ask because the spec has
> seemed quiet for a while (as mentioned above) and that makes it easy for
> things to accidentally get out of sync.
>
> On Tue, Jul 25, 2023 at 3:10 AM Yoav Weiss  wrote:
>
>>
>>
>> On Mon, Jul 24, 2023 at 7:27 PM Daniel Vogelheim 
>> wrote:
>>
>>> On Mon, Jul 24, 2023 at 5:55 PM Yoav Weiss 
>>> wrote:
>>>
 On Mon, Jul 24, 2023 at 5:44 PM Daniel Vogelheim 
 wrote:

> On Mon, Jul 24, 2023 at 5:24 PM Yoav Weiss 
> wrote:
>
>> On Fri, Jul 21, 2023 at 5:53 PM 'Daniel Vogelheim' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsvogelh...@chromium.org
>>>
>>> Specificationhttps://github.com/whatwg/fetch/pull/1442
>>>
>>> Summary
>>>
>>> Opaque Response Blocking (ORB) is a replacement for Cross-Origin
>>> Read Blocking (CORB -
>>> https://chromestatus.com/feature/5629709824032768). CORB and ORB
>>> are both heuristics that attempt to prevent cross-origin disclosure of
>>> “no-cors” subresources. This entry tracks "v0.2" of ORB - Chrome's 
>>> second
>>> step towards a full ORB implementation. ORB specifies error handling for
>>> blocked resources differently from CORB: ORB raises network errors, 
>>> while
>>> CORB injects an empty response. ORB "v0.1" still used CORB-style 
>>> response
>>> injection. This change brings our implementation more in line with the 
>>> ORB
>>> proposal, by changing the error handling of all fetches (except when
>>> initiated by a script) to be compliant with ORB. We've made a carve-out 
>>> for
>>> script-initiated fetches (where we retain CORB behaviour for now) to 
>>> limit
>>> compatibility risk.
>>>
>>>
>>> Blink componentInternals>Sandbox>SiteIsolation
>>> 
>>>
>>> TAG reviewNone
>>> (A TAG review of a particular aspect happened in:
>>> https://github.com/w3ctag/design-reviews/issues/618)
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> This release does not modify blocking behaviour, but only how a
>>> blocked resource is represented. Ideally, this change shouldn't break 
>>> any
>>> existing code since any resource that loads (or gets blocked) before 
>>> will
>>> continue to do so after. However, it is possible to distinguish between 
>>> the
>>> different types of error handling, and it may well happen that an
>>> application inadvertently relies on blocked resources "succeeding". In 
>>> our
>>> examinations so far, this chiefly concerns fetches using the `fetch()` 
>>> API,
>>> where blocking with a network error results in a failed promise 
>>> (instead of
>>> a success with an empty response). For this reason, we have carved out
>>> script-initiated fetches from "v0.2" and intend to handle them at a 
>>> later
>>> date.
>>>
>>
>> OK, so how would this change be web exposed? Are there scenarios
>> where an "error" event would now fire instead of a "load" event?
>>
>
> Yes, exactly. If a site is waiting for an onload event - despite not
> really caring about whether the load is actually meaningful, since it
> currently already loads empty - then it would see a behavioural change.
>
>
 Do we have stats on how oft

Re: [blink-dev] Intent to Ship: Anonymous iframes

[Olli Pettay]

On 11/10/22 10:33, 'Arthur Sonzogni' via blink-dev wrote:

Hi blink-dev,

*
*

We decided to address issue #5 : “rename anonymous iframe into iframe credentialless”. We will 
rename to .


For this adjustment to take place, the new plan is to ship in M110 instead of M109. We do not think the origin trial will need to be extended, since 
partners have been or will be able to test up to M108. Therefore, there will be a gap between the original trial and launch version.


However, renaming from anonymous to credentialless will not answer Mozilla's core argument. They believe that the feature would be best controlled via 
multiple new sandbox flags.


I don't think anyone from Mozilla has said that. What I have said is that the current way to control how iframes work is getting very complicated and 
the new attribute adds yet another mechanism. And if most of the users will use both sandbox and credentialless, understanding how those work together 
can be rather confusing. Also, credentialless isn't exposing the primitives itself, but some unique set of features. I'd rather see primitives to be

exposed and other features built on top of them.


-Olli


 We think it is much less ergonomic and makes the feature harder to explain to 
developers. The integration with sandbox
flags has challenging open questions around edge cases, as listed in this document 
.


*
*

Considering this, we think the current solution is a better one. We have feedback from partners that it solves their needs. Considering that we have 
no clear feedback Mozilla would be interested in implementing anonymous iframes even if they were spelled as sandbox flags, we believe we should ship 
with what we have implemented.



--
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/CAAzos5GDYwk7ohTD4Eq2TW43hU%3DrHfXsx2V7%2BVK%3DHdKNd02-TA%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/eaf7cf6c-b3a8-a263-3d32-47d373743540%40gmail.com.

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

[Olli Pettay]

On 10/20/22 18:23, Mike Taylor wrote:

On 10/19/22 8:05 PM, Etienne Pierre-doray wrote:



Contact emails

etien...@chromium.org


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 affects 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 component

Blink>Scheduling 



TAG review



TAG review status

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


Have we asked Mozilla for a signal?




I don't think so. I could say we're interested in trying to reduce wake-ups, but it is unclear how this 125Hz works in scenarios like when one has a 
very high refresh rate monitor (talking about monitors >250Hz). Browsers already struggle a bit in those cases in various ways. My gut feeling is that 
in those cases we'd rather try to schedule short timer runs between each rAF than every 8ms.



-Olli







/WebKit/: Neutral (https://github.com/WebKit/standards-positions/issues/44) Note that WebKit already has some DOM timer alignment logic (see 
Page::updateDOMTimerAlignmentInterval()), which depends on low power mode, page visibility and user interaction. It's also possible that there's 
some alignment logic at the platform level which is designed to reduce CPU wakeups.


/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

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 name

align-wakeups


Requires code in //chrome?

False


Tracking bug

https://crbug.com/1153139



Estimated milestones


DevTrial on desktop 105

DevTrial on Android 105

Chrome on desktop   107


Chrome on Android   107



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


This feature changes the behavior of an existing API in a way that is 
spec-compliant


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5680188671655936


Links to previous Intent discussions

Intent to Experiment: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALoDvsaQA8iqxdxNEh1PkBCzPFSsSSmZ72Jgmev-bdwenG6DrQ%40mail.gmail.com 



Related to this discussion ; we're now at step (3), the feature 
has been enabled at 100% on beta for almost 3 weeks, and M107 will soon roll out to stable.
Enabling the feature by default triggered crbug.com/1368989  (fuschia only, addressed), although this was unrelated to 

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Olli Pettay]

On 2/11/22 07:20, Kouhei Ueno wrote:

Contact emails

loading-...@chromium.org , 
noam.j.rosent...@gmail.com 


Component

Internals>Preload>Prerender


Explainer

https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md 




Spec

https://wicg.github.io/nav-speculation/prerendering.html
Discussion about upstreaming into HTML and elsewhere: whatwg/html#7533 




The corresponding TAG review is w3ctag/design-reviews#667 . (That review was for 
speculation-rules triggered prerendering, which has a superset of the considerations for omnibox-triggered prerendering.)



Summary

We would like to ship omnibox (i.e., URL bar) prerendering. With this feature, Chrome will start prerendering the high-confidence omnibox autocomplete 
suggestions. Chrome is currently prefetching resources for high-confidence suggestions using No-state Prefetch 
, but with this feature we will be further processing the webpage, including the 
DOM tree construction and script execution.



While this is a user agent feature, this is an observable change to the prerendered websites. This prerendering affects how the prerendered pages are 
processed. The website gets loaded before the navigation is committed, and the side-effects are delayed until activation (the actual navigation to the 
website was committed). We also would like to add a simple APIs (document.prerendering) to directly let the website know that it is being prerendered 
and when it was activated (prerenderingchange event, performance.activationStart timing).



Note that we are not shipping speculation rules triggered prerender2 (I2E extension 
) with this I2S, which allows web pages to prerender other web 
pages. We will come back (hopefully soon) with a separate I2S. For details about our web exposed changes shipping plan, please consult this doc: 
Interoperability Roadmap for Shipping Prerender2 Incrementally .



Link to “Intent to Prototype” blink-dev discussion

We don’t have a corresponding “Intent to Prototype”. This was implemented as a variation of other prerender2 triggers (Speculation rules I2E 
).



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

We plan to roll out omnibox-triggered prerendering from Android platforms, where we already have the MPArch coverage. Eventually, we will enable this 
on all platforms.



Demo link

For a demo of prerendering generally, and its effect on websites, https://prerender2-specrules.glitch.me/ 
shows it triggered by speculation rules (which are not part of this Intent).



Instruction: Demonstration of URL-bar-triggered Omnibox prerendering 



Demo page: https://omnibox-prerender.glitch.me/ 



Debuggability

We are actively talking to the devtools team about adding general Prerender support to it [metabug 
]. The MVP is to expose the prerendered page status in the panel so web developers can 
know if they finished successfully, or they couldn’t proceed due to its feature restrictions.



We currently don’t have a plan to add devtools support specifically for the 
omnibox prerender trigger (your thoughts are welcome!).


Measurement

We have implemented UseCounters [cs 
] to monitor the usage 
of the properties added by this I2S.



Risks

Compatibility

There is a non-zero chance that the behavior of the prerendered sites can be broken. The prerendered pages are loaded and rendered before user 
actually navigates to the websites, so there will be some number of prerenders that are false positives, which end up not being used. The websites 
will observe the requests, and can run some JavaScript, which can have side effects.



That said, triggering a prerender from the address bar isn’t an entirely new behavior. Chrome used to have a prerendering feature a long while ago 
. A similar behavior is also present in other browsers (e.g. “Preload Top Hit” feature 
in Safari).


For omnibox prerendering,

Re: [blink-dev] Intent to Ship: Omnibox Prerendering

[Olli Pettay]

FWIW, the comment in the HTML spec triage was positive feedback to have a
spec for this.
The current spec proposal clearly is missing still quite a few cases (is
the idea really that one can use BroadcastChannel with prerendered page?
and the webidl annotation behaves rather oddly)
So it is surprising to see this shipping already now.

-Olli

On Fri, Feb 11, 2022 at 7:20 AM Kouhei Ueno  wrote:

> Contact emails
>
> loading-...@chromium.org, noam.j.rosent...@gmail.com
>
> Component
>
> Internals>Preload>Prerender
>
> Explainer
>
>
> https://github.com/WICG/nav-speculation/blob/main/ua-initiated-prerendering.md
>
> Spec
>
> https://wicg.github.io/nav-speculation/prerendering.html
> Discussion about upstreaming into HTML and elsewhere: whatwg/html#7533
> 
>
> The corresponding TAG review is w3ctag/design-reviews#667
> . (That review was
> for speculation-rules triggered prerendering, which has a superset of the
> considerations for omnibox-triggered prerendering.)
>
> Summary
>
> We would like to ship omnibox (i.e., URL bar) prerendering. With this
> feature, Chrome will start prerendering the high-confidence omnibox
> autocomplete suggestions. Chrome is currently prefetching resources for
> high-confidence suggestions using No-state Prefetch
> , but
> with this feature we will be further processing the webpage, including the
> DOM tree construction and script execution.
>
> While this is a user agent feature, this is an observable change to the
> prerendered websites. This prerendering affects how the prerendered pages
> are processed. The website gets loaded before the navigation is committed,
> and the side-effects are delayed until activation (the actual navigation to
> the website was committed). We also would like to add a simple APIs
> (document.prerendering) to directly let the website know that it is being
> prerendered and when it was activated (prerenderingchange event,
> performance.activationStart timing).
>
> Note that we are not shipping speculation rules triggered prerender2 (I2E
> extension
> )
> with this I2S, which allows web pages to prerender other web pages. We will
> come back (hopefully soon) with a separate I2S. For details about our web
> exposed changes shipping plan, please consult this doc: Interoperability
> Roadmap for Shipping Prerender2 Incrementally
> 
> .
>
> Link to “Intent to Prototype” blink-dev discussion
>
> We don’t have a corresponding “Intent to Prototype”. This was implemented
> as a variation of other prerender2 triggers (Speculation rules I2E
> 
> ).
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
> Chrome OS, Android, and Android WebView)?
>
> We plan to roll out omnibox-triggered prerendering from Android platforms,
> where we already have the MPArch coverage. Eventually, we will enable this
> on all platforms.
>
> Demo link
>
> For a demo of prerendering generally, and its effect on websites,
> https://prerender2-specrules.glitch.me/ shows it triggered by speculation
> rules (which are not part of this Intent).
>
> Instruction: Demonstration of URL-bar-triggered Omnibox prerendering
> 
>
> Demo page: https://omnibox-prerender.glitch.me/
>
> Debuggability
>
> We are actively talking to the devtools team about adding general
> Prerender support to it [metabug
> ]. The MVP
> is to expose the prerendered page status in the panel so web developers can
> know if they finished successfully, or they couldn’t proceed due to its
> feature restrictions.
>
> We currently don’t have a plan to add devtools support specifically for
> the omnibox prerender trigger (your thoughts are welcome!).
>
> Measurement
>
> We have implemented UseCounters [cs
> ]
> to monitor the usage of the properties added by this I2S.
>
> Risks
>
> Compatibility
>
> There is a non-zero chance that the behavior of the prerendered sites can
> be broken. The prerendered pages are loaded and rendered before user
> actually navigates to the websites, so there will be some number of
> prerenders that are false positives, which end up not being used. The
> websites will observe the requests, and can run some JavaScript, which can
> have side effects.
>
> That said, triggering a prerender from the address bar isn’t an entirely
> new behavior. Chrome used to have a prerendering feature a