Intent to Ship: Remove clamping of setTimeout(..., 0)

1156 views
Skip to first unread message

Lin, Wanming

unread,
Jan 26, 2021, 9:02:12 PMJan 26
to blin...@chromium.org, Zheng, Hong, Philip Jägenstedt

Contact emails

wanmi...@intel.com, hong....@intel.com, foo...@chromium.org

 

Spec

https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timer-initialisation-steps

 

No TAG review requested as this does not add/alter any API surfaces.

 

Summary

Calls to setTimeout(..., 0) were previously clamped to a 1 ms timeout for historical reason: https://bugs.chromium.org/p/chromium/issues/detail?id=402694, This is very old, http://trac.webkit.org/changeset/17156 appeared to add it (10/20/06).

 

This is actually a bug since there's no 1ms clamp in the spec, and which will cause scheduling error, e.g.

 

setTimeout(()=> console.log('1ms timeout'), 1);

setTimeout(()=> console.log('0ms timeout'), 0);

 

Outputs:

Chrome 87:  1ms timeout, 0ms timeout

 

Moreover, 1ms clamp may bring performance penalty.

 

 

Link to “Intent to Prototype” blink-dev discussion

N/A

 

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

Yes

 

Risks

Interoperability and Compatibility

Firefox: no 1ms clamp

