+Chris, this seems to be happening because we update the LayoutBoxModelObject sticky position constraints in PrePaintTreeWalk::walk from the call to updateAuxiliaryProperties but we don't update the composited sticky position constraints on the GraphicsLayer (i.e. we don't call CompositedLayerMapping::updateStickyConstraints). Do you know how this should be triggered?

After looking at the code with Ali I'm confused about why we need to update sticky position constraints in the prepaint tree walk. Seems like it should have already been done as part of the compositing inputs update?

It's done in pre-paint because SPv2 won't have a compositing input step.
It is happening now because of SPInvalidation. I think the simplest solution
is to turn off the sticky computation in the pre-paint tree walk for SPInvalidation
(but not for SPv2, which still needs it).

Why is updateStickyConstraints not getting called though? I would think the
effect of calling from the pre-paint tree walk is simply duplicated computation
(which is bad of course), but CompositedLayerMapping::updateStickyConstraints
would still get called.

Also, is this really causing the bug in Chrome 56? We don't run the pre-paint
tree walk in that version.

It's probably a red herring then, we must just be failing to invalidate sticky position constraints in this particular case.

I found the cause, test and review coming:
https://codereview.chromium.org/2683313003

It's that we short circuit trying to invalidate sticky constraints if the modified object doesn't have a layer() but we should use the enclosingLayer in this case.

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

commit b65f6264820a5c2e82aa1c9953b37ef34a4d02ec
Author: flackr <flackr@chromium.org>
Date: Mon Feb 13 17:39:22 2017

Always invalidate sticky constraints on the ancestor overflow layer

Previously we only invalidated sticky constraints on the ancestor
overflow layer if the layout object had a paint layer, but we should use
our enclosing layer (which may be the same object, its scroller or
an ancestor with a PaintLayer) to ensure that we invalidate the constraint
within the scroller.

BUG= 690580 

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

[modify] https://crrev.com/b65f6264820a5c2e82aa1c9953b37ef34a4d02ec/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
[modify] https://crrev.com/b65f6264820a5c2e82aa1c9953b37ef34a4d02ec/third_party/WebKit/Source/core/layout/LayoutBoxModelObjectTest.cpp

I verified that this is working on a local tip of tree build at 58.0.3014.0

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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

commit 643a0f48f293e0ae53903353b5bb54ed28bb4165
Author: Robert Flack <flackr@chromium.org>
Date: Wed Feb 15 15:57:17 2017

Always invalidate sticky constraints on the ancestor overflow layer

Previously we only invalidated sticky constraints on the ancestor
overflow layer if the layout object had a paint layer, but we should use
our enclosing layer (which may be the same object, its scroller or
an ancestor with a PaintLayer) to ensure that we invalidate the constraint
within the scroller.

BUG= 690580 

Review-Url: https://codereview.chromium.org/2683313003
Cr-Commit-Position: refs/heads/master@{#449993}
(cherry picked from commit b65f6264820a5c2e82aa1c9953b37ef34a4d02ec)

Review-Url: https://codereview.chromium.org/2696093003 .
Cr-Commit-Position: refs/branch-heads/2987@{#520}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/643a0f48f293e0ae53903353b5bb54ed28bb4165/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp
[modify] https://crrev.com/643a0f48f293e0ae53903353b5bb54ed28bb4165/third_party/WebKit/Source/core/layout/LayoutBoxModelObjectTest.cpp

Verified the issue on Ubuntu 14.04,Mac 10.12.3 and Win 10 using 57.0.2987.74 and its working fine.Please find the attached screen cast for the same.

Deleted: 690580_Feb_22.mp4 184 KB

	690580_Feb_22.mp4 184 KB View Download