New issue
Advanced search Search tips

Issue 695729 link

Starred by 10 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Position sticky has incorrect offsets when other elements have certain CSS property values

Reported by brad.kem...@gmail.com, Feb 24 2017

Issue description

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

Steps to reproduce the problem:
1. go to http://jsbin.com/hibudi/2/edit?html,css,output
2. Note that the dark bar on the top is offset to the left.
3. Remove the box-shadow from #bar, and then resize the window to see the effect go away.
4. Put the shadow back, and the problem returns. 
5. Change the z-index of 'nav' to 1 (instead of -1), see the problem go away again
6. Change the z-index of 'nav' to -1 and see the problem return
7. Change 'nav' to 'position:abolute' (instead of 'position:fixed'), and the problem returns.
8. Add a little margin to 'body' to see the offsetting more clearly, but the problem goes away when the body margin is greater than or equal to the box-shadow's blur and spread added together.
9. The problem also goes away when 'article' is not tall enough to allow scrolling.

What is the expected behavior?
Changing a box-shadow value (or z-index) on a different element should have no effect on where the sticky item is painted. A wide margin on the body should not be required if a person wants to have box-shadow and sticky in the same document.

What went wrong?
Having a box-shadow with blur+spread greater than the body margin causes a separate 'position:sticky' element to be offset by an amount roughly equal to the blur+spread, when there is also a fixed position element with 'z-index:-1'. Seriously, that's what I've been able to reduce it down to.

Did this work before? Yes 55, I think.

Does this work in other browsers? Yes

Chrome version: 57.0.2987.54  Channel: beta
OS Version: OS X 10.12.3
Flash Version: 

It also happens in version 56 on Android. I haven't checked it on Windows. 

Testing the equivalent in Safari requires '-webkit-sticky', not just 'sticky'.

 
When I said "Did this work before? Yes 55, I think.", I meant, that before 'position:sticky' was implemented, this problem didn't exist. I could detect 'position:sticky' support and have other CSS for fallback. 

Now that version 56+ supports 'position:sticky', it ruins my site by not supporting it well enough. I would post that site URL here, except very, very soon it will also check to make sure the browser is not Chrome before enabling the sticky features on the site.
Here's another example of this bug, caused by box-shadow on a sticky element's decendent: https://github.com/18F/web-design-standards-docs/issues/181

A simplified JSBin of it is available here: https://jsbin.com/cihujewebi/edit?html,css,output
Labels: Needs-Bisect Needs-Triage-M57

Comment 4 by rbyers@chromium.org, Feb 27 2017

Components: -Blink>CSS Blink>Layout
Labels: -Needs-Bisect Hotlist-ThreadedRendering
Owner: flackr@chromium.org
No need for a bisect, almost certainly introduced by shipping position:sticky -
  issue 231752  

Comment 5 by e...@chromium.org, Feb 28 2017

Status: Available (was: Unconfirmed)
Cc: flackr@chromium.org
 Issue 698291  has been merged into this issue.
Cc: smcgruer@chromium.org
Components: -Blink>Layout Internals>Compositing
Owner: yigu@chromium.org
Status: Assigned (was: Available)
Seems like there must be a problem with the LayerStickyPositionConstraint or the main_thread_offset in StickyPositionNodeData. Yi, can you have a look?
Note: this is compositor-only, main thread sticky works fine. So you need to use a high DPI device or use the devtools emulator.
I have the same issue, though only on Laptop screen. On wide screen the issue does not exist. See
http://codepen.io/clanceyp/full/OpVwRB
(The sticky panel in the right in incorrectly positioned on laptop screen, due to the position:relative; overflow:hidden; and transform: rotate; on child elements)

Comment 10 by yigu@chromium.org, Mar 7 2017

The examples from #2 and #9 cannot be reproduced in Canary or Beta. The original bug is reproducible though.
I can reproduce the original bug with my Mac only on a retina display, while it displays perfectly fine on a non-retina external monitor:

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Comment 12 by fet...@gmail.com, Apr 6 2017

Chrome version:	57.0.2987.133
Operating system: Macintosh, Version: OS X 10.11.6, Channel: Stable

I reproduced the same issue in something I worked...

I worked around the problem applying an opacity (see Expected behaviour url).

What I notice, is that you add opacity (example: 0.99999997) to the div that has overflow: scroll, that wraps the position: sticky element will fix the problem.

Other thing that I notice, is that the offset caused to the element that has position: sticky will be the same has the width (in my case) of the window

Wrong behaviour
http://jsbin.com/vizacebuso/edit?html,output

Expected behaviour
http://jsbin.com/meqowicolo/1/edit?html,output

PS: check the comments

Comment 13 by yigu@chromium.org, Apr 20 2017

Status: Started (was: Assigned)

Comment 15 by yigu@chromium.org, May 23 2017

Cc: yigu@chromium.org
 Issue 725202  has been merged into this issue.
Is there a way to be notified when this fix is released in a Chrome update?
https://storage.googleapis.com/chromium-find-releases-static/2cc.html#2ccdd05fd1c84d98775b5559ac2b09ba742ceaca

"Commit 2ccdd05f... initially landed in 60.0.3104.0

No merges found."

This fix should be in Chrome 60.

Comment 18 by yigu@chromium.org, Jun 6 2017

You could also find the current chrome version on different os here: https://omahaproxy.appspot.com/
Awesome, thanks! That "Find Releases" tool is super helpful. 👍

Sign in to add a comment