Safari: 1ms clamp (WebKit's clamp at https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L384)

 

           Some tests/live web pages that depended on this 1ms clamp may fail/meet issue.

 

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

No, no specific test for setTimeout(…, 0) is actually 0ms timeout, this is actually not necessary.

 

Entry on the feature dashboard

https://www.chromestatus.com/feature/4889002157015040

 

 

 

Thanks,

Wanming

Manuel Rego Casasnovas

unread,
Jan 28, 2021, 7:53:47 AMJan 28
to Lin, Wanming, blin...@chromium.org, Zheng, Hong, Philip Jägenstedt

On 27/01/2021 03:01, Lin, Wanming wrote:
> Safari: 1ms clamp (WebKit's clamp at
> https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L384
> <https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/DOMTimer.cpp#L384>)

Have we checked with WebKit if they have any plans to change this or not
at some point? Is there a WebKit bug report or something?
Maybe you can ask for signals in webkit-dev, see
https://bit.ly/blink-signals

Bye,
Rego

Alex Russell

unread,
Jan 28, 2021, 3:28:15 PMJan 28
to blink-dev, Manuel Rego, hong....@intel.com, Philip Jägenstedt, Lin, Wanming, Mike Taylor
+mike taylor who may have insight into the potential compat risks, given the different behavior between Gecko and WebKit/Blink.

Chris Harrelson

unread,
Jan 28, 2021, 3:35:25 PMJan 28
to Alex Russell, blink-dev, Manuel Rego, hong....@intel.com, Philip Jägenstedt, Lin, Wanming, Mike Taylor
Also, could you say more about the motivations for this work? Are developers facing problems from the 1ms clamping?

--
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/025bd7a7-6be1-4b77-9c3a-32bb6b295812n%40chromium.org.

Mike Taylor

unread,
Jan 28, 2021, 5:14:07 PMJan 28
to blink-dev, Manuel Rego, hong....@intel.com, Philip Jägenstedt, Alex Russell, Lin, Wanming
Howdy,

In general, I think if Firefox has been able to ship this behavior it's
likely web-compatible (modulo different code paths being served behind
UA sniffing).

There have been subtle race-y JS timing bug differences between sites in
Firefox and Chrome that my old team (at Mozilla) looked at, but
unfortunately I don't have any links to back that up. So there is some
risk that sites are (unintentionally) relying on the old behavior.

That said, aligning with Firefox (and the HTML standard) on this seems
good -- more so if WebKit is willing to do so as well.

A few questions:

What about setInterval?

Will setTimeout and setInterval be consistent wrt clamping after this
proposed change? (see also
https://bugzilla.mozilla.org/show_bug.cgi?id=1646799#c0)
> https://bit.ly/blink-signals <https://bit.ly/blink-signals>
>
> Bye,
> Rego
>
> --
> 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
> <mailto:blink-dev+...@chromium.org>.
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/025bd7a7-6be1-4b77-9c3a-32bb6b295812n%40chromium.org?utm_medium=email&utm_source=footer>.

Wanming Lin

unread,
Jan 29, 2021, 3:54:12 AMJan 29
to blink-dev, Mike Taylor, Manuel Rego, Hong Zheng, Philip Jägenstedt, sligh...@chromium.org, Lin, Wanming
Thanks all for your comments! I've created a WebKit issue at: https://bugs.webkit.org/show_bug.cgi?id=221124

The main motivation of this intent-to-ship is to correct the scheduling and reduce potential performance impact. We didn't find impact on live sites with/without 1ms clamp maybe they‘ve already avoided the usage of setTimeout(..., 0) since compatible risk is really existed. 

> What about setInterval?
Since remove 1ms clamp exits risk, we'd like to change setTimeout at first and base on discussion result to see if it's reasonable, if yes, we can apply it at setInterval as next step.

Yoav Weiss

unread,
Jan 29, 2021, 4:01:37 AMJan 29
to Wanming Lin, blink-dev, Mike Taylor, Manuel Rego, Hong Zheng, Philip Jägenstedt, sligh...@chromium.org
On Fri, Jan 29, 2021 at 9:54 AM Wanming Lin <wanmi...@intel.com> wrote:
Thanks all for your comments! I've created a WebKit issue at: https://bugs.webkit.org/show_bug.cgi?id=221124

The main motivation of this intent-to-ship is to correct the scheduling and reduce potential performance impact. We didn't find impact on live sites with/without 1ms clamp maybe they‘ve already avoided the usage of setTimeout(..., 0) since compatible risk is really existed. 

Do we have numbers on how often `setTimout(... ,0)` is used? (use counters, HTTPArchive, cluster telemetry, etc)
 
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/5c1d6691-1ccd-4451-a491-56990ecc695fn%40chromium.org.

Ben Kelly

unread,
Jan 29, 2021, 10:20:44 AMJan 29
to Yoav Weiss, Wanming Lin, blink-dev, Mike Taylor, Manuel Rego, Hong Zheng, Philip Jägenstedt, sligh...@chromium.org
Its possible folks are using setTimeout(.., 0) as a setImmediate() replacement which would result in high numbers.  But that use case would not be adversely impacted by removing this clamping.

Ben Kelly

unread,
Jan 29, 2021, 10:22:28 AMJan 29
to Yoav Weiss, Wanming Lin, blink-dev, Mike Taylor, Manuel Rego, Hong Zheng, Philip Jägenstedt, sligh...@chromium.org
Also note that if you nest setTimeout(..., 0) enough (5 times?) then you start getting 4ms clamping anyway.  So this is really about the first 4 or so setTimeout(..., 0) calls in a chain.  I don't think this intent is removing the 4ms clamping for nested timeouts.

geoffrey garen

unread,
Feb 1, 2021, 3:01:42 PMFeb 1
to blink-dev, wande...@chromium.org, Wanming Lin, blink-dev, Mike Taylor, Manuel Rego, hong....@intel.com, Philip Jägenstedt, sligh...@chromium.org, yo...@yoav.ws
Note: http://trac.webkit.org/changeset/17156/webkit is not the change that added the minimum timeout clamp. r17156 *reduced* a pre-existing 10ms clamp to 1ms. 

Alex Russell

unread,
Feb 4, 2021, 3:15:11 PMFeb 4
to blink-dev, geoffrey garen, Ben Kelly, Wanming Lin, blink-dev, Mike Taylor, Manuel Rego, hong....@intel.com, Philip Jägenstedt, Alex Russell, yo...@yoav.ws
Thanks for the clarification, Geoffery.

Wanming: we discussed this again at today's API OWNERS meeting and, given what Mike and Ben noted here, we'd like to see this bake for a while on Beta to shake out any potential compat issues. You have my LGTM1 to flag this on for Beta for one release, and as we get evidence back from that, we'd ask you to report it here. On the basis of that update, we'll then potentially approve a stable launch. Does that sound good to you?

Also, if you have any more data as to why this change improves things for users and developers, that would also be helpful.

Regards

Chris Harrelson

unread,
Feb 4, 2021, 3:16:37 PMFeb 4
to Alex Russell, blink-dev, geoffrey garen, Ben Kelly, Wanming Lin, Mike Taylor, Manuel Rego, hong....@intel.com, Philip Jägenstedt, yo...@yoav.ws
LGTM2 for testing on beta and coming back to the API owners with the results.

Wanming Lin

unread,
Feb 4, 2021, 9:34:37 PMFeb 4
to blink-dev, Chris Harrelson, blink-dev, geoffrey garen, wande...@chromium.org, Wanming Lin, Mike Taylor, Manuel Rego, Hong Zheng, Philip Jägenstedt, yo...@yoav.ws, sligh...@chromium.org
Thanks Alex, Chris, very glad to see this great progress!

> You have my LGTM1 to flag this on for Beta for one release, and as we get evidence back from that, we'd ask you to report it here. On the basis of that update, we'll then potentially approve a stable launch.

Since I'm new to intent-to-ship process, could you please guide me or provide BKMs on how to flag this on for Beta for one release, and what kinds of testing should be covered? Any chromium program could help test and evaluate the impact?

Besides, I am thinking of leveraging chrome://histograms/ to count the use of setTimeout(..., 0) from some hot websites, then we can do some basic testing to check if there's obvious regression. Does it make sense?

Thanks,
Wanming

Philip Jägenstedt

unread,
Feb 5, 2021, 11:01:24 AMFeb 5
to Wanming Lin, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org
Hi Wanming,

The most straightforward way to test this on beta (and canary before that) would be to land the code right after the M90 branch point (Feb 25) and then revert it some time well ahead of the M91 branch point (Apr 8). The beta promotion should be around Mar 11, so you should be able to get at least a few weeks on beta with this method.

However, even if the beta baking does not reveal any issues, breakage due to this can be hard to understand, and could be in code (libraries) that aren't easy to update. It would be prudent to make this a finch-controlled experiment, to avoid a potential urgent revert in a point release.

LGTM3 to trying this on beta with whichever method you prefer at the moment.

Best regards,
Philip

Wanming Lin

unread,
Feb 7, 2021, 9:07:07 PMFeb 7
to blink-dev, Philip Jägenstedt, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, Wanming Lin
Philip, thanks for your comments! I've submitted the reland CL at https://chromium-review.googlesource.com/c/chromium/src/+/2636507/,  please take a look.

Philip Jägenstedt

unread,
Feb 8, 2021, 4:28:00 AMFeb 8
to Wanming Lin, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org
Thanks Wanming, I'll review on the CL.

Can you check back in this thread on the week of March 22, so that there will be enough time to discuss before the branch point?

Ian Kilpatrick

unread,
Feb 8, 2021, 11:48:28 AMFeb 8
to Philip Jägenstedt, Wanming Lin, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org
Philip - if you could also email the release engineers directly about this change - that likely would be pertinent (just so this is on their radar in case things go wrong, and if a revert in Beta is needed).

Ian 

Wanming Lin

unread,
Feb 8, 2021, 8:09:13 PMFeb 8
to blink-dev, ikilp...@chromium.org, Wanming Lin, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, Philip Jägenstedt
> Can you check back in this thread on the week of March 22, so that there will be enough time to discuss before the branch point?

Sure. :)

Philip Jägenstedt

unread,
Feb 9, 2021, 5:14:15 PMFeb 9
to Ian Kilpatrick, Wanming Lin, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org
Good idea, Ian, I'll go ahead and do that.

Wanming Lin

unread,
Mar 28, 2021, 10:27:34 PMMar 28
to blink-dev, Philip Jägenstedt, Wanming Lin, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org
All, the CL has been landed at https://chromium-review.googlesource.com/c/chromium/src/+/2730350, sorry for a bit delay due to another reverting during the period.

Philip, could you help to  email the release engineers about this change?

Philip Jägenstedt

unread,
Mar 29, 2021, 6:03:04 AMMar 29
to Wanming Lin, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org
Hi Wanming,

I think the original timeline here won't work since your CL was reverted and relanded so many times, and I think I also made a mistake with the branching, since a change landed after the M90 branch point would never be in the M90 beta...

To bake in the the M91 beta, what we need to do is:
  • Land the change soon before the M91 branch point, which the latest reland did
  • Allow the change to reach M91 beta (promoted Apr 22)
  • Revert it on the M91 branch well before the stable cut/release, let's say May 4 at the latest
Exactly how much exposure on the beta channel that will give depends on beta release dates, but it ought to be at least a week. 

Does that sound right to you? If so I can ask the release managers about this plan.

Best regards,
Philip

Wanming Lin

unread,
Mar 29, 2021, 11:00:44 PMMar 29
to blink-dev, Philip Jägenstedt, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Wanming Lin
> Does that sound right to you? If so I can ask the release managers about this plan.

Yeah, that sounds good! Thank you for your support!

Philip Jägenstedt

unread,
May 13, 2021, 3:40:33 AMMay 13
to Wanming Lin, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org
Hi Wanming,

This change has now been on beta for a time, and the revert on M91 is in progress. Can you summarize what you learned from bug reports coming in?

Best regards,
Philip

Wanming Lin

unread,
May 13, 2021, 4:24:59 AMMay 13
to blink-dev, Philip Jägenstedt, blink-dev, Chris Harrelson, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Wanming Lin
Thank you Philip! We actually received some regression bugs during initial trial, including several pinpoint performance regressions and one user reported scheduling issue. But we finally identify they are all caused by other issues after investigation. Following's the bug summary:

We identified the problem is with the perf story itself.

2.  en.wikipedia.org : User reports page is scrolled to the top after closing overlay: https://bugs.chromium.org/p/chromium/issues/detail?id=1205285
This should be an navigation scheduling issue.

Chris Harrelson

unread,
May 13, 2021, 1:55:55 PMMay 13
to Wanming Lin, blink-dev, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org
Hi,

Thanks for these data points. Are these the only bugs that were filed?

I'd say these bugs are exactly the kind of interop problems we should be worried about with this intent. Yes it's true that those sites shouldn't depend on these relative timings, and it's technically a site bug if so, but if it is widespread enough it still represents a big enough problem that it would block shipping this change in behavior.

Chris

Daniel Bratell

unread,
May 13, 2021, 3:44:33 PMMay 13
to Chris Harrelson, Wanming Lin, blink-dev, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org

As Chris said, it's good that you managed to identify some problematic areas during the beta phase. Of course it would have been more pleasant with no problems at all, but this was always a risky change. Hopefully you can use these bug reports to figure out a version of this change that doesn't cause those problems.

From a process point of view we will consider this intent "on hold" until you think it is ready to try again. At such a time, just return to this thread (or file a new intent if you think that would be cleaner).

/Daniel

Wanming Lin

unread,
May 17, 2021, 3:17:48 AMMay 17
to blink-dev, Daniel Bratell, blink-dev, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Chris Harrelson, Wanming Lin
Thanks Chris and Daniel, sorry I didn't explain clearly for the user reported issue, which is actually a chrome bug, even with 1ms clamp, this issue may still happen in some other scenarios, I've created a separated bug and explained the story at https://bugs.chromium.org/p/chromium/issues/detail?id=1209717. PTAL, thanks!
I think it's worth an another intent once this bug be solved. As it turns out, 1ms' clamp covers up some real chrome bugs.




Wanming Lin

unread,
Jun 10, 2021, 10:13:47 PMJun 10
to blink-dev, Wanming Lin, Daniel Bratell, blink-dev, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Chris Harrelson, Toon Verwaest
Hi all,

@verwaest reported at the revert CL that this change would improve Speedometer2 by 5-6% on the Apple M1 and ~3% on our win10 perf bots. Thanks @verwaest!

This is really a good improvement and a new impetus for us to push this optimization forward. One block at present is the navigation scheduling issue we reported: https://bugs.chromium.org/p/chromium/issues/detail?id=1209717, which has been open for a while and no new updates. Could someone help to push it? Thanks!

Moreover, is there other workaround solution to push the optimization forward?

กมลวรรณ เหมาะตัว

unread,
Jun 11, 2021, 1:59:25 PMJun 11
to Wanming Lin, blink-dev, Daniel Bratell, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, Mike Taylor, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Chris Harrelson, Toon Verwaest
Re:[blink-dev] Ineng to Ship:Remove clamping of set Up

BGODL209B013

ในวันที่ ศ. 11 มิ.ย. 2021 09:13 Wanming Lin <wanmi...@intel.com> เขียนว่า:

Wanming Lin

unread,
Aug 4, 2021, 12:28:35 AMAug 4
to blink-dev, 08629...@gmail.com, blink-dev, Daniel Bratell, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Chris Harrelson, Toon Verwaest, Wanming Lin
Hi Chris, Daniel and all,

The blocker issue  https://bugs.chromium.org/p/chromium/issues/detail?id=1209717 has been fixed now, and per above performance improvement @verwaest reported, can we start testing on Beta again?

Chris Harrelson

unread,
Aug 5, 2021, 3:13:06 PMAug 5
to Wanming Lin, blink-dev, 08629...@gmail.com, Daniel Bratell, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest
Hi,

On Tue, Aug 3, 2021 at 9:28 PM Wanming Lin <wanmi...@intel.com> wrote:
Hi Chris, Daniel and all,

The blocker issue  https://bugs.chromium.org/p/chromium/issues/detail?id=1209717 has been fixed now, and per above performance improvement @verwaest reported, can we start testing on Beta again?

Sure, go ahead and experiment on canary/dev/beta, and then come back to us with any new findings.
 

Wanming Lin

unread,
Aug 26, 2021, 10:07:27 PMAug 26
to blink-dev, Chris Harrelson, blink-dev, 08629...@gmail.com, Daniel Bratell, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Wanming Lin
Hi all,

The CL has been relanded and following's the new original plan:
  • Land the change to M95 - Done
  • Allow the change to reach M95 beta (promoted Sep 23)
  • Revert it on the M95 branch well before the stable cut/release (Cut Oct 12)
  • Get back to this thread with test reports on M95 beta
Does that sound good to you? Looks like Philip is still on vacation, could someone help notice the release managers about this plan? Or just help me reach out the release managers. Many thanks!

Thanks,
Wanming

Chris Harrelson

unread,
Aug 27, 2021, 11:38:33 AMAug 27
to Wanming Lin, blink-dev, 08629...@gmail.com, Daniel Bratell, Philip Jägenstedt, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest

Philip Jägenstedt

unread,
Aug 31, 2021, 8:32:59 AMAug 31
to Chris Harrelson, Wanming Lin, blink-dev, 08629...@gmail.com, Daniel Bratell, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest
Hi Wanming, I'll put you in touch with our release managers so that they're aware of this happening.

Wanming Lin

unread,
Oct 12, 2021, 4:15:02 AMOct 12
to blink-dev, Philip Jägenstedt, Wanming Lin, blink-dev, 08629...@gmail.com, Daniel Bratell, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, rak...@chromium.org

Hi all,

Thanks Philip's bridge, I've been connected with the release managers and completed the new round of origin trial on M95 (we reached an agreement on reverting the change after the first M95 Beta release itself). During this period, I didn't receive any relevant bugs.

But unfortunately, after the origin trial, the fix for the previous block issue #1209717 was reverted due to regression at issue #1254867, @rakina is considering that maybe we can do nothing here because per crbug.com/1205285#c16, the original bug on Wikipedia has been fixed on Wikipedia's side. 

So we are looking forward your feedbacks, on both the bug of #1209717 and what's the next step to move forward this intent-to-ship. Many thanks in advance!


Thanks,

Wanming

Philip Jägenstedt

unread,
Oct 12, 2021, 11:16:26 AMOct 12
to Wanming Lin, blink-dev, 08629...@gmail.com, Daniel Bratell, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, Rakina Zata Amni
Hi Wanming,

If the reason for reverting no longer applies, then trying to reland the fix sounds like a reasonable next step. If that is done and it sticks this time, it seems to me we might be ready for a final Intent to Ship for this. At least I don't know what more could be done to vet the change before trying to let it reach stable.

Best regards,
Philip

Rakina Zata Amni

unread,
Oct 13, 2021, 5:14:28 AMOct 13
to Philip Jägenstedt, Wanming Lin, blink-dev, 08629...@gmail.com, Daniel Bratell, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson
I had a quick chat with Philip about whether we want to fix crbug.com/1209717 or not, and I think we don't need to fix that bug for shipping this.
In the bug, the code expected a same-document history navigation (and its scroll restoration) would happen synchronously, so any scroll changes that happen after the navigation was initiated won't be overwritten by the history scroll restore. Because all history navigation in Chrome needs to go through the browser process, the same-document history navigation is actually asynchronous, and so the history scroll restoration is also asynchronous. Looks like this was fast enough before that the history scroll restoration might happen before code with clamping of setTimeout, but now that the clamping is being removed it's not fast enough, so we got that regression.

That bug was derived from crbug.com/1205285, which is noted as having been fixed by Wikipedia since it's showing a similar behavior on Firefox with Fission. The fix itself is very simple: they just needed to set history.scrollRestoration to "manual". As the motivating bug has been fixed with a simple fix, and asynchronous same-document history navigation has been in Chrome for a while (and is also what Firefox is doing), I think we don't need to reland/make the full fix for crbug.com/1209717.

Philip Jägenstedt

unread,
Oct 13, 2021, 9:18:48 AMOct 13
to Rakina Zata Amni, Wanming Lin, blink-dev, 08629...@gmail.com, Daniel Bratell, geoffrey garen, wande...@chromium.org, mike...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson
Thanks for explaining this, Rakina, I definitely didn't get the whole
context on my first pass.

In particular the fact that current behavior matches Firefox is a
strong reason to not make any further changes.

Wanming, are you aware of any other outstanding questions or bugs that
might crop up if we attempt to ship this?

Mike Taylor

unread,
Oct 13, 2021, 9:54:59 AMOct 13
to Philip Jägenstedt, Rakina Zata Amni, Wanming Lin, blink-dev, 08629...@gmail.com, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson
It does seem worth trying to ship this given the lack of (known) bugs,
but maybe we should consider waiting until M98 to avoid sites needing to
deploy fixes during the holiday season, assuming a few weeks of latency
for bug reports.

Wanming Lin

unread,
Oct 13, 2021, 10:12:13 PMOct 13
to blink-dev, mike...@chromium.org, Wanming Lin, blink-dev, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, Philip Jägenstedt, rak...@chromium.org
Thank you all for your great support! 

There's no more outstanding questions or bugs in my mind that might block shipping this, but I need to get 3 LGTMs from you to process the final ship.
Is that possible we could cherry-pick it to M96?  Otherwise we have to wait about 4 months for M98 stable, and M96 stable release at Nov 16, 2021, we may have some latency for bug reports. But it's up to your opinions. :)


Thanks,
Wanming

Yoav Weiss

unread,
Oct 14, 2021, 5:02:22 AMOct 14
to Wanming Lin, blink-dev, mike...@chromium.org, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, Philip Jägenstedt, rak...@chromium.org
If I'm reading the Chromium Dashboard schedule correctly, M97 stable will be released early January, so after the holiday season. It seems worthwhile to try and ship this at that point (but not in M96).


Do I understand correctly and the only relationship between this change and the scroll restoration issue is that the bug is revealed when a 0 timeout is present?

Mike Taylor

unread,
Oct 14, 2021, 9:32:23 AMOct 14
to Yoav Weiss, Wanming Lin, blink-dev, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, Philip Jägenstedt, rak...@chromium.org
Ah, yeah. I think I intended to write M97 (but I'm admittedly terrible with calendars). That seems like a good milestone to try to ship.

Johnny Stenback

unread,
Oct 14, 2021, 12:15:08 PMOct 14
to Mike Taylor, Yoav Weiss, Wanming Lin, blink-dev, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, Philip Jägenstedt, rak...@chromium.org
M97 is also a better alternative in that it's not a release that will be supported for 8 weeks, as M96 would be, and thus we'll be in a better position to handle any fallout from this in M97.

Wanming Lin

unread,
Oct 14, 2021, 9:32:23 PMOct 14
to blink-dev, jste...@chromium.org, yoav...@chromium.org, Wanming Lin, blink-dev, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, Philip Jägenstedt, rak...@chromium.org, mike...@chromium.org
Thanks again! So can I suppose I have your LGTMs now and be approved to proceed the final ship to M97?

Yoav Weiss

unread,
Oct 15, 2021, 2:17:58 AMOct 15
to Wanming Lin, blink-dev, jste...@chromium.org, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, Philip Jägenstedt, rak...@chromium.org, mike...@chromium.org
Apologies for not being clearer, but this intent is not yet approved.

Talking about this with the API owners yesterday, we still see potentially high compat risk here, while at the same time there are potential compatibility and performance benefits.
One thing that was brought up was that this should be behind a feature flag, so that the various Chromium browsers would be able to carefully roll this out, and at worst, be able to turn it off if needed.

Philip Jägenstedt

unread,
Oct 15, 2021, 2:49:16 AMOct 15
to Yoav Weiss, Wanming Lin, blink-dev, jste...@chromium.org, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, rak...@chromium.org, mike...@chromium.org
I assume the idea is that this would be Finch controlled in Chrome? That sounds like a good idea if so! Do we have good docs for what's needed to make something possible to control with Finch?

Yoav Weiss

unread,
Oct 15, 2021, 2:55:25 AMOct 15
to Philip Jägenstedt, Wanming Lin, blink-dev, jste...@chromium.org, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, Chris Harrelson, rak...@chromium.org, mike...@chromium.org
I believe it's just a matter of adding a feature flag, and making sure that the feature is off when it's disabled. Then Chrome can create a Finch configuration based on that, Edge can set up its own controls, etc.

It may be reasonable to have the feature flag off by default, and have server-side configs that turn it on. (e.g. I believe enterprise users may opt-out of such configs, so it's better to be cautious there and have the risky option enabled by configs, rather than disabled by it)
That would mean that we'd need engineers on the Chrome and Edge side of things to own the configs that turn this on.

Chris Harrelson

unread,
Oct 15, 2021, 10:43:18 AMOct 15
to Yoav Weiss, Philip Jägenstedt, Wanming Lin, blink-dev, jste...@chromium.org, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, rak...@chromium.org, mike...@chromium.org
How about this option: put it behind a feature flag, and turn it on via finch for canary, dev and beta channels. Then let it run for several releases, gathering additional feedback on bugs in order to increase confidence.

Philip Jägenstedt

unread,
Oct 15, 2021, 11:34:10 AMOct 15
to Chris Harrelson, Yoav Weiss, Wanming Lin, blink-dev, jste...@chromium.org, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, rak...@chromium.org, mike...@chromium.org
That sounds like a good idea to me, if release managers are OK with it. Differences between beta and stable are always a risk, after all.

Wanming, what do you think about this approach?

Wanming Lin

unread,
Oct 15, 2021, 11:58:22 AMOct 15
to blink-dev, Philip Jägenstedt, yoav...@chromium.org, Wanming Lin, blink-dev, jste...@chromium.org, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, rak...@chromium.org, mike...@chromium.org, Chris Harrelson
Thanks all! Absolutely, we should be very careful for shipping this change, I'm totally agree with this approach.

Could you guide me how to control it via finch? Is there any docs?

Scott Haseley

unread,
Oct 21, 2021, 3:16:40 PMOct 21
to Wanming Lin, blink-dev, Philip Jägenstedt, yoav...@chromium.org, jste...@chromium.org, Daniel Bratell, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, rak...@chromium.org, mike...@chromium.org, Chris Harrelson
Hi Wanming,

My team can help out with this (I work on scheduling APIs). I'll send an email off-thread so we can coordinate. Thanks for working on this!

 - Scott

Yoav Weiss

unread,
Oct 21, 2021, 3:50:02 PMOct 21
to blink-dev, Scott Haseley, blink-dev, Philip Jägenstedt, Yoav Weiss, Johnny Stenback, Daniel Bratell, geoffrey garen, Ben Kelly, Manuel Rego, hong....@intel.com, yo...@yoav.ws, Alex Russell, Ian Kilpatrick, Toon Verwaest, Rakina Zata Amni, Mike Taylor, Chris Harrelson, Wanming Lin
Thanks Scott for helping out!

Since it's been a while since this was LGTMed, the API owners agreed that it makes sense to re-LGTM this attempt to re-land this.

LGTM1 to roll this out in Finch till Beta to gain confidence that this is safe to ship. Once we have that data, please come back to this thread before moving to Stable.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Daniel Bratell

unread,
Oct 21, 2021, 4:02:24 PMOct 21
to Yoav Weiss, blink-dev, Scott Haseley, Philip Jägenstedt, Johnny Stenback, geoffrey garen, Ben Kelly, Manuel Rego, hong....@intel.com, yo...@yoav.ws, Alex Russell, Ian Kilpatrick, Toon Verwaest, Rakina Zata Amni, Mike Taylor, Chris Harrelson, Wanming Lin

LGTM2 to run on beta, making sure this is web compatible.

/Daniel

Wanming Lin

unread,
Oct 21, 2021, 11:32:30 PMOct 21
to blink-dev, Daniel Bratell, Scott Haseley, Philip Jägenstedt, jste...@chromium.org, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, rak...@chromium.org, mike...@chromium.org, Chris Harrelson, Wanming Lin, yoav...@chromium.org
Thanks all! 

I've landed the change (CL) to  M97 canary which is behind a feature flag and disabled by default. 

Thanks Scott, let's talk off-thread.

Thanks,
Wanming.

Chris Harrelson

unread,
Oct 23, 2021, 12:19:58 AMOct 23
to Wanming Lin, blink-dev, Daniel Bratell, Scott Haseley, Philip Jägenstedt, jste...@chromium.org, geoffrey garen, wande...@chromium.org, Manuel Rego, Hong Zheng, yo...@yoav.ws, sligh...@chromium.org, ikilp...@chromium.org, Toon Verwaest, rak...@chromium.org, mike...@chromium.org, yoav...@chromium.org
Reply all
Reply to author
Forward
0 new messages