aura-mus: Implement Deactivate().

aura-mus: Implement Deactivate() and fix Activation.

This adds a Deactivate() call for a window to request
deactivation in the window server, which passes that
request on to the window manager.

This also hooks up activation to focus changes caused
by the window server.

BUG=663618, 678070
Review-Url: https://codereview.chromium.org/2568303006
Cr-Commit-Position: refs/heads/master@{#443668}
Committed: https://chromium.googlesource.com/chromium/src/+/02ba4e291b70651fe0813d70d24bea60fd64cfea

[Elliot Glaysher, 2016-12-13 22:21:52]

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

[commit-bot: I haz the power, 2016-12-13 22:22:32]

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

[Elliot Glaysher, 2016-12-13 23:30:20]

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

[Elliot Glaysher, 2016-12-13 23:30:20]

Question: what do I need to do to test this? I've sent this through the trybots,
but since they were passing before with an unimplemented version of this, I
assume there aren't tests.

I looked at widget_unittest.cc and widget_interactive_uitest.cc but I couldn't
find anything that was enabled and looked like it was testing this. Several of
the Widget::Deactivation() tests that I could find are unconditionally
deactivated right now.

https://codereview.chromium.org/2568303006/diff/1/ui/aura/mus/window_tree_hos...
File ui/aura/mus/window_tree_host_mus.cc (right):

https://codereview.chromium.org/2568303006/diff/1/ui/aura/mus/window_tree_hos...
ui/aura/mus/window_tree_host_mus.cc:122: }
I don't like this emerging pattern. DesktopWindowTreeHostMus calls this method
through its base class which calls WindowTreeClient through a delegate
interface. Seems like a lot of forwarding for a simple thing.

[commit-bot: I haz the power, 2016-12-13 23:31:27]

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

[commit-bot: I haz the power, 2016-12-13 23:31:27]

Dry run: This issue passed the CQ dry run.

[sky, 2016-12-13 23:55:04]

I'm surprised you didn't need an explicit function on ui::mojom::WindowTree for
this. Widget::Deactivate() should end up calling
FocusController::DeactivateWindow() (in the window-manager, ash), does that end
up happening with your patch?

[Elliot Glaysher, 2016-12-14 21:27:58]

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

[commit-bot: I haz the power, 2016-12-14 21:28: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, 2016-12-14 21:31:09]

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

[commit-bot: I haz the power, 2016-12-14 21:31:10]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[Elliot Glaysher, 2016-12-14 22:28:10]

On 2016/12/13 23:55:04, sky wrote:
> I'm surprised you didn't need an explicit function on ui::mojom::WindowTree
for
> this.

Trying to figure out how to test this, I changed views examples to use aura
mus[1], and hacked one of the buttons to just Deactivate the widget of the
current
window. This appears to deactivate the window; both visually (the shadow goes
away) and with various printf debugging I temporarily added to the core (but
didn't upload).

[1]: I added this to the patch because it should happen anyway, but if you'd
like
to see it in its own patch I can separate it out.

> Widget::Deactivate() should end up calling
> FocusController::DeactivateWindow() (in the window-manager, ash), does that
end
> up happening with your patch?

AFAICT, there isn't a FocusController::DeactivateWindow() in
services/ui/. (There is a WindowManagerState::Deactivate() in ws/, but it does
something different where it hides windows and resets an event queue.) There
also isn't one in the ash/ directory.

Likewise, the class ws::FocusController (which is what is actually performing
the deactivation currently) doesn't have a DeactivateWindow() method; just a
SetFocusedWindow{,Impl}() method, which needs to complete synchronously under
the current architecture. Sure, that could change so that the internal focusing
details happen asynchronously, but that's requires a larger reworking of how
focus works in the window server (which appears to not currently deal with
focus at all, at least it I'm reading the window_manager.mojom interface
correctly).

[Elliot Glaysher, 2016-12-14 22:38:34]

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

[commit-bot: I haz the power, 2016-12-14 22:38:53]

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-12-14 23:48:55]

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

[commit-bot: I haz the power, 2016-12-14 23:48:56]

Dry run: This issue passed the CQ dry run.

[Elliot Glaysher, 2016-12-15 22:10:21]

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

[commit-bot: I haz the power, 2016-12-15 22:11:10]

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-12-15 22:33:52]

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

[commit-bot: I haz the power, 2016-12-15 22:33:52]

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

[Elliot Glaysher, 2016-12-15 22:47:21]

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

[commit-bot: I haz the power, 2016-12-15 22:48:16]

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-12-15 23:16:56]

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

[commit-bot: I haz the power, 2016-12-15 23:16:57]

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

