ToT
When deferring paint of the SLAS settings on the old_layer in maximization animation [1], it caused test failure in some tests, e.g. (WorkspaceLayoutManagerTest, ChildBoundsResetOnMaximize) [2].
The reason is that, in the test, the animation duration is zero, there is not animation sequence is attached to CrossFadeObserver so that the CrossFadeObserver is destroyed and the old_layer_owner as well [3]. This will delete all the child layers and child layer_animators.
On the other hand, we DeferPaint() on the old_layer (including its children layers). For each layer, we create an observer and make the layer_animator own the observer [4].
Now in ~ScopedLayerAnimationSettings(), we iterate each observer and SetActive(). When we process the CrossFadeObserver, it will trigger ~CrossFadeObserver() as described above. This will delete the old_layer_owner, and then delete all the child layers and child layer_animators. When animator is destroyed, the animator owned observer is deleted.
Later when we iterate to the DeferredPaintObserver of the child layer, it has been already deleted. Then it failed as shown in the test.
A solution is that, when we create an animator_owned DeferredPaintObserver, we add the scoped animator to the settings' scoped_layer_animators_. When child layers are destroying, the child layer's animator will not be destroyed immediately (scoped ptr). In this way, in ~ScopedLayerAnimationSettings(), all the observers will still exist and be deleted later when scoped_layer_animators_ is destroyed.
[1] https://cs.chromium.org/chromium/src/ash/wm/window_animations.cc?l=342&rcl=ecc35b489d04d06ad4f2f3b0485e05fedccedf02
[2] https://cs.chromium.org/chromium/src/ash/wm/workspace/workspace_layout_manager_unittest.cc?l=417&rcl=ecc35b489d04d06ad4f2f3b0485e05fedccedf02
[3] https://cs.chromium.org/chromium/src/ash/wm/window_animations.cc?l=298&rcl=ecc35b489d04d06ad4f2f3b0485e05fedccedf02
[4] https://cs.chromium.org/chromium/src/ui/compositor/scoped_layer_animation_settings.cc?l=100&rcl=f393d2432378fc23c53b3b9c57b5f5a1d4818d30
Comment 1 by bugdroid1@chromium.org
, Oct 9 2017