For V1, I think that we should always ask ourselves the following:
 Instead of fixing a broken case or addressing a missed opportunity, is it faster *and/or* less risky to not intervene? 

Tentatively changing the summary to reflect this mantra.

Steve: 
 1. is it less work and/or less risky to not intervene in this case? What's your estimate?
 2. What's the best(*) way to achieve this? "CSS animations used => no anchoring"?

Ideally, we would want a UMA to track such missed opportunities but this can be done as a follow-up work item.


*: best as in optimizing for less work, less risk

The test page Ojan reported this on is https://jsbin.com/jeronariga/edit?html,output.  I think it's something to do with fractional scroll offsets.

It's probably more work to avoid anchoring to elements that are animating, than to fix the bug.  But arguably we should do that anyway, since the intent of animating is to produce visible movement.  (I recall leviw raising this point in some of the early discussions.)

Yash is going to look at the fractional offset issue.  Let's separate it from the broader discussion of anchoring to animating content.  (I suspect it can be reproduced even without animations.)

I am just wrapping up some other bugs and will get on this and ramping up on scroll anchoring mid this week.

I did some investigation.

On low dpi devices (my linux workstation), I see that the localToAncestorQuad function returns decimal values (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/layout/ScrollAnchor.cpp&l=77). Is it not true that low-dpi devices don't have sub pixels and the relative bounds of the anchor object should always be an integer? When I round m_savedRelativeOffset to an integer, I don't see the judder on Ojan's test page (https://crrev.com/1818093004) on low-dpi, but unsurprisingly the problem persists on high-dpi (Android). 

I can't reason about why we're seeing the judder on high-dpi at all. From debugging, nothing obvious is going wrong there, so I am not entirely sure how to proceed. Any tips skobes, ojan, leviw? 

  

Sub-pixel accumulation is used for layout even in Low-DPI settings. Just think about the case where you have two boxes on a line, each specified to take 50% of the line width, and the line width is 101 pixels. One will get 50, one will get 51 (we always pixel-align before we paint).

We accumulate sub-pixel offset from the root when painting. In order to assure we pixel snap the same in composited and non-composited cases, we store accumulated sub-pixel information from the root on composited layers. Some compositing decisions are made differently in lo vs hi-dpi, which probably explains what you're seeing.

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

commit 3c17160bd5dd8a82b0a9bd2b9cb531e285e6386f
Author: skobes <skobes@chromium.org>
Date: Tue May 10 22:40:40 2016

Round anchor offsets to DIPs in ScrollAnchor::restore.

A fractional adjustment may not match the actual pixel delta of the anchor node.
This eliminates visible judder when the anchor node's position is animating.

Also ignore FrameView's fractional scroll offset when computing the anchor's
viewport-relative position.  This ensures we round in the right direction.

BUG= 594450 

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

[modify] https://crrev.com/3c17160bd5dd8a82b0a9bd2b9cb531e285e6386f/third_party/WebKit/Source/core/layout/ScrollAnchor.cpp
[modify] https://crrev.com/3c17160bd5dd8a82b0a9bd2b9cb531e285e6386f/third_party/WebKit/Source/core/layout/ScrollAnchorTest.cpp