Makes it possible for clients to directly create WindowTreeHostMus

Makes it possible for clients to directly create WindowTreeHostMus

Views code needs this so that it can subclass WindowTreeHostMus. In
particular views code wants to subclass WindowTreeHostMus. As a result
of this I changed around the following:

. Got rid of the extra window that was sometimes around in
  WindowTreeHostMus (yay!)
. Made bounds in WindowTreeHostMus always screen relative, no more
  offset and other magic. To get this right I need to fix the server
  side too, 661270, I'll do that separately.
. Made ownership clearer. Now that WindowTreeHostMus is either
  explicitly created, or passed to client code it's clear who owns it.

BUG=659155
TEST=covered by tests
R=sadrul@chromium.org

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

[sky, 2016-11-01 22:19:19]

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

[commit-bot: I haz the power, 2016-11-01 22:19:50]

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-01 23:09:54]

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

[commit-bot: I haz the power, 2016-11-01 23:09:55]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[sky, 2016-11-02 02:14:23]

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

[commit-bot: I haz the power, 2016-11-02 02:14:42]

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-02 02:46:09]

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

[commit-bot: I haz the power, 2016-11-02 02:46:10]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[sky, 2016-11-02 03:02:35]

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

[commit-bot: I haz the power, 2016-11-02 03:02:55]

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-02 03:51:52]

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

[commit-bot: I haz the power, 2016-11-02 03:51:53]

Dry run: This issue passed the CQ dry run.

[sadrul, 2016-11-02 16:03:04]

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_mus.h
File ui/aura/mus/window_mus.h (right):

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_mus....
ui/aura/mus/window_mus.h:58: // exceptions (such as the root of a
WindowTreeHost) is it false.
Update the doc?

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (left):

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:123: DCHECK(has_server_window());
Some of these DCHECK()s should still be OK?

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_host_mus.h (right):

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_host_mus.h:37: explicit
WindowTreeHostMus(WindowTreeClient* window_tree_client);
Is this used only in tests?

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/test/aura_test_...
File ui/aura/test/aura_test_base.cc (right):

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/test/aura_test_...
ui/aura/test/aura_test_base.cc:214: const display::Display& display) {}
Is it OK to not keep the WTHMus alive?

[sky, 2016-11-02 16:53:23]

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_mus.h
File ui/aura/mus/window_mus.h (right):

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_mus....
ui/aura/mus/window_mus.h:58: // exceptions (such as the root of a
WindowTreeHost) is it false.
On 2016/11/02 16:03:04, sadrul wrote:
> Update the doc?

I nuked it. There isn't really much to say.

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_port...
File ui/aura/mus/window_port_mus.cc (left):

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_port...
ui/aura/mus/window_port_mus.cc:123: DCHECK(has_server_window());
On 2016/11/02 16:03:04, sadrul wrote:
> Some of these DCHECK()s should still be OK?

The DCHECKs were intended to catch the case of windows with no associated server
window. Previously this was only possible for the roots of WindowTreeHostMus (in
some cases). As this change make it so these windows now have associated server
windows too the DCHECK didn't seem useful. It's true the DCHECK would catch not
assigning a server id, but that is really separate from what the DCHECKs were
intended for originally. WDYT?

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_tree...
File ui/aura/mus/window_tree_host_mus.h (right):

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/mus/window_tree...
ui/aura/mus/window_tree_host_mus.h:37: explicit
WindowTreeHostMus(WindowTreeClient* window_tree_client);
On 2016/11/02 16:03:04, sadrul wrote:
> Is this used only in tests?

It will be used in views. Specifically I'm working on a DesktopWindowTreeHostMus
that will subclass this. I had hoped to avoid subclassing WindowTreeHostMus, but
it turns out that makes some things awkward given how views code is structured.

More generally I'm assuming any time a client wants a top level window they
explicitly create a WindowTreeHostMus. The other constructor is used for
displays and embedding.

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/test/aura_test_...
File ui/aura/test/aura_test_base.cc (right):

https://codereview.chromium.org/2470963002/diff/60001/ui/aura/test/aura_test_...
ui/aura/test/aura_test_base.cc:214: const display::Display& display) {}
On 2016/11/02 16:03:04, sadrul wrote:
> Is it OK to not keep the WTHMus alive?

It should be fine. But I'm assuming when a test wants to test this code path it
will subclass. Or it could be I change this. I'll know once I get further
along...

[sky, 2016-11-02 16:53:37]

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

[commit-bot: I haz the power, 2016-11-02 16:54:12]

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

[sadrul, 2016-11-02 16:58:59]

lgtm

[sky, 2016-11-02 17:36:01]

The CQ bit was unchecked by sky@chromium.org

[sky, 2016-11-02 17:36:06]

The CQ bit was checked by sky@chromium.org

[commit-bot: I haz the power, 2016-11-02 17:36:49]

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-02 17:49:15]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-11-02 17:56:44]

Description was changed from

==========
Makes it possible for clients to directly create WindowTreeHostMus

Views code needs this so that it can subclass WindowTreeHostMus. In
particular views code wants to subclass WindowTreeHostMus. As a result
of this I changed around the following:

. Got rid of the extra window that was sometimes around in
  WindowTreeHostMus (yay!)
. Made bounds in WindowTreeHostMus always screen relative, no more
  offset and other magic. To get this right I need to fix the server
  side too, 661270, I'll do that separately.
. Made ownership clearer. Now that WindowTreeHostMus is either
  explicitly created, or passed to client code it's clear who owns it.

BUG=659155
TEST=covered by tests
R=sadrul@chromium.org
==========

to

==========
Makes it possible for clients to directly create WindowTreeHostMus

Views code needs this so that it can subclass WindowTreeHostMus. In
particular views code wants to subclass WindowTreeHostMus. As a result
of this I changed around the following:

. Got rid of the extra window that was sometimes around in
  WindowTreeHostMus (yay!)
. Made bounds in WindowTreeHostMus always screen relative, no more
  offset and other magic. To get this right I need to fix the server
  side too, 661270, I'll do that separately.
. Made ownership clearer. Now that WindowTreeHostMus is either
  explicitly created, or passed to client code it's clear who owns it.

BUG=659155
TEST=covered by tests
R=sadrul@chromium.org

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

[commit-bot: I haz the power, 2016-11-02 17:56:45]

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