mus: Allow the WM to specify the windows that can have active children.

mus: Allow the WM to specify the windows that can have active children.

. The sample WindowManager creates various containers, and marks the container
  for user windows to be allowed to have active windows. Other containers may
  also be allowed to have active children in the future.

. For mandoline, the BrowserWindow (which is the WM) marks the root as being
  able to contain active windows. Consequently, the browser window can be
  properly activated.

. Raise a Window to the top when it becomes active.

BUG=548422
Committed: https://crrev.com/5b2aedd64f34977e6ef73e22681f4f0dbdc0ec42
Cr-Commit-Position: refs/heads/master@{#361274}

[sadrul, 2015-11-19 00:04:39]

Description was changed from

==========
mus: Allow the WM to specify the windows that can have active children.

. The sample WindowManager creates various containers, and marks the container
  for user windows to be allowed to have active windows. Other containers may
  also be allowed to have active children in the future.

. For mandoline, the BrowserWindow (which is the WM) marks the root as being
  able to contain active windows. Consequently, the browser window can be
  properly activated.

BUG=548422
==========

to

==========
mus: Allow the WM to specify the windows that can have active children.

. The sample WindowManager creates various containers, and marks the container
  for user windows to be allowed to have active windows. Other containers may
  also be allowed to have active children in the future.

. For mandoline, the BrowserWindow (which is the WM) marks the root as being
  able to contain active windows. Consequently, the browser window can be
  properly activated.

. Raise a Window to the top when it becomes active.

BUG=548422
==========

[sadrul, 2015-11-19 00:23:57]

sadrul@chromium.org changed reviewers:
+ ben@chromium.org

[sadrul, 2015-11-19 00:23:57]

Still working on new tests, but there's enough code here to explain what I am
doing. There are still a number of TODOs, which I hope to address in subsequent
patches.

[Ben Goodger (Google), 2015-11-19 07:26:25]

https://codereview.chromium.org/1459463004/diff/60001/components/mus/public/i...
File components/mus/public/interfaces/window_tree_host.mojom (right):

https://codereview.chromium.org/1459463004/diff/60001/components/mus/public/i...
components/mus/public/interfaces/window_tree_host.mojom:32:
SetActivationParent(uint32 window_id, bool enable);
how about AddActivationParent & RemoveActivationParent?

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/focus...
File components/mus/ws/focus_controller.cc (right):

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/focus...
components/mus/ws/focus_controller.cc:67: // focused.
what's the reason for this policy?

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/windo...
File components/mus/ws/window_tree_host_impl.cc (right):

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/windo...
components/mus/ws/window_tree_host_impl.cc:144: bool wm_misbehaving = false;
what's this for?

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/windo...
components/mus/ws/window_tree_host_impl.cc:227:
new_active_window->parent()->StackChildAtTop(new_active_window);
does this account for transients?

[sadrul, 2015-11-19 19:33:34]

https://codereview.chromium.org/1459463004/diff/60001/components/mus/public/i...
File components/mus/public/interfaces/window_tree_host.mojom (right):

https://codereview.chromium.org/1459463004/diff/60001/components/mus/public/i...
components/mus/public/interfaces/window_tree_host.mojom:32:
SetActivationParent(uint32 window_id, bool enable);
On 2015/11/19 07:26:24, Ben Goodger (Google) wrote:
> how about AddActivationParent & RemoveActivationParent?

Done.

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/focus...
File components/mus/ws/focus_controller.cc (right):

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/focus...
components/mus/ws/focus_controller.cc:67: // focused.
On 2015/11/19 07:26:24, Ben Goodger (Google) wrote:
> what's the reason for this policy?

Hm, I thought this is what we wanted to do. But I was wrong; Chrome doesn't move
focus when clicking on a non-focusable window. Made this do an early return
instead.

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/windo...
File components/mus/ws/window_tree_host_impl.cc (right):

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/windo...
components/mus/ws/window_tree_host_impl.cc:144: bool wm_misbehaving = false;
On 2015/11/19 07:26:24, Ben Goodger (Google) wrote:
> what's this for?

I would normally do a DCHECK(window) here, but a misbehaving WM could then bring
down mus. I was contemplating having some mechanism to signal a misbehaving WM,
or shut it down + restart it if it is misbehaving too often. But we can look at
that in the future. Removed the relevant code.

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/windo...
components/mus/ws/window_tree_host_impl.cc:227:
new_active_window->parent()->StackChildAtTop(new_active_window);
On 2015/11/19 07:26:25, Ben Goodger (Google) wrote:
> does this account for transients?

StackChildAtTop() etc. account for transients, yep. (turns out transiency isn't
quite set-up correctly yet from views. Fix up in
https://codereview.chromium.org/1462123002/)

[sadrul, 2015-11-21 08:49:23]

Added an apptest. PTAL

[Ben Goodger (Google), 2015-11-23 22:29:45]

lgtm

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/focus...
File components/mus/ws/focus_controller.cc (right):

https://codereview.chromium.org/1459463004/diff/60001/components/mus/ws/focus...
components/mus/ws/focus_controller.cc:67: // focused.
On 2015/11/19 19:33:34, sadrul wrote:
> On 2015/11/19 07:26:24, Ben Goodger (Google) wrote:
> > what's the reason for this policy?
> 
> Hm, I thought this is what we wanted to do. But I was wrong; Chrome doesn't
move
> focus when clicking on a non-focusable window. Made this do an early return
> instead.

Yeah I was concerned you'd be left in a bad state where key events wouldn't get
dispatched to anyone.

[sadrul, 2015-11-24 07:38:53]

The CQ bit was checked by sadrul@chromium.org

[sadrul, 2015-11-24 07:38:54]

The patchset sent to the CQ was uploaded after l-g-t-m from ben@chromium.org
Link to the patchset: https://codereview.chromium.org/1459463004/#ps180001
(title: "tot-merge")

[commit-bot: I haz the power, 2015-11-24 07:40:03]

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

[commit-bot: I haz the power, 2015-11-24 07:46:15]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2015-11-24 07:47:16]

Patchset 10 (id:??) landed as
https://crrev.com/5b2aedd64f34977e6ef73e22681f4f0dbdc0ec42
Cr-Commit-Position: refs/heads/master@{#361274}