Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is invoked

Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Updated views_unittests ViewAuraTest.RecreateLayersWithWindows
with checks that would fail prior to this fix.

Committed: https://crrev.com/e540e65b1024433c088933f558095a5e849dea25
Cr-Commit-Position: refs/heads/master@{#362535}

[tapted, 2015-11-27 00:49:53]

Description was changed from

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via LayerOwner::RecreateLayer()
and so it fails to call Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when RecreateLayer()
completes, View can't also be a LayerOwnerDelegate without causing
conflicts with subclasses of views::View which already are.

BUG=546846
==========

to

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846
TEST=Added ash_unittests WindowStateTest.RecreateLayersDuringCrossfade
which would fail prior to this fix.
==========

[tapted, 2015-11-27 00:49:53]

tapted@chromium.org changed reviewers:
+ sky@chromium.org

[tapted, 2015-11-27 03:08:40]

Hi sky, please take a look (this was the cause of the asan failures with the
paint-tab-loading-throbber-to-layer CL, from before my vacation).

[tapted, 2015-11-27 03:24:40]

Description was changed from

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846
TEST=Added ash_unittests WindowStateTest.RecreateLayersDuringCrossfade
which would fail prior to this fix.
==========

to

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Added ash_unittests WindowStateTest.RecreateLayersDuringCrossfade
which would fail prior to this fix.
==========

[sky, 2015-11-30 16:52:09]

https://codereview.chromium.org/1474993003/diff/40001/ash/wm/window_state_uni...
File ash/wm/window_state_unittest.cc (right):

https://codereview.chromium.org/1474993003/diff/40001/ash/wm/window_state_uni...
ash/wm/window_state_unittest.cc:342: TEST_F(WindowStateTest,
RecreateLayersDuringCrossfade) {
This test is ok, but you're relying on maximize recreating layers. How about
directly calling RecreateLayers?

[tapted, 2015-12-01 03:26:30]

Patchset #6 (id:100001) has been deleted

[tapted, 2015-12-01 03:35:20]

Description was changed from

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Added ash_unittests WindowStateTest.RecreateLayersDuringCrossfade
which would fail prior to this fix.
==========

to

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Updated views_unittests ViewAuraTest.RecreateLayersWithWindows
with checks that would fail prior to this fix.
==========

[tapted, 2015-12-01 04:34:43]

https://codereview.chromium.org/1474993003/diff/40001/ash/wm/window_state_uni...
File ash/wm/window_state_unittest.cc (right):

https://codereview.chromium.org/1474993003/diff/40001/ash/wm/window_state_uni...
ash/wm/window_state_unittest.cc:342: TEST_F(WindowStateTest,
RecreateLayersDuringCrossfade) {
On 2015/11/30 16:52:09, sky wrote:
> This test is ok, but you're relying on maximize recreating layers. How about
> directly calling RecreateLayers?

I did this in Patchset 4, but it made the connection to ash/../window_state a
bit tenuous. Also it started looking a lot like the existing test in
view_unittest_aura for wm::RecreateLayers

So I've incorporated the test cases into view_unittest_aura's
ViewAuraTest.RecreateLayersWithWindows - I think this make sense. It also has
the advantage of being run on more platforms, instead of just those running
ash_unittests. PTAL

[sky, 2015-12-01 15:12:25]

LGTM

[tapted, 2015-12-01 22:11:15]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2015-12-01 22:12:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1474993003/120001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1474993003/120001

[commit-bot: I haz the power, 2015-12-01 22:41:07]

Description was changed from

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Updated views_unittests ViewAuraTest.RecreateLayersWithWindows
with checks that would fail prior to this fix.
==========

to

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Updated views_unittests ViewAuraTest.RecreateLayersWithWindows
with checks that would fail prior to this fix.
==========

[commit-bot: I haz the power, 2015-12-01 22:41:08]

Committed patchset #6 (id:120001)

[commit-bot: I haz the power, 2015-12-01 22:44:22]

Description was changed from

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Updated views_unittests ViewAuraTest.RecreateLayersWithWindows
with checks that would fail prior to this fix.
==========

to

==========
Ensure View invalidates Widget::root_layers_ when LayerOwner::RecreateLayer is
invoked

Adding a Layer to a subview in a Widget currently causes functions like
wm::RecreateLayers() to leave stale copies of the old layer inside the
"root layer" cache in views::Widget. This happens because views::View
doesn't have a signal when its layer changes via
LayerOwner::RecreateLayer() and so it fails to call
Widget::UpdateRootLayers().

To fix, allow LayerOwner::RecreateLayer() to be overridden by View.
While a LayerOwnerDelegate also receives a notification when
RecreateLayer() completes, View can't also be a LayerOwnerDelegate
without causing conflicts with subclasses of views::View which already
are.

BUG=546846, 391646
TEST=Updated views_unittests ViewAuraTest.RecreateLayersWithWindows
with checks that would fail prior to this fix.

Committed: https://crrev.com/e540e65b1024433c088933f558095a5e849dea25
Cr-Commit-Position: refs/heads/master@{#362535}
==========

[commit-bot: I haz the power, 2015-12-01 22:44:23]

Patchset 6 (id:??) landed as
https://crrev.com/e540e65b1024433c088933f558095a5e849dea25
Cr-Commit-Position: refs/heads/master@{#362535}