Introduce window container to be used by lock screen app windows

Introduce window container to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.
Lock screen app windows are currently restricted only to maximized
bounds.

To implement this behavior, this CL introduces a new container that
adjusts its children visibility state according to lock screen new
note action state:
 * children can be active only when the action is in active state
 * children can be visible only when the action is in active or
   background state
 * in background state, children are stacked below the lock screen
   window
 * in active state, children are stacked above lock screen window

BUG=716081
Review-Url: https://codereview.chromium.org/2876993002
Cr-Commit-Position: refs/heads/master@{#475042}
Committed: https://chromium.googlesource.com/chromium/src/+/98adf00652d29143b41b6ec77b31e74025f10e93

[tbarzic, 2017-05-12 01:06:33]

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

[commit-bot: I haz the power, 2017-05-12 01:07:33]

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, 2017-05-12 04:02:27]

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

[commit-bot: I haz the power, 2017-05-12 04:02:28]

Dry run: This issue passed the CQ dry run.

[tbarzic, 2017-05-14 00:45:09]

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

[commit-bot: I haz the power, 2017-05-14 00:45:22]

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, 2017-05-14 02:49:52]

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

[commit-bot: I haz the power, 2017-05-14 02:49:53]

Dry run: This issue passed the CQ dry run.

[tbarzic, 2017-05-14 07:09:37]

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

[commit-bot: I haz the power, 2017-05-14 07:09:43]

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, 2017-05-14 08:04:46]

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

[commit-bot: I haz the power, 2017-05-14 08:04:47]

Dry run: This issue passed the CQ dry run.

[tbarzic, 2017-05-14 16:19:05]

Description was changed from

==========
Introduce window containers to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.

To implement this behavior, this CL introduces 2 new containers
 * lock action handler container - a container visible only when
       a tray action is being handled - i.e. new note action is in
       active state
 * lock action handler background container - a container visible only
       when a tray action handler has been moved to background -i.e.
       new note action is in background state

Only one of these window containers will be visible at a time.
On tray action state changes, any windows that are in the wrong
container wil lbe moved to the other one.

For example,
 * if the new note state changes from active -> background, all windows in
   foreground container will be reparented to the background container.
 * if the new note state changes from background -> active, all windows in
   background container will be reparented to foreground container.

Window behavior in these containers is similar to behavior of windows in
lock container - only allowed state is maximized, but their bounds get
restricted to the current user work space area.

BUG=716081
==========

to

==========
Introduce window containers to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.

To implement this behavior, this CL introduces 2 new containers
 * lock action handler container - a container visible only when
       a tray action is being handled - i.e. new note action is in
       active state
 * lock action handler background container - a container visible only
       when a tray action handler has been moved to background -i.e.
       new note action is in background state

Only one of these window containers will be visible at a time.
On tray action state changes, any windows that are in the wrong
container will be moved to the other one.

For example,
 * if the new note state changes from active -> background, all windows in
   foreground container will be reparented to the background container.
 * if the new note state changes from background -> active, all windows in
   background container will be reparented to foreground container.

Similar to lock screen container - window states in these containers will
be restricted to maximized, minimized and fullscreen (normal, non maximizable
windows are centred on the screen). The difference to the lock screen container 
is that the shelf is taken into account when calculating work are for the
container.

BUG=716081
==========

[tbarzic, 2017-05-14 17:54:33]

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

[commit-bot: I haz the power, 2017-05-14 17:54:40]

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, 2017-05-14 19:52:30]

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

[commit-bot: I haz the power, 2017-05-14 19:52:31]

Dry run: This issue passed the CQ dry run.

[tbarzic, 2017-05-15 17:40:22]

tbarzic@chromium.org changed reviewers:
+ oshima@chromium.org

[tbarzic, 2017-05-15 17:40:22]

Can you please take a look?

[tbarzic, 2017-05-15 23:14:33]

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

[commit-bot: I haz the power, 2017-05-15 23:15:32]

Dry run: CQ is trying da patch.

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

[oshima, 2017-05-17 18:16:00]

one question. Why do you want to reparent, instead of changing visibility?
Reparenting has many side effects so I'd recommend not to do unless it's
necessary.

