PS: Screen Recording https://youtu.be/bmpT8sTLTGM

https://jsbin.com/vexeriberi/edit?html,css,output
Lag confirmed when running Linux, both 56 and nightly.

Using the has bisect providing the bisect results,
Good Build : 49.0.2583.0 (revision : 363342)
Bad Build : 49.0.2584.0 (revision : 363378)

You are probably looking for a change made after 363372 (known good), but no later than 363373 (first known bad).

CHANGELOG URL:
 
https://chromium.googlesource.com/chromium/src/+log/b8e6a42d49ec47adc219ef8fb57db64ea88bb4c9..b6adea99ac09da288ebfa137466727c306bfb9fa

From the CL above, assigning the issue to the concern owner 

@ajuma - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review URL: https://codereview.chromium.org/1495983003

Thanks!

The problem is that the wrong cc::Layer is getting set as the fixed-pos container. We have:
...C->L->F...
where L is the layer with the transform animation, C is its ancestor clipping layer, and F is the fixed position layer.

CompositedLayerMapping::registerScrollingLayers sets the childForSuperlayers (rather than m_graphicsLayer) as the container for fixed pos when the owning PaintLayer can contain fixed position objects, so C rather than L is set as a fixed pos container (via cc::Layer::SetIsContainerForFixedPositionLayers). So when property trees get built, the transform tree has F's transform node as a child of C's transform node, which means it isn't affected by the transform animation on L.

Looking through the history a bit, it's still not clear why we aren't just setting m_graphicsLayer as the fixed position container.

It's plausible that this was triggered by the CL from #5 (which enabled compositor property trees) since CDP implemented fixed pos differently (by reverse-scrolling the accumulated scroll offset between a layer and its fixed pos container).

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

commit d290cbee660c449245346abe4a9f2c7948df4c9e
Author: ajuma <ajuma@chromium.org>
Date: Thu Feb 09 22:54:07 2017

Set m_graphicsLayer as fixed position container

This changes the fixed position container set by CompositedLayerMapping
from childForSuperlayers() to m_graphicsLayer. When childForSuperlayers()
is different from m_graphicsLayer, setting the fixed position container
to childForSuperlayers() means that the contained fixed position layers
incorrectly ignore changes to m_graphicsLayer's transform that happen
on the compositor thread (since they're fixed to m_graphicsLayer's parent
rather than to m_graphicsLayer itself).

BUG= 686748 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

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

[modify] https://crrev.com/d290cbee660c449245346abe4a9f2c7948df4c9e/cc/layers/layer.cc
[add] https://crrev.com/d290cbee660c449245346abe4a9f2c7948df4c9e/third_party/WebKit/LayoutTests/compositing/fixed-position-container-expected.html
[add] https://crrev.com/d290cbee660c449245346abe4a9f2c7948df4c9e/third_party/WebKit/LayoutTests/compositing/fixed-position-container.html
[modify] https://crrev.com/d290cbee660c449245346abe4a9f2c7948df4c9e/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp

Thanks! How to know in which version will this be available?

It will be in Chrome 58.

Tested the issue on Windows-7, Mac 10.12.2 and Linux Ubuntu-14.04 using Chrome version 58.0.3012.0 as per the comment #0.

Observed that the fix is working as expected.

Attaching the screen cast for reference.

Hence, adding the verified labels.

Thanks.

Deleted: 686748.mp4 8.4 MB

	686748.mp4 8.4 MB View Download