[Elliot Glaysher, 2016-12-15 23:20:24]

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

[commit-bot: I haz the power, 2016-12-15 23:21:24]

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-12-15 23:52:37]

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

[commit-bot: I haz the power, 2016-12-15 23:52:37]

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

[Elliot Glaysher, 2016-12-16 00:04:58]

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

[commit-bot: I haz the power, 2016-12-16 00:06:06]

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-12-16 03:28:53]

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

[commit-bot: I haz the power, 2016-12-16 03:28:54]

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

[Elliot Glaysher, 2017-01-10 22:34:58]

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

[commit-bot: I haz the power, 2017-01-10 22:35:26]

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-01-10 23:29:49]

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

[commit-bot: I haz the power, 2017-01-10 23:29:50]

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

[Elliot Glaysher, 2017-01-11 20:31:37]

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

[commit-bot: I haz the power, 2017-01-11 20:32: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-01-11 20:50:02]

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

[commit-bot: I haz the power, 2017-01-11 20:50:03]

Dry run: Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Elliot Glaysher, 2017-01-11 22:17:02]

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

[commit-bot: I haz the power, 2017-01-11 22:18:31]

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-01-11 23:34:24]

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

[commit-bot: I haz the power, 2017-01-11 23:34:25]

Dry run: This issue passed the CQ dry run.

[Elliot Glaysher, 2017-01-11 23:38:25]

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

[commit-bot: I haz the power, 2017-01-11 23:39:32]

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

[Elliot Glaysher, 2017-01-11 23:49:25]

OK, I think this is ready to go.

The real problem in DesktopNativeWidgetAura wasn't that OnWindowActivated()
wasn't getting called; it was. The problem was that the Widget never got
notified when the activation changed. Contrast DesktopNativeWidgetAura with
NativeWidgetAura: NWA notifies Widget as the last thing it does.

I tried just indiscriminately notifying Widget like in NWA, but the problem is
this breaks the other DNWA users. So I put it behind a DesktopWindowTreeHost
delegate method.

[commit-bot: I haz the power, 2017-01-12 00:52:39]

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

[commit-bot: I haz the power, 2017-01-12 00:52:40]

Dry run: This issue passed the CQ dry run.

[sky, 2017-01-12 00:55:39]

https://codereview.chromium.org/2568303006/diff/200001/services/ui/public/cpp...
File services/ui/public/cpp/tests/test_window_tree.h (right):

https://codereview.chromium.org/2568303006/diff/200001/services/ui/public/cpp...
services/ui/public/cpp/tests/test_window_tree.h:105: void
DeactivateWindow(uint32_t current_window_id) override;
For consistency use window_id (most other functions use window_id).

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
File services/ui/ws/window_tree.cc (right):

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
services/ui/ws/window_tree.cc:1588: void WindowTree::DeactivateWindow(Id
requester_window_id) {
window_id

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
services/ui/ws/window_tree.cc:1596: WindowManagerDisplayRoot* display_root =
Make sure you null check display_root. null happens if the window isn't parented
to a display. See other functions that use WindowManagerDisplayRoot for the set
of null checks.

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
File services/ui/ws/window_tree.h (right):

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
services/ui/ws/window_tree.h:440: void DeactivateWindow(Id current_window_id)
override;
window_id.

https://codereview.chromium.org/2568303006/diff/200001/ui/aura/mus/window_tre...
File ui/aura/mus/window_tree_client.cc (right):

https://codereview.chromium.org/2568303006/diff/200001/ui/aura/mus/window_tre...
ui/aura/mus/window_tree_client.cc:1479:
window_manager_delegate_->OnWmDeactivateWindow(window->GetWindow());
It seems like this should early out if window isn't contained in the active
window. Is there a reason not to do that?

[Elliot Glaysher, 2017-01-12 19:15:41]

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

[commit-bot: I haz the power, 2017-01-12 19:16:20]

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-01-12 19:20:01]

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

[commit-bot: I haz the power, 2017-01-12 19:20:02]

Dry run: Try jobs failed on following builders:
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)

[Elliot Glaysher, 2017-01-12 20:18:49]

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

[commit-bot: I haz the power, 2017-01-12 20:19:32]

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-01-12 20:40:07]

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

[commit-bot: I haz the power, 2017-01-12 20:40:08]

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_...)
  linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Elliot Glaysher, 2017-01-12 20:43:54]

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

[commit-bot: I haz the power, 2017-01-12 20:44:59]

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

[Elliot Glaysher, 2017-01-12 21:55:40]

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

[commit-bot: I haz the power, 2017-01-12 21:56:30]

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-01-12 23:18:20]

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

