views/mus: Set-up transient windows correctly.

views/mus: Set-up transient windows correctly.

When a transient widget is created, make sure to set-up the transiency on mus
windows correctly as well.

Also, change policy in mus to allow adding/removing transient windows as long
as the client created either the parent or the child window.

Also, rename window-property defines in mus to have the MUS_ prefix, to avoid
conflict with the same macros for setting properties on aura::Windows.

BUG=none

Committed: https://crrev.com/1e5ea7a809355aecd0acc5817d40f0ffbeea1476
Cr-Commit-Position: refs/heads/master@{#369121}

[sadrul, 2015-11-19 19:22:26]

Description was changed from

==========
views/mus: Set-up transient windows correctly.

When a transient widget is created, make sure to set-up the transiency on mus
windows correctly as well.

BUG=none
==========

to

==========
views/mus: Set-up transient windows correctly.

When a transient widget is created, make sure to set-up the transiency on mus
windows correctly as well.

Also, change policy in mus to allow adding/removing transient windows as long
as the client created either the parent or the child window.

Also, rename window-property defines in mus to have the MUS_ prefix, to avoid
conflict with the same macros for setting properties on aura::Windows.

BUG=none
==========

[sadrul, 2015-11-19 19:24:43]

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

[sky, 2015-11-19 20:32:11]

https://codereview.chromium.org/1462123002/diff/40001/components/mus/ws/defau...
File components/mus/ws/default_access_policy.cc (right):

https://codereview.chromium.org/1462123002/diff/40001/components/mus/ws/defau...
components/mus/ws/default_access_policy.cc:41:
delegate_->IsRootForAccessPolicy(parent->id()) ||
Thsi policy, and remove, is too loose. In particular it would allow a client to
parent a window to a window they should not be able to access. What specific
case are you encountering?

[sadrul, 2015-11-19 20:43:59]

https://codereview.chromium.org/1462123002/diff/40001/components/mus/ws/defau...
File components/mus/ws/default_access_policy.cc (right):

https://codereview.chromium.org/1462123002/diff/40001/components/mus/ws/defau...
components/mus/ws/default_access_policy.cc:41:
delegate_->IsRootForAccessPolicy(parent->id()) ||
On 2015/11/19 20:32:10, sky wrote:
> Thsi policy, and remove, is too loose. In particular it would allow a client
to
> parent a window to a window they should not be able to access. What specific
> case are you encountering?

In the window_type_launcher demo, trying to open a transient window fails,
because it owns neither of the windows (both are created by the WM).

[sky, 2015-11-19 21:27:14]

https://codereview.chromium.org/1462123002/diff/40001/components/mus/ws/defau...
File components/mus/ws/default_access_policy.cc (right):

https://codereview.chromium.org/1462123002/diff/40001/components/mus/ws/defau...
components/mus/ws/default_access_policy.cc:41:
delegate_->IsRootForAccessPolicy(parent->id()) ||
On 2015/11/19 20:43:58, sadrul wrote:
> On 2015/11/19 20:32:10, sky wrote:
> > Thsi policy, and remove, is too loose. In particular it would allow a client
> to
> > parent a window to a window they should not be able to access. What specific
> > case are you encountering?
> 
> In the window_type_launcher demo, trying to open a transient window fails,
> because it owns neither of the windows (both are created by the WM).

That implies you're trying to use a window from one windowtree with a window
from another windowtree. I'm not sure the client lib deals with that very well
yet. I believe we will need this logic, but it hinges on associated pipes.
Without them we don't have a way to know if window should be visible to you. I
think you should hold off on this until we get associated pipes in place.

[sadrul, 2016-01-11 21:37:34]

https://codereview.chromium.org/1462123002/diff/80001/components/mus/public/c...
File components/mus/public/cpp/lib/window.cc (right):

https://codereview.chromium.org/1462123002/diff/80001/components/mus/public/c...
components/mus/public/cpp/lib/window.cc:782: return false;
There is probably a bug that the WS sends reorder notifications for roots? I am
looking into it.

[sadrul, 2016-01-12 21:50:48]

https://codereview.chromium.org/1462123002/diff/80001/components/mus/public/c...
File components/mus/public/cpp/lib/window.cc (right):

https://codereview.chromium.org/1462123002/diff/80001/components/mus/public/c...
components/mus/public/cpp/lib/window.cc:782: return false;
On 2016/01/11 21:37:34, sadrul wrote:
> There is probably a bug that the WS sends reorder notifications for roots? I
am
> looking into it.

Put up https://codereview.chromium.org/1580193002/ for this issue.

[sky, 2016-01-12 22:36:48]

On 2016/01/12 21:50:48, sadrul wrote:
>
https://codereview.chromium.org/1462123002/diff/80001/components/mus/public/c...
> File components/mus/public/cpp/lib/window.cc (right):
> 
>
https://codereview.chromium.org/1462123002/diff/80001/components/mus/public/c...
> components/mus/public/cpp/lib/window.cc:782: return false;
> On 2016/01/11 21:37:34, sadrul wrote:
> > There is probably a bug that the WS sends reorder notifications for roots? I
> am
> > looking into it.
> 
> Put up https://codereview.chromium.org/1580193002/ for this issue.

Is this ready for review then?

[sadrul, 2016-01-12 22:38:42]

On 2016/01/12 22:36:48, sky wrote:
> On 2016/01/12 21:50:48, sadrul wrote:
> >
>
https://codereview.chromium.org/1462123002/diff/80001/components/mus/public/c...
> > File components/mus/public/cpp/lib/window.cc (right):
> > 
> >
>
https://codereview.chromium.org/1462123002/diff/80001/components/mus/public/c...
> > components/mus/public/cpp/lib/window.cc:782: return false;
> > On 2016/01/11 21:37:34, sadrul wrote:
> > > There is probably a bug that the WS sends reorder notifications for roots?
I
> > am
> > > looking into it.
> > 
> > Put up https://codereview.chromium.org/1580193002/ for this issue.
> 
> Is this ready for review then?

Ignoring the change in window.cc: the rest is ready for review, yep.

[sky, 2016-01-12 22:43:40]

LGTM

[sadrul, 2016-01-13 08:20:40]

The CQ bit was checked by sadrul@chromium.org

[sadrul, 2016-01-13 08:20:40]

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

[commit-bot: I haz the power, 2016-01-13 08:20:48]

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

[commit-bot: I haz the power, 2016-01-13 08:56:20]

Description was changed from

==========
views/mus: Set-up transient windows correctly.

When a transient widget is created, make sure to set-up the transiency on mus
windows correctly as well.

Also, change policy in mus to allow adding/removing transient windows as long
as the client created either the parent or the child window.

Also, rename window-property defines in mus to have the MUS_ prefix, to avoid
conflict with the same macros for setting properties on aura::Windows.

BUG=none
==========

to

==========
views/mus: Set-up transient windows correctly.

When a transient widget is created, make sure to set-up the transiency on mus
windows correctly as well.

Also, change policy in mus to allow adding/removing transient windows as long
as the client created either the parent or the child window.

Also, rename window-property defines in mus to have the MUS_ prefix, to avoid
conflict with the same macros for setting properties on aura::Windows.

BUG=none
==========

[commit-bot: I haz the power, 2016-01-13 08:56:21]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2016-01-13 08:57:33]

Description was changed from

==========
views/mus: Set-up transient windows correctly.

When a transient widget is created, make sure to set-up the transiency on mus
windows correctly as well.

Also, change policy in mus to allow adding/removing transient windows as long
as the client created either the parent or the child window.

Also, rename window-property defines in mus to have the MUS_ prefix, to avoid
conflict with the same macros for setting properties on aura::Windows.

BUG=none
==========

to

==========
views/mus: Set-up transient windows correctly.

When a transient widget is created, make sure to set-up the transiency on mus
windows correctly as well.

Also, change policy in mus to allow adding/removing transient windows as long
as the client created either the parent or the child window.

Also, rename window-property defines in mus to have the MUS_ prefix, to avoid
conflict with the same macros for setting properties on aura::Windows.

BUG=none

Committed: https://crrev.com/1e5ea7a809355aecd0acc5817d40f0ffbeea1476
Cr-Commit-Position: refs/heads/master@{#369121}
==========

[commit-bot: I haz the power, 2016-01-13 08:57:34]

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