smreagle@ thank you for the report.
I can reproduce the bug on Retina Macbook Pro.

Routing to layout team to triage.

We are also experiencing this bug. Something to note: You can easily reproduce this on a regular machine (without retina display) by using the developer tools to toggle the device toolbar and select "Laptop with HiDPI screen".

I see another more general issue here, reproducible on any display and visible in both attached gifs. I think that, in the attached test case, given this rule

thead {position: sticky; top: 0;}

the top left cell (that with "Firstname" in it) should stick as you scroll down, but it doesn't. This is unexpected to me.

I get the expected behaviour if I remove this rule

td:first-child {position: sticky; left:0;}

which, btw,

- doesn't select the top left cell nor any of its ancestors
- should only affect horizontal scrolling, not vertical

As to browser consistency, unfortunately I don't have a Mac to test with Safari and Firefox does not support position sticky on table elements (known bug).

Hi.

I tried the Performant Parallaxing from https://developers.google.com/web/updates/2016/12/performant-parallaxing with the position:sticky trick and on retina display it does the effect twice slower than expected on a retina display.

Although still a bit buggy, you can see it on https://www.frontools.rocks logo

Does chrome plan to address this before the release of 56 at the end of the month? Just curious because I have a project that uses it.

I have a patch up for review: https://codereview.chromium.org/2646133002/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/686dbbef585fd2064f1a2a3451b90e501936a589

commit 686dbbef585fd2064f1a2a3451b90e501936a589
Author: flackr <flackr@chromium.org>
Date: Wed Jan 25 23:07:42 2017

Add offset contributed to sticky position box rect by location containers

Tables are constructed using locationContainers which do not serve as the
containing block but do offset the element. These need to be included in the
sticky position offsets in the constraints.