https://codereview.chromium.org/2876993002/diff/140001/ash/wm/lock_action_han...
File ash/wm/lock_action_handler_layout_manager.cc (right):

https://codereview.chromium.org/2876993002/diff/140001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager.cc:21: namespace {}  // namespace
?

[tbarzic, 2017-05-17 18:28:43]

On 2017/05/17 18:16:00, oshima wrote:
> one question. Why do you want to reparent, instead of changing visibility?
> Reparenting has many side effects so I'd recommend not to do unless it's
> necessary.
> 
>
https://codereview.chromium.org/2876993002/diff/140001/ash/wm/lock_action_han...
> File ash/wm/lock_action_handler_layout_manager.cc (right):
> 
>
https://codereview.chromium.org/2876993002/diff/140001/ash/wm/lock_action_han...
> ash/wm/lock_action_handler_layout_manager.cc:21: namespace {}  // namespace
> ?

Main reason to reparent is that the UX wants the app window displayed behind the
lock screen when the user switches to user pod UI (which is in the lock screen
container), so just hiding the app window would not work for that case.
Basically, we'd have to change the window stacking based on the user action:
- when the action (new_note) handler window is active - the window should be
stacked above the lock screen
- when the user tries to unlock the screen - the window should be stacked below
the lock screen
(https://gallery.googleplex.com/projects/MCHbtQVoQ2HCZeuVjVNz6jvj/files/MCEioo...)

I'm open to suggestions if you have a better solution for this :)

[oshima, 2017-05-17 23:26:03]

> Only one of these window containers will be visible at a time.

I've got impression that you don't need two containers.
Just move the container instead each windows, and alter visibility?

[tbarzic, 2017-05-17 23:37:10]

Description was changed from

==========
Introduce window containers to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.

To implement this behavior, this CL introduces 2 new containers
 * lock action handler container - a container visible only when
       a tray action is being handled - i.e. new note action is in
       active state
 * lock action handler background container - a container visible only
       when a tray action handler has been moved to background -i.e.
       new note action is in background state

Only one of these window containers will be visible at a time.
On tray action state changes, any windows that are in the wrong
container will be moved to the other one.

For example,
 * if the new note state changes from active -> background, all windows in
   foreground container will be reparented to the background container.
 * if the new note state changes from background -> active, all windows in
   background container will be reparented to foreground container.

Similar to lock screen container - window states in these containers will
be restricted to maximized, minimized and fullscreen (normal, non maximizable
windows are centred on the screen). The difference to the lock screen container 
is that the shelf is taken into account when calculating work are for the
container.

BUG=716081
==========

to

==========
Introduce window containers to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.

To implement this behavior, this CL introduces 2 new containers
 * lock action handler container - a container visible only when
       a tray action is being handled - i.e. new note action is in
       active state
 * lock action handler background container - a container visible only
       when a tray action handler has been moved to background -i.e.
       new note action is in background state

Only windows in one of these window containers will be visible at
a time. On tray action state changes, any windows that are in the wrong
container will be moved to the other one.

For example,
 * if the new note state changes from active -> background, all windows in
   foreground container will be reparented to the background container.
 * if the new note state changes from background -> active, all windows in
   background container will be reparented to foreground container.

Similar to lock screen container - window states in these containers will
be restricted to maximized, minimized and fullscreen (normal, non maximizable
windows are centred on the screen). The difference to the lock screen container 
is that the shelf is taken into account when calculating work are for the
container.

BUG=716081
==========

[tbarzic, 2017-05-18 00:45:02]

On 2017/05/17 23:26:03, oshima wrote:
> > Only one of these window containers will be visible at a time.
> 
> I've got impression that you don't need two containers.
> Just move the container instead each windows, and alter visibility?

Can you elaborate a little?
Do you mean something like moving the whole container between e.g.
LockScreenWallpaperContainer container and LockScreenContainersContainer?

[oshima, 2017-05-18 01:09:08]

On 2017/05/18 00:45:02, tbarzic wrote:
> On 2017/05/17 23:26:03, oshima wrote:
> > > Only one of these window containers will be visible at a time.
> > 
> > I've got impression that you don't need two containers.
> > Just move the container instead each windows, and alter visibility?
> 
> Can you elaborate a little?
> Do you mean something like moving the whole container between e.g.
> LockScreenWallpaperContainer container and LockScreenContainersContainer?


It sounded like you always move all windows back and forth and in that case
you can just restack the container.

Maybe I'm missing something. Do you have a UI mock with transition?

[tbarzic, 2017-05-18 01:33:31]

On 2017/05/18 01:09:08, oshima wrote:
> On 2017/05/18 00:45:02, tbarzic wrote:
> > On 2017/05/17 23:26:03, oshima wrote:
> > > > Only one of these window containers will be visible at a time.
> > > 
> > > I've got impression that you don't need two containers.
> > > Just move the container instead each windows, and alter visibility?
> > 
> > Can you elaborate a little?
> > Do you mean something like moving the whole container between e.g.
> > LockScreenWallpaperContainer container and LockScreenContainersContainer?
> 
> 
> It sounded like you always move all windows back and forth and in that case
> you can just restack the container.
> 
> Maybe I'm missing something. Do you have a UI mock with transition?

Oh, OK.. I was a little confused by "move".
Yeah, it's basically moving windows back an forth.
Let me try with restacking the container above/below the lock screen container.

[tbarzic, 2017-05-18 03:14:28]

btw. one advantage of using two containers is it's easier to ensure the app
windows in the background are not activatable  (so they cannot steal focus from
the lock screen) - we can just not include the background container in the
activatable containers list

[tbarzic, 2017-05-18 19:50:35]

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

[tbarzic, 2017-05-18 19:51:13]

Description was changed from

==========
Introduce window containers to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.

To implement this behavior, this CL introduces 2 new containers
 * lock action handler container - a container visible only when
       a tray action is being handled - i.e. new note action is in
       active state
 * lock action handler background container - a container visible only
       when a tray action handler has been moved to background -i.e.
       new note action is in background state

Only windows in one of these window containers will be visible at
a time. On tray action state changes, any windows that are in the wrong
container will be moved to the other one.

For example,
 * if the new note state changes from active -> background, all windows in
   foreground container will be reparented to the background container.
 * if the new note state changes from background -> active, all windows in
   background container will be reparented to foreground container.

Similar to lock screen container - window states in these containers will
be restricted to maximized, minimized and fullscreen (normal, non maximizable
windows are centred on the screen). The difference to the lock screen container 
is that the shelf is taken into account when calculating work are for the
container.

BUG=716081
==========

to

==========
Introduce window container to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.
Lock screen app windows are currently restricted only to maximized
bounds.

To implement this behavior, this CL introduces a new container that
adjusts its children visibility state according to lock screen new
note action state:
 * children can be active only when the action is in active state
 * children can be visible only when the action is in active or
   background state
 * in background state, children are stacked below the lock screen
   window
 * in active state, children are stacked above lock screen window

BUG=716081
==========

[commit-bot: I haz the power, 2017-05-18 19:51:52]

Dry run: CQ is trying da patch.

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

[tbarzic, 2017-05-18 19:54:58]

Updated the approach to use a single window container.

Please, take another look.

https://codereview.chromium.org/2876993002/diff/140001/ash/wm/lock_action_han...
File ash/wm/lock_action_handler_layout_manager.cc (right):

https://codereview.chromium.org/2876993002/diff/140001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager.cc:21: namespace {}  // namespace
On 2017/05/17 18:15:59, oshima wrote:
> ?

oops, had a constant that I remove here.

[commit-bot: I haz the power, 2017-05-19 00:29:22]

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

[commit-bot: I haz the power, 2017-05-19 00:29:23]

Dry run: This issue passed the CQ dry run.

[tbarzic, 2017-05-25 03:37:12]

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

[commit-bot: I haz the power, 2017-05-25 03:37:51]

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, 2017-05-25 05:15:11]

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

