Fixes bug in handling restacking because of transients

Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155
TEST=covered by test
R=msw@chromium.org

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

[sky, 2016-11-20 17:01:45]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-20 17:01:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[sky, 2016-11-20 17:29:39]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-20 17:29:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-20 19:52:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-20 19:52:32]

Dry run: This issue passed the CQ dry run.

[msw, 2016-11-21 19:56:34]

I'd like to suggest ways to reduce complexity here, but I don't see any...

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/client/transien...
File ui/aura/client/transient_window_client_observer.h (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/client/transien...
ui/aura/client/transient_window_client_observer.h:32: virtual void
OnWillRestackTransientChildAbove(Window* source,
nit: are there better names we can use here? like |parent| and |transient_child|
above?

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:332: DCHECK(removed);
Just so I understand: is OnTransientRestackDone only called when the server
performed the restack, so the scheduled TRANSIENT_REORDER can be removed;
otherwise, this functions isn't called and the change is left scheduled (and to
be performed soon)?

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.h (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.h:186: ServerChanges::iterator
FindServerChangeByTypeAndData(
nit: nix 'Server' here or add to functions above?

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.h:215: void PrepareForTransientRestack(WindowMus*
window) override;
nit: order these just after PrepareForServerVisibilityChange

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client_unittest.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:948: // Verifies adding/removing a
transient child doesn't notify the server of the
When is the server notified of restack? Add a test fixture for that?

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:977:
window_tree_client()->OnTransientWindowAdded(server_id(w2), server_id(w3));
Did you mean to use transient_client here and below?

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:991:
root_window()->StackChildAtBottom(w1);
Should we test some bad behavior, like StackChildAtBottom(w3)?

https://codereview.chromium.org/2517853002/diff/40001/ui/wm/core/transient_wi...
File ui/wm/core/transient_window_manager.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/wm/core/transient_wi...
ui/wm/core/transient_window_manager.cc:140: for
(aura::client::TransientWindowClientObserver& observer :
optional nit: auto& here and below?

[sky, 2016-11-21 21:22:16]

Description was changed from

==========
Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155
TEST=covered by test
R=msw@chromium.org
==========

to

==========
Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155,667478
TEST=covered by test
R=msw@chromium.org
==========

[sky, 2016-11-21 21:30:10]

Description was changed from

==========
Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155,667478
TEST=covered by test
R=msw@chromium.org
==========

to

==========
Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155
TEST=covered by test
R=msw@chromium.org
==========

[sky, 2016-11-21 21:31:43]

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/client/transien...
File ui/aura/client/transient_window_client_observer.h (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/client/transien...
ui/aura/client/transient_window_client_observer.h:32: virtual void
OnWillRestackTransientChildAbove(Window* source,
On 2016/11/21 19:56:33, msw wrote:
> nit: are there better names we can use here? like |parent| and
|transient_child|
> above?

Done.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:332: DCHECK(removed);
On 2016/11/21 19:56:34, msw wrote:
> Just so I understand: is OnTransientRestackDone only called when the server
> performed the restack,

OnTransientRestackDone is always called.

> so the scheduled TRANSIENT_REORDER can be removed;
> otherwise, this functions isn't called and the change is left scheduled (and
to
> be performed soon)?

Yes, this is to balance the OnWillRestackTransientChildAbove and is necessary
because the call from TransientWindowManager to StackChildAbove() may do nothing
(the window may already be in place).  Ideally OnDidRestackTransientChildAbove
wouldn't be necessary, but it is because TransientWindowManager is outside of
aura. That is, the only way to possibly get rid of
OnWillRestackTransientChildAbove  is to add context to why the reorder is
happening. That would be a pain though. Another possibility is to move transient
management back into aura proper, most likely on aura::Window. Doing that would
mean aura::Window knows the reorder is the result of a transient being
added/removed and could call different functions on WindowPort. That a bigger
change than I want to bite off here though.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.h (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.h:186: ServerChanges::iterator
FindServerChangeByTypeAndData(
On 2016/11/21 19:56:34, msw wrote:
> nit: nix 'Server' here or add to functions above?

Done.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.h:215: void PrepareForTransientRestack(WindowMus*
window) override;
On 2016/11/21 19:56:34, msw wrote:
> nit: order these just after PrepareForServerVisibilityChange

Done.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client_unittest.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:948: // Verifies adding/removing a
transient child doesn't notify the server of the
On 2016/11/21 19:56:34, msw wrote:
> When is the server notified of restack? Add a test fixture for that?

For a transient? Never. The assertions on 971/974 verify no restacking is
scheduled.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:977:
window_tree_client()->OnTransientWindowAdded(server_id(w2), server_id(w3));
On 2016/11/21 19:56:34, msw wrote:
> Did you mean to use transient_client here and below?

Done.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:991:
root_window()->StackChildAtBottom(w1);
On 2016/11/21 19:56:34, msw wrote:
> Should we test some bad behavior, like StackChildAtBottom(w3)?

Ugh. This uncovered a bug in aura 667460.

https://codereview.chromium.org/2517853002/diff/40001/ui/wm/core/transient_wi...
File ui/wm/core/transient_window_manager.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/wm/core/transient_wi...
ui/wm/core/transient_window_manager.cc:140: for
(aura::client::TransientWindowClientObserver& observer :
On 2016/11/21 19:56:34, msw wrote:
> optional nit: auto& here and below?

I like not using auto here as the observers are different than observers_.

[sky, 2016-11-21 21:31:45]

The CQ bit was checked by sky@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-21 21:32:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[msw, 2016-11-21 22:34:49]

It's a little tough to grok; but lgtm with a nit.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:332: DCHECK(removed);
On 2016/11/21 21:31:43, sky wrote:
> On 2016/11/21 19:56:34, msw wrote:
> > Just so I understand: is OnTransientRestackDone only called when the server
> > performed the restack,
> 
> OnTransientRestackDone is always called.
> 
> > so the scheduled TRANSIENT_REORDER can be removed;
> > otherwise, this functions isn't called and the change is left scheduled (and
> to
> > be performed soon)?
> 
> Yes, this is to balance the OnWillRestackTransientChildAbove and is necessary
> because the call from TransientWindowManager to StackChildAbove() may do
nothing
> (the window may already be in place).  Ideally OnDidRestackTransientChildAbove
> wouldn't be necessary, but it is because TransientWindowManager is outside of
> aura. That is, the only way to possibly get rid of
> OnWillRestackTransientChildAbove  is to add context to why the reorder is
> happening. That would be a pain though. Another possibility is to move
transient
> management back into aura proper, most likely on aura::Window. Doing that
would
> mean aura::Window knows the reorder is the result of a transient being
> added/removed and could call different functions on WindowPort. That a bigger
> change than I want to bite off here though.

Okay, so the transient reordering step sometimes does nothing, but we always
schedule and remove TRANSIENT_REORDER, because OnWillMoveChild may notify
window_tree_client_, but it never removes the TRANSIENT_REORDER change.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client_unittest.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:948: // Verifies adding/removing a
transient child doesn't notify the server of the
On 2016/11/21 21:31:43, sky wrote:
> On 2016/11/21 19:56:34, msw wrote:
> > When is the server notified of restack? Add a test fixture for that?
> 
> For a transient? Never. The assertions on 971/974 verify no restacking is
> scheduled.

Okay, maybe I get it now. The server gets the call to add/remove transient and
*sometimes* causes a reordering. The server is never told by a client to reorder
for an added/removed transient. It's not entirely obvious, or I'm just slow...

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/client/transien...
File ui/aura/client/transient_window_client_observer.h (right):

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/client/transien...
ui/aura/client/transient_window_client_observer.h:33: virtual void
OnWillRestackTransientChildAbove(Window* parent,
optional nit: rename 'stack'->'order' throughout.

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client_unittest.cc (right):

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:1004: // result in placing |w2| above
its transient parent.
Did you mean "above its transient child."?

[commit-bot: I haz the power, 2016-11-21 22:36:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-21 22:36:02]

Dry run: This issue passed the CQ dry run.

[sky, 2016-11-21 22:41:10]

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:332: DCHECK(removed);
On 2016/11/21 22:34:49, msw wrote:
> On 2016/11/21 21:31:43, sky wrote:
> > On 2016/11/21 19:56:34, msw wrote:
> > > Just so I understand: is OnTransientRestackDone only called when the
server
> > > performed the restack,
> > 
> > OnTransientRestackDone is always called.
> > 
> > > so the scheduled TRANSIENT_REORDER can be removed;
> > > otherwise, this functions isn't called and the change is left scheduled
(and
> > to
> > > be performed soon)?
> > 
> > Yes, this is to balance the OnWillRestackTransientChildAbove and is
necessary
> > because the call from TransientWindowManager to StackChildAbove() may do
> nothing
> > (the window may already be in place).  Ideally
OnDidRestackTransientChildAbove
> > wouldn't be necessary, but it is because TransientWindowManager is outside
of
> > aura. That is, the only way to possibly get rid of
> > OnWillRestackTransientChildAbove  is to add context to why the reorder is
> > happening. That would be a pain though. Another possibility is to move
> transient
> > management back into aura proper, most likely on aura::Window. Doing that
> would
> > mean aura::Window knows the reorder is the result of a transient being
> > added/removed and could call different functions on WindowPort. That a
bigger
> > change than I want to bite off here though.
> 
> Okay, so the transient reordering step sometimes does nothing, but we always
> schedule and remove TRANSIENT_REORDER, because OnWillMoveChild may notify
> window_tree_client_, but it never removes the TRANSIENT_REORDER change.

You got it.

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client_unittest.cc (right):

https://codereview.chromium.org/2517853002/diff/40001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:948: // Verifies adding/removing a
transient child doesn't notify the server of the
On 2016/11/21 22:34:49, msw wrote:
> On 2016/11/21 21:31:43, sky wrote:
> > On 2016/11/21 19:56:34, msw wrote:
> > > When is the server notified of restack? Add a test fixture for that?
> > 
> > For a transient? Never. The assertions on 971/974 verify no restacking is
> > scheduled.
> 
> Okay, maybe I get it now. The server gets the call to add/remove transient and
> *sometimes* causes a reordering. The server is never told by a client to
reorder
> for an added/removed transient. It's not entirely obvious, or I'm just slow...

You got it. If a reorder needs to happen, the server does it too. So that if the
client tells the server about the reorder as well we get failures.

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/client/transien...
File ui/aura/client/transient_window_client_observer.h (right):

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/client/transien...
ui/aura/client/transient_window_client_observer.h:33: virtual void
OnWillRestackTransientChildAbove(Window* parent,
On 2016/11/21 22:34:49, msw wrote:
> optional nit: rename 'stack'->'order' throughout.

I left this as stack. It better fits with the StackChild* calls in Window as
well as the delegate.

[sky, 2016-11-21 22:41:15]

The CQ bit was checked by sky@chromium.org

[commit-bot: I haz the power, 2016-11-21 22:41:47]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[msw, 2016-11-21 22:43:50]

still lgtm, just wanted to highlight an unaddressed nit/q

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client_unittest.cc (right):

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:1004: // result in placing |w2| above
its transient parent.
On 2016/11/21 22:34:49, msw wrote:
> Did you mean "above its transient child."?

ping fyi

[sky, 2016-11-21 22:50:34]

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_client_unittest.cc (right):

https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_client_unittest.cc:1004: // result in placing |w2| above
its transient parent.
On 2016/11/21 22:34:49, msw wrote:
> Did you mean "above its transient child."?

Indeed. Will update.

[commit-bot: I haz the power, 2016-11-21 22:54:37]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1479768075826850,
"parent_rev": "5c50634779479aea313af7bb3e8c2106aeb99958", "commit_rev":
"2efb21b6e77638a76a9bf9ccaeb9a3658a9dfc2c"}

[commit-bot: I haz the power, 2016-11-21 22:55:08]

Description was changed from

==========
Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155
TEST=covered by test
R=msw@chromium.org
==========

to

==========
Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155
TEST=covered by test
R=msw@chromium.org
==========

[commit-bot: I haz the power, 2016-11-21 22:55:09]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-11-21 22:57:02]

Description was changed from

==========
Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155
TEST=covered by test
R=msw@chromium.org
==========

to

==========
Fixes bug in handling restacking because of transients

When a window is added/removed as a transient the siblings of the
window may get reordered. For example, consider windows W1, W2 and T1
in that order. If T1 is made a transient of W1, then T1 is stacked on
top of W1 so that the resulting order is W1, T1, W2. On the mus server
side when a window is made a transient mus handles the restacking
(meaning mus also restacks the windows on its side and does not send
out notification of the window moves, only that a transient was
added/removed, it assumes the client handles the restacking). If the
client also sends messages to restack then the changes fail (because
the windows are already in order).

Prior to this fix aura-mus would send moves for the transient restack,
resulting in a crash.

BUG=659155
TEST=covered by test
R=msw@chromium.org

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

[commit-bot: I haz the power, 2016-11-21 22:57:03]

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

[sky, 2016-11-21 23:00:33]

On 2016/11/21 22:50:34, sky wrote:
>
https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
> File ui/aura/mus/window_tree_client_unittest.cc (right):
> 
>
https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
> ui/aura/mus/window_tree_client_unittest.cc:1004: // result in placing |w2|
above
> its transient parent.
> On 2016/11/21 22:34:49, msw wrote:
> > Did you mean "above its transient child."?
> 
> Indeed. Will update.

I'm fixing this comment in the window type property patch
https://codereview.chromium.org/2517853002/.

[sky, 2016-11-21 23:04:55]

On 2016/11/21 23:00:33, sky wrote:
> On 2016/11/21 22:50:34, sky wrote:
> >
>
https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
> > File ui/aura/mus/window_tree_client_unittest.cc (right):
> > 
> >
>
https://codereview.chromium.org/2517853002/diff/60001/ui/aura/mus/window_tree...
> > ui/aura/mus/window_tree_client_unittest.cc:1004: // result in placing |w2|
> above
> > its transient parent.
> > On 2016/11/21 22:34:49, msw wrote:
> > > Did you mean "above its transient child."?
> > 
> > Indeed. Will update.
> 
> I'm fixing this comment in the window type property patch
> https://codereview.chromium.org/2517853002/.

That should be https://codereview.chromium.org/2514243002/