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.
On 10/13/21 9:18 AM, Philip Jägenstedt wrote:
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?
On Wed, Oct 13, 2021 at 11:14 AM Rakina Zata Amni <rak...@chromium.org> wrote:
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.
On Tue, Oct 12, 2021 at 11:16 PM Philip Jägenstedt <foo...@chromium.org> wrote:
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
On Tue, Oct 12, 2021 at 10:14 AM Wanming Lin <wanming....@intel.com> wrote:
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
On Tuesday, August 31, 2021 at 8:32:59 PM UTC+8 Philip Jägenstedt wrote:
Hi Wanming, I'll put you in touch with our release managers so that they're
aware of this happening.
On Fri, Aug 27, 2021 at 5:38 PM Chris Harrelson <chri...@chromium.org> wrote:
Sounds good to me.
On Thu, Aug 26, 2021 at 7:07 PM Wanming Lin <wanmi...@intel.com> wrote:
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
On Friday, August 6, 2021 at 3:13:06 AM UTC+8 Chris Harrelson wrote:
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.
On Saturday, June 12, 2021 at 1:59:25 AM UTC+8 08629...@gmail.com wrote:
Re:[blink-dev] Ineng to Ship:Remove clamping of set Up
BGODL209B013
ในวันที่ ศ. 11 มิ.ย. 2021 09:13 Wanming Lin <wanmi...@intel.com> เขียนว่า:
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?
On Monday, May 17, 2021 at 3:17:48 PM UTC+8 Wanming Lin wrote:
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.
On Friday, May 14, 2021 at 3:44:33 AM UTC+8 Daniel Bratell wrote:
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
On 2021-05-13 19:55, Chris Harrelson wrote:
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
On Thu, May 13, 2021 at 1:24 AM Wanming Lin <wanmi...@intel.com> wrote:
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:
1. Pinpoint regressions:
https://bugs.chromium.org/p/chromium/issues/detail?id=1179810
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.
On Thursday, May 13, 2021 at 3:40:33 PM UTC+8 Philip Jägenstedt wrote:
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
On Tue, Mar 30, 2021 at 5:00 AM Wanming Lin <wanmi...@intel.com> wrote:
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!
On Monday, March 29, 2021 at 6:03:04 PM UTC+8 Philip Jägenstedt wrote:
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
On Mon, Mar 29, 2021 at 4:27 AM Wanming Lin <wanmi...@intel.com> wrote:
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?
On Wednesday, February 10, 2021 at 6:14:15 AM UTC+8 Philip Jägenstedt wrote:
Good idea, Ian, I'll go ahead and do that.
On Mon, Feb 8, 2021 at 5:48 PM Ian Kilpatrick <ikilp...@chromium.org> wrote:
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
On Mon, Feb 8, 2021 at 1:28 AM Philip Jägenstedt <foo...@chromium.org> wrote:
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?
On Mon, Feb 8, 2021 at 3:07 AM Wanming Lin <wanmi...@intel.com> wrote:
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.
On Saturday, February 6, 2021 at 12:01:24 AM UTC+8 Philip Jägenstedt wrote:
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
On Fri, Feb 5, 2021 at 3:34 AM Wanming Lin <wanmi...@intel.com> wrote:
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
On Friday, February 5, 2021 at 4:16:37 AM UTC+8 Chris Harrelson wrote:
LGTM2 for testing on beta and coming back to the API owners with the results.
On Thu, Feb 4, 2021 at 12:15 PM Alex Russell <sligh...@chromium.org> wrote:
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
On Monday, February 1, 2021 at 12:01:42 PM UTC-8 geoffrey garen wrote:
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.
On Friday, January 29, 2021 at 7:22:28 AM UTC-8 wande...@chromium.org wrote:
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.
On Fri, Jan 29, 2021 at 10:20 AM Ben Kelly <wande...@chromium.org> wrote:
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.
On Fri, Jan 29, 2021 at 4:01 AM Yoav Weiss <yo...@yoav.ws> wrote:
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)
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.
On Friday, January 29, 2021 at 6:14:07 AM UTC+8 Mike Taylor wrote:
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)
On 1/28/21 2:28 PM, Alex Russell wrote:
+mike taylor who may have insight into the potential compat risks, given
the different behavior between Gecko and WebKit/Blink.
On Thursday, January 28, 2021 at 4:53:47 AM UTC-8 Manuel Rego wrote:
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>
<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 <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>.
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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/025bd7a7-6be1-4b77-9c3a-32bb6b295812n%40chromium.org?utm_medium=email&utm_source=footer>.
--
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/5c1d6691-1ccd-4451-a491-56990ecc695fn%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhAvLduQ6XXA-Vm-8%3DTM9L-d5q1_h-DrvrKLHg8NBvxEQ%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/095fc193-27e5-4a7c-b816-edbab7eb176cn%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfU0La%3D3Fpd%3DHBVQ2phHuvMSozpOsXqt-NR-mtWepRJPQ%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2869319d-e852-4f3b-8471-611f6ae7c9b4n%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8JUEZDbfNsmXJWhcz_N7zcRwzoips2r_DzMEqhctwr1g%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b155d685-4b7e-498b-8e8a-1e9c95d4195an%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f2f1d2cf-0b9b-4ed4-ac0e-4f7d9a20e4c1n%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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cb9aacdf-dc28-42b0-90cd-6c0faec080ffn%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/d2d07fa7-b648-da5f-12cd-907d121580b3%40chromium.org.
