GitLab

This bug occurs because of an issue in ordering of cc::Layer
destruction. LayerTreeHost maintains a mapping of ElementId to
cc::Layer. When scroll deltas are committed from the compositor thread
to the main thread, the deltas are associated with an ElementId. LTH
uses the mapping to determine the layer onto which the delta is applied.

The problem here occurs when a scroller loses its compositing layer,
then becomes composited again within the same lifecycle frame. The event
sequence:

1) Scroller becomes decomposited due to style change, GraphicsLayer is
destructed but the root cc::Layer still has a pointer to the child layer
so we don't yet destroy the associated cc::Layer
2) Scroller becomes composited again due to another style change.
3) During compositing portion of lifecycle we'll create a new
GraphicsLayer.
4) In PaintArtifactCompositor::Update, we create a new cc::Layer which
causes us to initialize the ElementId mapping in LTH when we call
Layer::SetLayerTreeHost. This clobbers the ElementId->cc::Layer mapping
for the layer removed in step 1.
5) At the end of PAC::Update, we set the new layer list on the root
which removes pointer to the layer removed in step 1. This causes the
layer to be deleted which calls cc::Layer::SetLayerTreeHost(nullptr)
causing the layer to remove its ElementId mapping. However, the mapping
for the ElementId now points to the new layer created in step 4.
6) Compositor scrolls against the ElementId now don't commit any delta
because the mapping doesn't contain an entry for ElementId.

This CL fixes the issue by causing the cc::Layer to remove itself from
the layer list when the GraphicsLayer is deleted. This will cause the
layer to be deleted and unregister itself at that time.

Bug: 979002
Change-Id: I76b195982cc09d9ed208e6f96271b7539898da4b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1690036Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Auto-Submit: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#675740}