Hmm, this seems like another fundamental problem with scroll anchoring, which I don't have a good solution to.

Here's what I think is going on:

There's JS on the page that shows the the big version of the header when we're scrolling up and the small version of the header when we're scrolling down. The transition between the two headers happens by animating some padding, which is what triggers Layout and scroll anchoring. The sequence of events are as follows:

1) The user scrolls down and JS on the page changes the big header to the small header, triggering a layout.
2) Scroll anchoring anchors to something reasonable before the layout. After the layout, it sees that the element is moved due to the padding shrinking. and adjusts upwards.
3) JS on the page sees the new scroll position, and thinks that the user is scrolling up, and changes the big header to the small header, triggering a layout. 
4) Repeat 2 in  opposite direction.

As a result of this, the user sees the page alternating between the two.

This is basically a special case of the techcrunch topnav judder ( issue 600891 ), with the difference being that the change is triggered by the direction of the scroll and not an absolute scroll position.

Any suggestions here guys?

Relaying ojan's suggestion via chat: consider not anchoring if any of the ancestors have had their border/padding modified in that frame (layout pass?).

LayoutBlock has fields that may help here (m_widthAvailableToChildrenChanged, m_heightAvailableToChildrenChanged).

If this also fixes  issue 601906  we can consider reverting r403491.

After thinking a bit more, I am convinced that the padding/margin hack doesn't work in many cases.

In this particular case, it doesn't always work because the page transitions from the big header to the small header by 1) changing the padding on the body so that content in the viewport doesn't jump and 2) Changing the height of some part of the header to do the actual change. The two can happen in different layout passes and fields from the LayoutBlock are reset. So to fix this, we have to do something like "don't anchor if we have seen a padding/margin change on an ancestor in this layout pass, AND previous layout passes". Now this becomes even more hacky.

But more generally, there is a bigger issue that a page may not always change the padding/margin. For example  issue 626158  changes the visibility / height of a mock div to achieve the same thing, and obviously looking for padding/margin changes doesn't fix this. Because of this, we can't get rid of the de-bouncing hack either.

I have a patch in progress anyway: https://codereview.chromium.org/2245873002.

I am hopeful that the SANACLAP proposal will fix this https://docs.google.com/document/d/1YxqdqXP6bzh-77acaWwfROsvpuoJ7LXUzHU-GXmv_WM/edit.

Verified that SANACLAP fixes this.