[commit-bot: I haz the power, 2017-01-12 23:18:21]

Dry run: This issue passed the CQ dry run.

[Elliot Glaysher, 2017-01-12 23:20:37]

https://codereview.chromium.org/2568303006/diff/200001/services/ui/public/cpp...
File services/ui/public/cpp/tests/test_window_tree.h (right):

https://codereview.chromium.org/2568303006/diff/200001/services/ui/public/cpp...
services/ui/public/cpp/tests/test_window_tree.h:105: void
DeactivateWindow(uint32_t current_window_id) override;
On 2017/01/12 00:55:39, sky wrote:
> For consistency use window_id (most other functions use window_id).

Done.

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
File services/ui/ws/window_tree.cc (right):

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
services/ui/ws/window_tree.cc:1588: void WindowTree::DeactivateWindow(Id
requester_window_id) {
On 2017/01/12 00:55:39, sky wrote:
> window_id

Done.

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
services/ui/ws/window_tree.cc:1596: WindowManagerDisplayRoot* display_root =
On 2017/01/12 00:55:39, sky wrote:
> Make sure you null check display_root. null happens if the window isn't
parented
> to a display. See other functions that use WindowManagerDisplayRoot for the
set
> of null checks.

Done.

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
File services/ui/ws/window_tree.h (right):

https://codereview.chromium.org/2568303006/diff/200001/services/ui/ws/window_...
services/ui/ws/window_tree.h:440: void DeactivateWindow(Id current_window_id)
override;
On 2017/01/12 00:55:39, sky wrote:
> window_id.

Done.

https://codereview.chromium.org/2568303006/diff/200001/ui/aura/mus/window_tre...
File ui/aura/mus/window_tree_client.cc (right):

https://codereview.chromium.org/2568303006/diff/200001/ui/aura/mus/window_tre...
ui/aura/mus/window_tree_client.cc:1479:
window_manager_delegate_->OnWmDeactivateWindow(window->GetWindow());
On 2017/01/12 00:55:39, sky wrote:
> It seems like this should early out if window isn't contained in the active
> window. Is there a reason not to do that?

Hoisted the early out check from inside OnWmDeactivateWindow() to this method by
exposing an IsWindowActive() check.

https://codereview.chromium.org/2568303006/diff/280001/ui/views/mus/desktop_w...
File ui/views/mus/desktop_window_tree_host_mus.cc (right):

https://codereview.chromium.org/2568303006/diff/280001/ui/views/mus/desktop_w...
ui/views/mus/desktop_window_tree_host_mus.cc:682: is_active_ = active;
I have readded this. We discussed setting |is_active_| in
DesktopWindowTreeHostMus::OnNativeWidgetActivationChanged() instead of in a
WidgetObserver method. However, this breaks focus, whether I set |is_active_|
before or after the call to Widget::OnNativeWidgetActivationChanged(). Moving
setting |is_active_|  back here fixes everything.

I'm fairly confused as to why this is required and (theoretically) they should
be equivalent. They obviously aren't though. The only thing that I can think of
is that there are places in the activation code path which rely on the old
widget not to report being active before some signal, and to report the opposite
afterwards.

[sky, 2017-01-13 00:01:19]

LGTM

https://codereview.chromium.org/2568303006/diff/280001/ui/views/mus/desktop_w...
File ui/views/mus/desktop_window_tree_host_mus.cc (right):

https://codereview.chromium.org/2568303006/diff/280001/ui/views/mus/desktop_w...
ui/views/mus/desktop_window_tree_host_mus.cc:682: is_active_ = active;
On 2017/01/12 23:20:37, Elliot Glaysher wrote:
> I have readded this. We discussed setting |is_active_| in
> DesktopWindowTreeHostMus::OnNativeWidgetActivationChanged() instead of in a
> WidgetObserver method. However, this breaks focus, whether I set |is_active_|
> before or after the call to Widget::OnNativeWidgetActivationChanged(). Moving
> setting |is_active_|  back here fixes everything.
> 
> I'm fairly confused as to why this is required and (theoretically) they should
> be equivalent. They obviously aren't though. The only thing that I can think
of
> is that there are places in the activation code path which rely on the old
> widget not to report being active before some signal, and to report the
opposite
> afterwards.

Can you add a TODO to track down why? It would be good to know.

[Elliot Glaysher, 2017-01-13 18:54:35]

Description was changed from

==========
aura-mus: Implement Deactivate().

BUG=663618
==========

to

==========
aura-mus: Implement Deactivate() and fix Activation.

This adds a Deactivate() call for a window to request
deactivation in the window server, which passes that
request on to the window manager.

This also hooks up activation to focus changes caused
by the window server.

BUG=663618,678070
==========

[Elliot Glaysher, 2017-01-13 18:54:48]

The CQ bit was checked by erg@chromium.org

[Elliot Glaysher, 2017-01-13 18:54:48]

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/2568303006/#ps300001
(title: "Add comment.")

[commit-bot: I haz the power, 2017-01-13 18:55:39]

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-01-13 21:13:52]

