I've attached screencast showing both scenarions (with `top: 0` specified on thead or not) in Chrome & Safari.

Note that in Chrome the header text is partially cut off; in Safari it's fine.

Deleted: chrome-top-0.mov 375 KB

chrome-top-0.mov 375 KB Download

Deleted: chrome-top-missing.mov 212 KB

chrome-top-missing.mov 212 KB Download

Deleted: safari-top-0.mov 367 KB

safari-top-0.mov 367 KB Download

Deleted: safari-top-missing.mov 172 KB

safari-top-missing.mov 172 KB Download

 Issue 672710  may be related.

Locally, I see 

55.0.2883.87 (Official Build) (64-bit) : Header scrolls down
58.0.3010.0 (Official Build) canary (64-bit) : Header stays put

Test team - can you please bisect this?

@mikelawther For me both versions fail the test, including the latest Canary  58.0.3011.0. Perhaps it's macOS-only?

#4 - Chrome 55 does not support position: sticky, so this issue is irrelevant to it. Support for position: sticky starts from Chrome 56.

Cc'ing 	smcgruer@ from  Issue 672710  for confirmation if the CL under review would work for this as well and confirmation if  Issue 672710  is same.

Position: Sticky was enabled by https://codereview.chromium.org/2468283005

This is not nested sticky (as far as I can see there is only one sticky element), so it does not relate to  issue 672710 . 

A few notes:

1. It's compositing-only, which will explain the difference in people who can/can't reproduce it on the same version of Chrome. High DPI devices will be promoting the scroller, low DPI devices won't be.

2. There is a flexbox involved, which has previously caused issues (e.g.  issue 690580 ).

3. However my fix for  issue 672710  does appear to fix the problem as long as the sticky is applied to the <th> instead of the <thead> (as per the CSS 2.1 spec for relative positioning, we are planning in the intermediate term to only honor position: sticky on <th> elements.)


flackr - do you want to investigate since it isn't nested sticky, or are we happy to just bundle it under  issue 672710  since apparently my CL will fix this too?

 Issue 690580  seems like it would be unrelated since there's no layout change as far as I can tell.

I think we should add a test which will regress if this particular case regresses but otherwise consider it fixed as part of  issue 672710 . This test could apply sticky top: 0 to the thead and th (so as to work with our current limitations but ensure that if thead sticky top: 0 becomes problematic when we do support it that we catch that case).

#8 - the specification says that position: sticky acts like position: relative for table elements. I think <thead> is considered as a table element (the specification does not seem to mean <table> specifically), so why is it being sticky?
If I understand correctly, Firefox does not stick table elements.

Interesting. Firefox has a ticket to make `position: sticky` work on table parts so it's not that it being ignored inside tables is intended in a long run.

If Safari did & Firefox plans to then perhaps the spec could be amended? This would be a very useful feature, people do need sticky table headers pretty often.

 Issue 692429  has been merged into this issue.

Removing the Needs-Bisect as the owner for this is identified. Please add it back if this requires bisect.

Thank you!

Re #10, #11: back in Oct 2014 a clarification was requested for table elements, and the reply[1] appears to back the interpretation that position: sticky should apply to table elements and the element should be offset relative to the flow root not its normal position. A wording clarification was promised but appears not to have materialized.

Note however that Chromium currently follows the CSS 2.1 spec for position: relative[2], and in the short term at least this is going to force us to ignore position: sticky on <thead> and <tr> elements, as the Blink implementation of those elements makes some CSS 2.1 based assumptions. We do and will support sticky <th> elements.

[1]: https://lists.w3.org/Archives/Public/www-style/2014Oct/0236.html
[2]: https://www.w3.org/TR/CSS2/visuren.html#propdef-position

This is a dupe of  issue 692263 ; both are caused by us incorrectly including the scroll offset in parent_relative_sticky_box_rect and will be fixed by the same patch.