[commit-bot: I haz the power, 2017-05-25 05:15:12]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[oshima, 2017-05-25 19:50:00]

https://codereview.chromium.org/2876993002/diff/220001/ash/screen_util.cc
File ash/screen_util.cc (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/screen_util.cc#new...
ash/screen_util.cc:52: return GetDisplayBoundsInParent(window);
nit: looks like shelf shouldn't be null? If so, please remove the condition.

https://codereview.chromium.org/2876993002/diff/220001/ash/tray_action/tray_a...
File ash/tray_action/tray_action.h (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/tray_action/tray_a...
ash/tray_action/tray_action.h:40: mojom::TrayActionState
GetLockScreenNoteState() const;
thanks

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
File ash/wm/lock_action_handler_layout_manager.cc (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager.cc:54:
AdjustWindowsForWorkAreaChange(&event);
Why this is necessary?

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
File ash/wm/lock_action_handler_layout_manager_unittest.cc (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager_unittest.cc:33: namespace test {
test namespace is for test utilities, so please just put then in the ash.

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager_unittest.cc:37: const int
kVirtualKeyboardHeight = 100;
constexpr

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager_unittest.cc:124: return
std::unique_ptr<aura::Window>(widget->GetNativeView());
nit: base::WrapUnique

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager_unittest.cc:137: if
(keyboard->ui()->GetKeyboardWindow()->bounds().height() == 0) {
is this condition necessary?

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_window_sta...
File ash/wm/lock_window_state.h (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_window_sta...
ash/wm/lock_window_state.h:66: bool shelf_visible_ = false;
exclude_shelf_ ? (I believe the shelf is *visible* even when this is false)

[tbarzic, 2017-05-25 20:32:21]

https://codereview.chromium.org/2876993002/diff/220001/ash/screen_util.cc
File ash/screen_util.cc (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/screen_util.cc#new...
ash/screen_util.cc:52: return GetDisplayBoundsInParent(window);
On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> nit: looks like shelf shouldn't be null? If so, please remove the condition.

yeah, it seems so.
Done.

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
File ash/wm/lock_action_handler_layout_manager.cc (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager.cc:54:
AdjustWindowsForWorkAreaChange(&event);
On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> Why this is necessary?

To adjust window bounds when the work area bounds change - e.g. when ChromeVox
panel is shown while user session is locked - this would update user work area
to exclude the panel window (kShellWindowId_SettingBubbleContainer); the goal of
this is to pick up on that change.

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
File ash/wm/lock_action_handler_layout_manager_unittest.cc (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager_unittest.cc:33: namespace test {
On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> test namespace is for test utilities, so please just put then in the ash.

Done.

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager_unittest.cc:37: const int
kVirtualKeyboardHeight = 100;
On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> constexpr

Done.

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager_unittest.cc:124: return
std::unique_ptr<aura::Window>(widget->GetNativeView());
On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> nit: base::WrapUnique

Done.

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager_unittest.cc:137: if
(keyboard->ui()->GetKeyboardWindow()->bounds().height() == 0) {
On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> is this condition necessary?

it's not really.

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_window_sta...
File ash/wm/lock_window_state.h (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_window_sta...
ash/wm/lock_window_state.h:66: bool shelf_visible_ = false;
On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> exclude_shelf_ ? (I believe the shelf is *visible* even when this is false)

Done.

[tbarzic, 2017-05-25 20:32:34]

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

[commit-bot: I haz the power, 2017-05-25 20:33:34]

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, 2017-05-25 22:22:27]

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

[commit-bot: I haz the power, 2017-05-25 22:22:28]

Dry run: This issue passed the CQ dry run.

[oshima, 2017-05-25 23:46:20]

lgtm

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
File ash/wm/lock_action_handler_layout_manager.cc (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager.cc:54:
AdjustWindowsForWorkAreaChange(&event);
On 2017/05/25 20:32:20, tbarzic wrote:
> On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> > Why this is necessary?
> 
> To adjust window bounds when the work area bounds change - e.g. when ChromeVox
> panel is shown while user session is locked - this would update user work area
> to exclude the panel window (kShellWindowId_SettingBubbleContainer); the goal
of
> this is to pick up on that change.

I assume you meant when GetDisplayWorkAreaBoundsInParentForLockScreen changes?

can you add comment that this has to be done differently due to the way workarea
is computed for lock screen?

[tbarzic, 2017-05-26 00:49:33]

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
File ash/wm/lock_action_handler_layout_manager.cc (right):

https://codereview.chromium.org/2876993002/diff/220001/ash/wm/lock_action_han...
ash/wm/lock_action_handler_layout_manager.cc:54:
AdjustWindowsForWorkAreaChange(&event);
On 2017/05/25 23:46:20, oshima wrote:
> On 2017/05/25 20:32:20, tbarzic wrote:
> > On 2017/05/25 19:49:59, oshima (OOO May 22-24) wrote:
> > > Why this is necessary?
> > 
> > To adjust window bounds when the work area bounds change - e.g. when
ChromeVox
> > panel is shown while user session is locked - this would update user work
area
> > to exclude the panel window (kShellWindowId_SettingBubbleContainer); the
goal
> of
> > this is to pick up on that change.
> 
> I assume you meant when GetDisplayWorkAreaBoundsInParentForLockScreen changes?
> 
> can you add comment that this has to be done differently due to the way
workarea
> is computed for lock screen?
> 

Done.

[tbarzic, 2017-05-26 01:24:09]

The CQ bit was checked by tbarzic@chromium.org

[tbarzic, 2017-05-26 01:24:10]

The patchset sent to the CQ was uploaded after l-g-t-m from oshima@chromium.org
Link to the patchset: https://codereview.chromium.org/2876993002/#ps280001
(title: ".")

[commit-bot: I haz the power, 2017-05-26 01:25:14]

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, 2017-05-26 05:43:23]

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

[commit-bot: I haz the power, 2017-05-26 05:43:24]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[tbarzic, 2017-05-26 05:58:44]

The CQ bit was checked by tbarzic@chromium.org

[tbarzic, 2017-05-26 05:58:52]

The CQ bit was unchecked by tbarzic@chromium.org

[tbarzic, 2017-05-26 16:21:46]

The CQ bit was checked by tbarzic@chromium.org

[commit-bot: I haz the power, 2017-05-26 16:22:12]

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, 2017-05-26 17:28:23]

CQ is committing da patch.

Bot data: {"patchset_id": 280001, "attempt_start_ts": 1495815706738550,
"parent_rev": "ce00cf81df6d6949fb64023c486f23792ca131e8", "commit_rev":
"98adf00652d29143b41b6ec77b31e74025f10e93"}

[commit-bot: I haz the power, 2017-05-26 17:28:37]

Description was changed from

==========
Introduce window container to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.
Lock screen app windows are currently restricted only to maximized
bounds.

To implement this behavior, this CL introduces a new container that
adjusts its children visibility state according to lock screen new
note action state:
 * children can be active only when the action is in active state
 * children can be visible only when the action is in active or
   background state
 * in background state, children are stacked below the lock screen
   window
 * in active state, children are stacked above lock screen window

BUG=716081
==========

to

==========
Introduce window container to be used by lock screen app windows

An app will be able to show a window on lock screen only if it
was registered as a handler for "new_note" tray action, and a
user performed an action that causes the action to be handled.

Lock screen app windows can have two visible states:
 * active - when the window is displayed over the user pods on lock
       screen UI.
 * background - when the window is displayed in background, under the
       user pods in lock screen UI.

In both states, the lock screen UI system shelf should remain visible.
Lock screen app windows are currently restricted only to maximized
bounds.

To implement this behavior, this CL introduces a new container that
adjusts its children visibility state according to lock screen new
note action state:
 * children can be active only when the action is in active state
 * children can be visible only when the action is in active or
   background state
 * in background state, children are stacked below the lock screen
   window
 * in active state, children are stacked above lock screen window

BUG=716081

Review-Url: https://codereview.chromium.org/2876993002
Cr-Commit-Position: refs/heads/master@{#475042}
Committed:
https://chromium.googlesource.com/chromium/src/+/98adf00652d29143b41b6ec77b31...
==========

[commit-bot: I haz the power, 2017-05-26 17:28:40]

Committed patchset #15 (id:280001) as
https://chromium.googlesource.com/chromium/src/+/98adf00652d29143b41b6ec77b31...