CQ is committing da patch.

Bot data: {"patchset_id": 300001, "attempt_start_ts": 1484333688061200,
"parent_rev": "2cca07af9074a721023db37901881af2b3eb9f9e", "commit_rev":
"02ba4e291b70651fe0813d70d24bea60fd64cfea"}

[commit-bot: I haz the power, 2017-01-13 21:14:37]

Description was changed from

==========
aura-mus: Implement Deactivate() and fix Activation.

This adds a Deactivate() call for a window to request
deactivation in the window server, which passes that
request on to the window manager.

This also hooks up activation to focus changes caused
by the window server.

BUG=663618,678070
==========

to

==========
aura-mus: Implement Deactivate() and fix Activation.

This adds a Deactivate() call for a window to request
deactivation in the window server, which passes that
request on to the window manager.

This also hooks up activation to focus changes caused
by the window server.

BUG=663618,678070

Review-Url: https://codereview.chromium.org/2568303006
Cr-Commit-Position: refs/heads/master@{#443668}
Committed:
https://chromium.googlesource.com/chromium/src/+/02ba4e291b70651fe0813d70d24b...
==========

[commit-bot: I haz the power, 2017-01-13 21:14:41]

Committed patchset #16 (id:300001) as
https://chromium.googlesource.com/chromium/src/+/02ba4e291b70651fe0813d70d24b...

[Wez, 2017-02-07 19:51:23]

wez@chromium.org changed reviewers:
+ wfh@chromium.org

[Wez, 2017-02-07 19:51:25]

Hallo wfh@chromium.org!
Due to a depot_tools patch which mistakenly removed the OWNERS check for
non-source files (see crbug.com/684270), the following files landed in this CL
and need a retrospective review from you:
	services/ui/public/interfaces/window_manager.mojom
	services/ui/public/interfaces/window_tree.mojom
Thanks,
Wez

[Will Harris, 2017-02-07 23:24:21]

Description was changed from

==========
aura-mus: Implement Deactivate() and fix Activation.

This adds a Deactivate() call for a window to request
deactivation in the window server, which passes that
request on to the window manager.

This also hooks up activation to focus changes caused
by the window server.

BUG=663618,678070

Review-Url: https://codereview.chromium.org/2568303006
Cr-Commit-Position: refs/heads/master@{#443668}
Committed:
https://chromium.googlesource.com/chromium/src/+/02ba4e291b70651fe0813d70d24b...
==========

to

==========
aura-mus: Implement Deactivate() and fix Activation.

This adds a Deactivate() call for a window to request
deactivation in the window server, which passes that
request on to the window manager.

This also hooks up activation to focus changes caused
by the window server.

BUG=663618,678070

Review-Url: https://codereview.chromium.org/2568303006
Cr-Commit-Position: refs/heads/master@{#443668}
Committed:
https://chromium.googlesource.com/chromium/src/+/02ba4e291b70651fe0813d70d24b...
==========

[Will Harris, 2017-02-07 23:25:28]

hi - can you clarify what process calls this new DeactivateWindow IPC and from
which context, and does the call cross security boundaries (e.g. from untrusted
process to trusted process)?

[Elliot Glaysher, 2017-02-07 23:31:37]

On 2017/02/07 23:25:28, Will Harris wrote:
> hi - can you clarify what process calls this new DeactivateWindow IPC and from
> which context, and does the call cross security boundaries (e.g. from
untrusted
> process to trusted process)?

DeactivateWindow is called from an untrusted client process and is implemented
in the trusted window server.

The WmDeactivateWindow is a call from the window_server to the window manager,
so trusted to trusted.

[Will Harris, 2017-02-07 23:47:35]

On 2017/02/07 23:31:37, Elliot Glaysher wrote:
> On 2017/02/07 23:25:28, Will Harris wrote:
> > hi - can you clarify what process calls this new DeactivateWindow IPC and
from
> > which context, and does the call cross security boundaries (e.g. from
> untrusted
> > process to trusted process)?
> 
> DeactivateWindow is called from an untrusted client process and is implemented
> in the trusted window server.
> 
> The WmDeactivateWindow is a call from the window_server to the window manager,
> so trusted to trusted.

okay thanks, retroactive lgtm