I see the issue in the non-composite (second) table, not the first one.

See also https://output.jsbin.com/puyutid/. When there are two `th`s in a non-composited table, both with position: sticky set, they behave differently.

Re #1: On what version of Chrome, OS, and is that a high or low DPI screen?

Your other reproduction is not the same bug as this - but is definitely a bug. Forked issue 699137 to investigate that.

I've just realized that you were asking about your test case. :)

The non-composited test case is broken for me on a Retina screen and the composited works fine (in latest Canary). On the low-DPI screen it's the reverse.

So the conclusions are similar to what I described in https://bugs.chromium.org/p/chromium/issues/detail?id=699137#c1.

Note: bug does not repro if table is not a stacking context. Reason appears to be however that the <th> gets a layer (although the layer isn't directly associated with the <th> element in the devtools layer panel, it is the same size as the <th>).

See http://output.jsbin.com/bodoyog

This shouldn't be failing the check in requiresCompositingForScrollDependentPosition https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/compositing/CompositingReasonFinder.cpp?q=CompositingReasonFinder&sq=package:chromium&dr=CSs&l=226 because it's already in a composited ancestor so has lost LCD text. This should be getting promoted.

I chatted with Yi about this. It looks like my comment in #5 isn't correct because the scroller isn't composited. We should however update the layer position from the call to PaintLayerScrollableArea::UpdateScrollOffset https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp?type=cs&l=396 which should cause a paint invalidation making us repaint the sticky element. You can see that it does get painted correctly if you invalidate paint by selecting text on the page.

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

commit e44021ea6e3e18bc59854b4c8d30999f1fc4379f
Author: yigu <yigu@chromium.org>
Date: Thu May 18 22:07:55 2017

Fix the bug that sticky element may not be correctly invalidated due to
non-promotion.

When a non composited sticky element is nested in a compositied ancestor
which requires repaint on scroll, the sticky element should also be
composited to have correct paint invalidation.

TEST=compositing/overflow/non-composited-sticky-element-in-main-thread-scrolled-composited-ancestor.html;
BUG= 698358 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

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

[add] https://crrev.com/e44021ea6e3e18bc59854b4c8d30999f1fc4379f/third_party/WebKit/LayoutTests/compositing/overflow/non-composited-sticky-element-in-main-thread-scrolled-composited-ancestor-expected.html
[add] https://crrev.com/e44021ea6e3e18bc59854b4c8d30999f1fc4379f/third_party/WebKit/LayoutTests/compositing/overflow/non-composited-sticky-element-in-main-thread-scrolled-composited-ancestor.html
[modify] https://crrev.com/e44021ea6e3e18bc59854b4c8d30999f1fc4379f/third_party/WebKit/Source/core/layout/compositing/CompositingRequirementsUpdater.cpp