Issue 515257 in chromium: .scrollTo(0, 0) ignored unless scrollY is read first

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Pri-2 Via-Wizard Type-Compat OS-Mac

New issue 515257 by itsbusti...@gmail.com: .scrollTo(0, 0) ignored unless
scrollY is read first
https://code.google.com/p/chromium/issues/detail?id=515257

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.15 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. visit scrollable page, scroll down half-way
2. click a link which triggers history.pushState() and causes html to be
replaced
3. set scrollTo(0,0); after DOM is updated

What is the expected behavior?
new scroll position is 0, 0

What went wrong?
scroll position is not updated, old position 0, 1001 is retained

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No

Did this work before? Yes v44

Does this work in other browsers? Yes

Chrome version: 45.0.2454.15 Channel: beta
OS Version: OS X 10.10.4
Flash Version:

i realize this is a fairly vague and unhelpful report but bear with me a
bit here - what i'm seeing is simply hard to explain let alone provide an
isolated test case for.

i have a single page app where i manually manage the main window's scroll
position (le sigh) - allowing me to restore on back / fwd as well as set
the appropriate state on initial click.

basic steps in this case are:

1. user clicks a link
2. app fetches view content (or restores if cached)
3. app draws new view, revealing when done
4. if scroll pos has changed, app sets new position - in this case
scrollTo(0, 0);

prior to v45, this all worked more or less fine - showing the user a new
view scrolled fully to the top when first loaded. with v45, new views are
no longer being scrolled to the top.

stepping thru my code in the debugger, i see that i'm setting the
appropriate scrollTo values at the right time yet those values are not
being respected.

here's the weird part - if i read window.scrollY directly before calling
window.scrollTo(0, 0), everything works as it did in v44.

further, when i pause execution in chrome at the point where i'm
setting .scrollTo(), i see that my new view is not yet painted. when i step
thru my code in firefox (v40) and safari (v8), they work as expected and
when i pause execution at the same point, my new view is rendered and
visible.

i found this perhaps related issue -->
https://code.google.com/p/chromium/issues/detail?id=465574&q=scroll%20position&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

i'll be sure to post any additional info as i find it. unfortunately, the
code which triggers this issue isn't live yet but when it gets shipped, i
will update this issue with a live example.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Labels: Cr-Blink-Scroll Cr-Blink-Layout

Comment #1 on issue 515257 by tk...@chromium.org: .scrollTo(0, 0) ignored

unless scrollY is read first
https://code.google.com/p/chromium/issues/detail?id=515257

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Cc: a...@chromium.org
Labels: Needs-Feedback

Comment #2 on issue 515257 by a...@chromium.org: .scrollTo(0, 0) ignored

unless scrollY is read first
https://code.google.com/p/chromium/issues/detail?id=515257

Please attach any sample file with the above test case when the code is
ready.

Thanks!

[chro...@googlecode.com]

Updates:
Labels: -Cr-Blink-Layout

Comment #5 on issue 515257 by e...@chromium.org: .scrollTo(0, 0) ignored

unless scrollY is read first
https://code.google.com/p/chromium/issues/detail?id=515257

(No comment was entered for this change.)

[chro...@googlecode.com]

Updates:
Cc: jap...@chromium.org esp...@chromium.org ru...@opera.com

Comment #6 on issue 515257 by maji...@chromium.org: .scrollTo(0, 0) ignored

unless scrollY is read first
https://code.google.com/p/chromium/issues/detail?id=515257

The original report is correct (thanks itsbusticated@!) that the issue is
related to 465574 which makes it so that scrolling to (0,0) does not cause
layout.

This is what happens now:
1- History is being traversed (back/forward)
2- onpopstate page recreates the UI (no layout yet)
3- scrolls to top i.e., window.scrollTo(0,0)
4- layout happens => content size is updated
5- now try to restore scroll if needed

Before 465574, step 3 would have triggered layout and scroll restoration
before scrolling to top. Now it does not which result in the current order
and causes the history scroll restoration to override the scripted scroll
to top. Using window.scrollY triggers a layout which is why calling it
before scrolling to (0,0) solves this issue.

Obviously reverting back to the old behaviour for scrolling to (0,0)
resolves this issue but I think the right solution here is for scroll
restoration to not happen if we detect that a scripted scrolled has
occurred. We already do this if we detect a user scroll. I think it is
reasonable to extend this logic to apply to scripted scrolls too.

[chro...@googlecode.com]

Comment #7 on issue 515257 by ru...@opera.com: .scrollTo(0, 0) ignored

unless scrollY is read first
https://code.google.com/p/chromium/issues/detail?id=515257

> I think it is reasonable to extend this logic to apply to scripted
> scrolls too.

Sounds reasonable to me too.

[chro...@googlecode.com]

Comment #8 on issue 515257 by itsbusti...@gmail.com: .scrollTo(0, 0)

ignored unless scrollY is read first
https://code.google.com/p/chromium/issues/detail?id=515257

> The original report is correct (thanks itsbusticated@!) that the issue is
> related to 465574

cool! happy to help :) one day i'll get setup to build locally so i can at
least bisect. anyway, thanks!

[chro...@googlecode.com]

Updates:
Labels: -Type-Compat Type-Bug-Regression
Blockedon: chromium:465574

Comment #9 on issue 515257 by rby...@chromium.org: .scrollTo(0, 0) ignored

unless scrollY is read first
https://code.google.com/p/chromium/issues/detail?id=515257

So this regressed in M44 (when issue 465574 landed), right?

Extending the "don't restore scroll" logic to scripted scrolls makes sense
to me.

Is there a deeper issue here that the timing of scroll restoration is hard
to predict? I.e. why should a layout trigger scroll restoration? That
makes something that's supposed to be mostly an implementation detail (when
exactly we re-layout) into something web exposed (when the scroll position
gets restored). Maybe that's a harder problem to solve that may not be
worth it though?