New issue
Advanced search Search tips

Issue 739860 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

viewport-anchored expand direction with flexbox

Reported by ja...@bluesparklabs.com, Jul 6 2017

Issue description

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

Steps to reproduce the problem:
1. Open pen: https://codepen.io/jameswilson/full/xrpRPg/
2. Scroll through page, clicking the various toggle test cases.
3. Note that the "toggle" target button moves from under the cursor in several cases, depending on what adjacent sidebar images are available on screen.

What is the expected behavior?
All other browsers (IE, Edge, Firefox, Safari) expand downward and collapse upward, when using both jQuery slideToggle or the HTML5 <details> element (for browsers that support them).

What went wrong?
The expand/collapse direction of flex-item in flex container changes based on visible adjacent flex-items, as well as the configured value of the justify-content on those adjacent flex-items.  Further explanation in the 6 test cases in the codepen.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 59.0.3071.115  Channel: stable
OS Version: OS X 10.12.5
Flash Version: 

This was originally filed as a question on stackoverflow here but we think there is some mystery algorithm going on under the covers that needs deeper insight from a Chromium dev to surmount. There is still a bounty open on the issue.   

https://stackoverflow.com/questions/44826446
 

Comment 1 by e...@chromium.org, Jul 6 2017

Owner: cbiesin...@chromium.org
I'm guessing this is intentional to keep the element within the viewport but over to cbiesinger to clarify.

Comment 2 by e...@chromium.org, Jul 6 2017

Cc: skobes@chromium.org
Or perhaps it's scroll anchoring kicking in?

Cc: -skobes@chromium.org cbiesin...@chromium.org
Components: -Blink>Layout Blink>Scroll
Owner: skobes@chromium.org
As far as I can tell, the concern is about the scrolling behavior, not the layout behavior. That is, the layout is the same the question is just what we keep scrolled in the viewport. As such, I suspect this is related to scroll anchoring.
Status: WontFix (was: Unconfirmed)
This is the intended behavior of the scroll anchoring feature which launched in Chrome 56.

For more information about scroll anchoring including details of the algorithm please refer to the explainer at:
https://github.com/WICG/ScrollAnchoring/blob/master/explainer.md

In your "long container" test cases we will generally anchor the scroll position to the first visible <div> in the left-hand sidebar since it precedes the toggles in DOM order.

You can disable scroll anchoring with CSS "overflow-anchor: none".
Thank you skobes, et all.  

I forked the pen and added your suggested line which does indeed fix the issue, in all 6 test cases.

https://codepen.io/jameswilson/pen/JJBgNW

Sign in to add a comment