Overflowing elements cause scrollIntoView({ behavior: 'smooth' }) to offset page in some cases
Reported by
austinta...@gmail.com,
Sep 18 2017
|
|||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36
Steps to reproduce the problem:
1. View index.html (attached).
2. Click "Scroll to bottom" link.
3. See the red offset on the right side of the page.
What is the expected behavior?
The page should scroll without shifting to the left. No red should appear on the right side. It scrolls correctly in Firefox 55+.
What went wrong?
Since the .dropdown div is translated 50px off screen, when Element.scrollIntoView({ behavior: 'smooth' }) is called it includes the overflow in its calculations, even though the extra 50px should be hidden by .container { overflow: hidden; }.
The issue disappears if you do any of the following:
- Change .dropdown { transform: translateX(50px); } to .dropdown { transform: translateX(0); } so it fits inside the viewport.
- Change .main { display: grid; } to .main { display: flex; }.
- Make div#bottom an inline element, like span.
- Use block: 'start', inline: 'nearest' params in the call to Element.scrollIntoView().
Did this work before? No
Does this work in other browsers? Yes
Chrome version: 61.0.3163.91 Channel: stable
OS Version: OS X 10.12.6
Flash Version:
I first noticed this in a CodePen example: https://codepen.io/tannerhodges/pen/dVorxG It's most noticeable when you are logged in and load the page in Left View. The Change View dropdown is hidden, but it overflows the body until you click the button and its right position is set inside the viewport. If you scroll before then (even inside an iframe) it causes the whole page to shift left.
This issue may be related to these other bugs:
- "scrollIntoView goes to the wrong position for anchors next to tall images" https://bugs.chromium.org/p/chromium/issues/detail?id=73953
,
Sep 19 2017
Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 using chrome stable version #61.0.3163.91 and latest canary #63.0.3218.0. Bisect Information: ===================== Good build: 61.0.3124.0 Revision(477839) Bad Build : 61.0.3125.0 Revision(478135) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/59f0f198fe28e6c3881f54416552552ad5434cb0..61b73ca665e42dfb7953de8a4daf1d4144805fef From the above change log suspecting below change Review URL: https://codereview.chromium.org/2650343008 sunyunjia@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression. Thanks...!!
,
Sep 19 2017
Just to update, issue is broken in M61 and is tagged with a Stable blocker. Can this be addressed. Thanks.!
,
Sep 19 2017
,
Sep 19 2017
The bisect looks correct. Although it's a regression, it looks like the CL involved is large and complex: https://codereview.chromium.org/2650343008 It's unlikely that a revert is going to make anything better.
,
Sep 19 2017
Thank you girard@ for taking a look. +amineer@ & ketakid@ (M61 Android and Chrome OS TPMs) as change this is a Blink issue adding Android and Chrome OS.
,
Sep 19 2017
Clarification on my previous comment. It would appear that behavior:smooth was newly added in https://codereview.chromium.org/2650343008 I suspect that the code "worked" before because the behavior:smooth parameter was ignored. Now we're paying attention to it (although we seem to be confused on the details.) https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView Still a bug, but not a regression.
,
Sep 19 2017
When I test the sample file (index.html) with 60.0.3112.78 the page scrolls immediately to the bottom and top, but does not show the red bar. (IOW: There is no smooth scrolling happening) BTW, thanks for index.html - that's a great sample to test and reproduce this issue.
,
Sep 19 2017
Thank you girard@ for taking a look. We're not considering this as M61 Stable blocker based on comment #7 and #8 and per offline chat with girard@.
,
Mar 8 2018
Changing pri to reflect reality but this seems like it'd be an important interop pain-point. We should work on a fix soon.
,
May 14 2018
I think I found a reliable repro for this issue: http://jsfiddle.net/LEqjm/258/
,
May 14 2018
The repro was linked in a stack overflow post here: https://stackoverflow.com/questions/11039885/scrollintoview-causing-the-whole-page-to-move
,
May 14 2018
,
May 14 2018
,
Sep 8
No longer on the Chrome team, e-mail me @google.com if any attention still required from me here, otherwise good luck! |
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by manoranj...@chromium.org
, Sep 18 2017