New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 775387 link

Starred by 1 user
Status: WontFix
Owner:
skobes@chromium.org
Closed: Jan 7
Cc:
█ sc00335...@techmahindra.com
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

changing height of position:sticky element causes confusing scroll anchoring behavior

Reported by mike.phe...@ephox.com, Oct 17 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce the problem:
1. open the attached file
2. open the console also
3. scroll the page so that the blue 'Toolbar' element and button is stuck to the top of the screen
4. click the button

What is the expected behavior?
- the orange (container) element will stay in the same visual location on the screen and its content will scroll down to make room for the larger blue box
- the 'top' position of the orange box does not change (see console log)

What went wrong?
- the 'top' position of the orange (container) element changed
- the orange element moved on the screen

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 61.0.3163.100  Channel: stable
OS Version: 10.0
Flash Version:
test-pos-sticky.html
2.4 KB View Download

Comment 1 by woxxom@gmail.com, Oct 17 2017 

Caused by Scroll Anchoring intervention.
To opt out simply add "overflow-anchor: none;" to the scrolling element (in this case it's "body").
More info: https://github.com/WICG/ScrollAnchoring/blob/master/explainer.md

Comment 2 by dtapu...@chromium.org, Oct 17 2017

Components: Blink>Scroll

Comment 3 by ligim...@chromium.org, Oct 17 2017

Labels: Needs-Triage-M61

Comment 4 by mike.phe...@ephox.com, Oct 17 2017 

Thanks!

Comment 5 by sc00335...@techmahindra.com, Oct 18 2017

Cc: sc00335...@techmahindra.com
Labels: -Type-Bug -Pri-2 hasbisect-per-revision Triaged-ET M-64 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: flackr@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce this issue on reported version 61.0.3163.100 and on latest canary 64.0.3242.0 using Window10,Ubuntu 14.04 and Mac 10.12.6 with steps mentioned in comment#0.

Manual Bisect Info:
===============
Good Build: 56.0.2909.0
Bad Build: 56.0.2910.0 

You are probably looking for a change made after 429926 (known good), but no later than 429927 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/851c6f72587756eab07e345c2212c0d45c8c10e1..77a8c51a440e0741315ff5e9e77441b86cbbc56d

Review-Url: https://codereview.chromium.org/2468283005
 
Suspecting same from changelog.

@flackr: Please confirm the bug and help in re-assigning if it is not related to your change.

Thanks!

Comment 6 by flackr@chromium.org, Oct 18 2017

Owner: skobes@chromium.org
Summary: changing height of position:sticky element causes confusing scroll anchoring behavior (was: changing height of position:sticky element changes 'top' position of containing element)
The layout of everything seems to be fine. The toolbar changes from height 53 to height 200 which causes the iframeContainer to shrink from 447 to 300 (due to the flexbox). The absolute top position of the container changes by the expected 200 - 53 = 147 to account for the change and scroll anchoring adjusts the scroll position which causes the bounding client rect to end up going up.

I agree the net result is a little unexpected, over to skobes to see if we could do better with the scroll anchoring targeting.

Comment 7 by skobes@chromium.org, Oct 18 2017

Labels: -Pri-1 -Type-Bug-Regression Pri-2 Type-Bug

Comment 8 by nzolghadr@chromium.org, Jan 3 

skobes@ any action item for this?

Comment 9 by skobes@chromium.org, Jan 7

Status: WontFix (was: Assigned)
This is WAI.  Scroll anchoring selects the <iframe> element to anchor to as it is the first (non-sticky) element in the viewport.
►

Sign in to add a comment