BUG= 673538 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2646133002
Cr-Commit-Position: refs/heads/master@{#446155}

[modify] https://crrev.com/686dbbef585fd2064f1a2a3451b90e501936a589/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
[modify] https://crrev.com/686dbbef585fd2064f1a2a3451b90e501936a589/third_party/WebKit/Source/core/layout/LayoutBoxModelObjectTest.cpp
[modify] https://crrev.com/686dbbef585fd2064f1a2a3451b90e501936a589/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/686dbbef585fd2064f1a2a3451b90e501936a589/third_party/WebKit/Source/core/layout/LayoutObject.h
[modify] https://crrev.com/686dbbef585fd2064f1a2a3451b90e501936a589/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMappingTest.cpp

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hi!

When this bug is supposed to be fixed? I see the same bug in version 56.0.2924.76 (64-bit).

Thanks a lot fro quick response!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6781957c4f6c0199918d826c3e5a39bd3c7696bf

commit 6781957c4f6c0199918d826c3e5a39bd3c7696bf
Author: Robert Flack <flackr@chromium.org>
Date: Fri Jan 27 18:01:12 2017

Add offset contributed to sticky position box rect by location containers

Tables are constructed using locationContainers which do not serve as the
containing block but do offset the element. These need to be included in the
sticky position offsets in the constraints.

BUG= 673538 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2646133002
Cr-Commit-Position: refs/heads/master@{#446155}
(cherry picked from commit 686dbbef585fd2064f1a2a3451b90e501936a589)

Review-Url: https://codereview.chromium.org/2658783006 .
Cr-Commit-Position: refs/branch-heads/2987@{#151}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/6781957c4f6c0199918d826c3e5a39bd3c7696bf/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
[modify] https://crrev.com/6781957c4f6c0199918d826c3e5a39bd3c7696bf/third_party/WebKit/Source/core/layout/LayoutBoxModelObjectTest.cpp
[modify] https://crrev.com/6781957c4f6c0199918d826c3e5a39bd3c7696bf/third_party/WebKit/Source/core/layout/LayoutObject.cpp
[modify] https://crrev.com/6781957c4f6c0199918d826c3e5a39bd3c7696bf/third_party/WebKit/Source/core/layout/LayoutObject.h
[modify] https://crrev.com/6781957c4f6c0199918d826c3e5a39bd3c7696bf/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMappingTest.cpp

Unfortunately this won't get merged back to M56, but it will be fixed in the next version of M57 - I believe this is 57.0.2987.15 or later.

Verified the issue on Mac 10.12.2,Win 10 and Ubuntu 14.04 using 57.0.2987.19 and its working fine now.Hence added the respective labels for the same.

Deleted: 673538_Jan_31.mp4 709 KB

	673538_Jan_31.mp4 709 KB View Download

Hello, 

I still have some issues with the retina screen if I use css translate (see examples):

> Chrome Version 57.0.2987.98 (64-bit) 
> MacBook Pro (Retina, 13-inch, Early 2013), Intel HD Graphics 4000 1536 MB


Let me know if you need some more info / details.

Dennis

Deleted: bad-macbook-retina.gif 499 KB

	bad-macbook-retina.gif 499 KB View Download

Deleted: good-external-dell-screen.gif 542 KB

	good-external-dell-screen.gif 542 KB View Download

This bug has reverted in the latest dev and beta channels even though it is working fine in the current release. Can we make sure they get fixed before they get released?

Hello,

We discovered that the new Mac Books doesn't encounter this problem.

Grtz Dennis

Re #18, position sticky on <thead> and <tr> was intentionally disabled in  issue 695179  as we do not yet properly support position relative on those elements.

My issue is not related to  issue 695179  since I'm applying "position: sticky" to <th> and <td> tags, not <thead> or <tr>.

Furthermore, Chrome beta gives me the right behavior when using a regular screen. It only displays the bad behavior when I use HiDPI screen. And the bad behavior I'm complaining about *isn't* that "position: sticky" is disabled. It's that "position: sticky" causes crazy double-speed scrolling when using HiDPI screens (as described earlier in this bug). 

If my problem was that "position: sticky" didn't work, I would expect the elements to act like they had "position: static" and I'd expect the behavior to be the same regardless of whether I was using HiDPI or not. That's not the case here and that's why I implore you to reopen the bug.

The attached file shows the broken behavior in Chrome beta. On regular screens, it behaves as one would expect when scrolling vertically. On HiDPI screens, scrolling vertically causes the sticky elements to rise twice as fast as they should.

Deleted: bugdemo.htm 4.3 KB

bugdemo.htm 4.3 KB View Download

I created a new bug for my issue since it's not exactly the same as this one: Issue 706455

I can confirm that this issue is still occurring. 

57.0.2987.133 (64-bit)
Mac retina pro

This issue is NOT fixed. Reproduced on 58.0.3029.

Issue since v56 was position sticky makes the element invisible on high DPI (retina) screens, even with all parent elements using overflow visible.

Still able to reproduce odd layout bugs with position: sticky on Chrome 58.0.3029.110, on HiDPI displays.

I also had a problem with position sticky, so I started deleting all sibling elements of the element with position sticky (well, siblings of his parent actually). Once the offset was gone, i started deleting child element of that particular sibling. And I ended up with a h1 tag that had text-indent: -1000px on it. When I removed that style, everything was acting as it should.

Re #22, your example seems to be working on 58.0.3029.110 on both high and low DPI.

Re #29, #30 please file bugs with example html files or sites where the sticky element is not positioned correctly. Then we can identify the root cause, determine if it is already known / being fixed and get the cases resolved.

We do have a change planned to fix the composited (high dpi) positioning by giving the compositor thread the information it needs to perform the exact same calculation as the main thread.

@flackr.


Problems arise in combination with css transform (translate).  

Demo. When I use top instead of transform it's works perfectly :)
Let me know if I can help you!


Grtz Dennis

Deleted: scrolltest-sticky.html 2.9 KB

scrolltest-sticky.html 2.9 KB View Download

Re #32, the sticky position offset is a layout effect computed in terms of layout box positions. It is expected not to change when transform changes. This matches the behavior in Firefox and is a bug in Safari's current implementation: https://bugs.webkit.org/show_bug.cgi?id=164292

I was able to add "transform: scale(1)" to the parent of the sticky positioned element as a temporary workaround for when a parent higher up the tree has a transform property.

Re #34, the workaround "transform: scale(1)" to the parent of the sticky positioned element works! Thank you for saving my day.

I ran into a corner case which "transform: scale(1)" doesn't appear to fix.

If the container of the sticky header has a fixed height element with overflow the sticky header still breaks interactivity within it after a scroll.

https://stackoverflow.com/questions/49822911/issue-with-sticky-interaction-on-hidpi-mac-screens

Re comment 36: please file a new bug and reference it here. I think
the issue you are describing may be a duplicate of issue  crbug.com/827224  however.