See this profile from playing a video on youtube: https://perfht.ml/2pYJWzA A synchronous layout flush coming from script calling window.scroll(0, 0) for 29ms. I checked and Chromium has added a fast path for (0, 0), because scrolling to that position is always a valid thing to do: <https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/LocalDOMWindow.cpp?l=1272> <https://codereview.chromium.org/1071983002> I think we should add a similar fast path.

Olli, Mats, what do you think?

(Note that this bug is part of the Quantum Release Criteria.)

Here is the patch, in case you agree this is a good idea.

hmm, is there some edge case where flushing is needed.

Comment on attachment 8868883 [details] [diff] [review] Don't flush layout for (0, 0) in nsGlobalWindow::ScrollTo() Given that this has something in common with bug 1364360, perhaps bz could review.

Comment on attachment 8868883 [details] [diff] [review] Don't flush layout for (0, 0) in nsGlobalWindow::ScrollTo() Please add a code comment about scrolling to some nonzero position needs a layout flush because we need to determine whether that position is actually in our scroll range or not, which depends on sizes of things, but (0,0) is always in the scroll range.

Will do. I noticed that <https://searchfox.org/mozilla-central/rev/f55349994fdac101d121b11dac769f3f17fbec4b/dom/base/nsGlobalWindow.cpp#8436> also has the same issue, I'll fix that as well.

Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/93cbe9914d05 Don't flush layout for (0, 0) in nsGlobalWindow::ScrollTo(); r=bzbarsky

(In reply to Pulsebot from comment #8) > Pushed by eakhgari@mozilla.com: > https://hg.mozilla.org/integration/mozilla-inbound/rev/93cbe9914d05 > Don't flush layout for (0, 0) in nsGlobalWindow::ScrollTo(); r=bzbarsky Oops, this landed before I meant it to...

Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/91f27a7b5130 Don't flush layout for (0, 0) in nsGlobalWindow::ScrollTo(); r=bzbarsky

Backout by eakhgari@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/802ae55b7c03 Backout for build bustage

Just a note for the record: Gecko has 0,0 as the origin also for RTL, but there is a CSSOM issue open on that: https://github.com/w3c/csswg-drafts/issues/1354 so this might change I suppose, which might break the RTL case. (I wonder if Chrome already have that bug, since they don't have 0,0 as the origin for RTL.)