Reproduces on ChromeOS, assuming all platforms when using composited position sticky. Yi, can you take a look? With the changes you made to make composited sticky use the same logic we shouldn't be getting this kind of double-offset.

Actually, it looks like this regressed recently, from bisect-builds in this range:
https://chromium.googlesource.com/chromium/src/+log/76542a3e01bd72e434eb72447388879d4c9c07f8..2db34c22417d64205320d05815b99c58bef29873

I suspect we may have some double offsetting from https://chromium.googlesource.com/chromium/src/+/b087bb812734db76b31de8c6e2efd62d1b0a15a7. Let's make sure we have adequate test coverage of composited sticky position in non-root scrollers so that we don't accidentally reintroduce similar bugs.

Marking as releaseblock-stable for M68 since it's a regression. Please comment
if you disagree.

Let me summarize what happened here. The regression from #2 was to fix another regression ( issue 827224 ). There was a reduced test case on #12 that showed sticky <a> didn't work correctly due to the change crrev.com/c/849417. The fix was to invalidate sticky constraints after composited scrolls. However, that kind of invalidation shouldn't happen. It seems to me that we should revert the invalidation logic and fix the <a> bug in a different way. WDYT?

You say "that kind of invalidation shouldn't happen". Why do you think so?

It looks to me that this bug was exposed by my previous patch, but was already
present in the system.

I agree with both of you.

We shouldn't need to invalidate sticky position constraints on scroll because they are meant to be scroll position independent and not require a tree update. 

However, invalidating too frequently should not cause additional errors, I agree that Chris's patch exposed a previously existing bug. So I think we should fix that bug first, and then investigate not invalidating on scroll.

Quick update: The sticky <a> not working issue was exposed here: https://chromium-review.googlesource.com/c/chromium/src/+/849417/11/third_party/WebKit/Source/core/paint/PaintLayerClipper.cpp#313.
It turns out that we do not call FragmentPaintPropertyTreeBuilder::UpdateForObjectLocationAndSize to update the fragment_data.PaintOffset after composited scrolls so chrishtr's patch above exposed the bug (the layer_bounds for the sticky <a> was incorrectly calculated). Invalidating sticky constraints forces an update so it "fixed" the sticky <a> bug. Given that we shouldn't need to do the invalidation on scroll, I'm trying to find the best place to do the update work.

If the paint offset of the fragment changes due to sticky, it has to be done
in the pre-paint tree walk. I don't think the current implementation externalizes
that. Therefore any scroll currently must force a pre-paint recomputation of
at least some of the property tree data, including paint offset.

If the paint offset for sticky were externalized into a transform value similar
to scroll, we could potentially avoid this cost, but it's tricky and requires
stacking contexts to be done cleanly.

Just uploaded a working patch at crrev.com/c/1052890. We have another bug here regarding <a>:

Clicking a sticky hyperlink after scroll won't navigate to the new page. Click it the second time or click it without scrolling it first works. Suspecting that the position on cc side after scroll becomes incorrect and a click "reveals" the true position of the sticky element therefore the second click works. See http://output.jsbin.com/rimilej/1

The problem could happen when a sticky element has an anonymous containing block while at the end of the containing block chain there is a scroller. It's being tracked via  issue 841551 .