Block keyboard and mouse input when maximize mode is activated by accelerometer.

Block keyboard and mouse input when maximize mode is activated by accelerometer.

BUG=353409
TEST=MaximizeModeControllerTest.BlocksKeyboardAndMouse

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=263481

[flackr, 2014-04-09 13:55:09]

Hi,

This is a simple approach to blocking keyboard and touchpad events when we enter
maximize mode.

Eventually I'd like to use the id of the xinput device but as far as i can tell
this isn't passed down as it doesn't seem to be part of the XKeyEvent structure.
Probably the best solution would be to disable and re-enable the internal
keyboard / touchpad devices (i.e. similar to xinput disable #), but I wanted to
try to start simple especially if we might want to merge to M35.

What do you think?

[sadrul, 2014-04-09 16:54:18]

https://codereview.chromium.org/230613004/diff/1/ash/wm/maximize_mode/maximiz...
File ash/wm/maximize_mode/maximize_mode_controller.cc (right):

https://codereview.chromium.org/230613004/diff/1/ash/wm/maximize_mode/maximiz...
ash/wm/maximize_mode/maximize_mode_controller.cc:92:
Shell::GetInstance()->PrependPreTargetHandler(this);
Can you install a WindowTargeter on the root-window that returns NULL for
key/mouse events, instead of event-handlers?

[flackr, 2014-04-09 17:11:49]

https://codereview.chromium.org/230613004/diff/1/ash/wm/maximize_mode/maximiz...
File ash/wm/maximize_mode/maximize_mode_controller.cc (right):

https://codereview.chromium.org/230613004/diff/1/ash/wm/maximize_mode/maximiz...
ash/wm/maximize_mode/maximize_mode_controller.cc:92:
Shell::GetInstance()->PrependPreTargetHandler(this);
On 2014/04/09 16:54:18, sadrul wrote:
> Can you install a WindowTargeter on the root-window that returns NULL for
> key/mouse events, instead of event-handlers?

It looks like event targeters are per window / root window, which means it'll
have to install on each root window and track new root window creation. Is there
a global event targeter?

Wouldn't this also mean that if something else set an event targeter afterwards
we could accept events again?

[sadrul, 2014-04-09 17:33:30]

https://codereview.chromium.org/230613004/diff/1/ash/wm/maximize_mode/maximiz...
File ash/wm/maximize_mode/maximize_mode_controller.cc (right):

https://codereview.chromium.org/230613004/diff/1/ash/wm/maximize_mode/maximiz...
ash/wm/maximize_mode/maximize_mode_controller.cc:92:
Shell::GetInstance()->PrependPreTargetHandler(this);
On 2014/04/09 17:11:49, flackr wrote:
> On 2014/04/09 16:54:18, sadrul wrote:
> > Can you install a WindowTargeter on the root-window that returns NULL for
> > key/mouse events, instead of event-handlers?
> 
> It looks like event targeters are per window / root window, which means it'll
> have to install on each root window and track new root window creation. Is
there
> a global event targeter?

There isn't a global event targeter. If a new root-window is added, you would
have to install a targeter on that.

> 
> Wouldn't this also mean that if something else set an event targeter
afterwards
> we could accept events again?

Yes. But so does for event-handlers: there can be some other pre-handler that is
pre-pended and does things with key/mouse events. Between an event-handler and
event-targeter, the latter is the more correct way of doing this.

[oshima, 2014-04-09 23:02:58]

i'll wait until sadrul's comment is resolved.

[flackr, 2014-04-10 02:30:02]

https://codereview.chromium.org/230613004/diff/1/ash/wm/maximize_mode/maximiz...
File ash/wm/maximize_mode/maximize_mode_controller.cc (right):

https://codereview.chromium.org/230613004/diff/1/ash/wm/maximize_mode/maximiz...
ash/wm/maximize_mode/maximize_mode_controller.cc:92:
Shell::GetInstance()->PrependPreTargetHandler(this);
On 2014/04/09 17:33:30, sadrul wrote:
> On 2014/04/09 17:11:49, flackr wrote:
> > On 2014/04/09 16:54:18, sadrul wrote:
> > > Can you install a WindowTargeter on the root-window that returns NULL for
> > > key/mouse events, instead of event-handlers?
> > 
> > It looks like event targeters are per window / root window, which means
it'll
> > have to install on each root window and track new root window creation. Is
> there
> > a global event targeter?
> 
> There isn't a global event targeter. If a new root-window is added, you would
> have to install a targeter on that.

Just wanted to be sure I wasn't just missing something, thanks.
> 
> > 
> > Wouldn't this also mean that if something else set an event targeter
> afterwards
> > we could accept events again?
> 
> Yes. But so does for event-handlers: there can be some other pre-handler that
is
> pre-pended and does things with key/mouse events. Between an event-handler and
> event-targeter, the latter is the more correct way of doing this.

No problem, done. I refactored two other classes which had OnRootWindowAdded
being manually called on them to use ShellObserver to be notified of this event.
Done.

[sadrul, 2014-04-10 16:23:43]

ui/aura/ and MaximizeModeEventBlocker lgtm. Thanks!

[oshima, 2014-04-10 20:52:57]

lgtm

https://codereview.chromium.org/230613004/diff/40001/ash/wm/maximize_mode/max...
File ash/wm/maximize_mode/maximize_mode_controller_unittest.cc (right):

https://codereview.chromium.org/230613004/diff/40001/ash/wm/maximize_mode/max...
ash/wm/maximize_mode/maximize_mode_controller_unittest.cc:35: size_t
event_count() { return event_count_; }
const

[flackr, 2014-04-10 21:24:55]

https://codereview.chromium.org/230613004/diff/40001/ash/wm/maximize_mode/max...
File ash/wm/maximize_mode/maximize_mode_controller_unittest.cc (right):

https://codereview.chromium.org/230613004/diff/40001/ash/wm/maximize_mode/max...
ash/wm/maximize_mode/maximize_mode_controller_unittest.cc:35: size_t
event_count() { return event_count_; }
On 2014/04/10 20:52:57, oshima wrote:
> const 

Done.

[flackr, 2014-04-10 21:25:01]

The CQ bit was checked by flackr@chromium.org

[commit-bot: I haz the power, 2014-04-10 21:26:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/flackr@chromium.org/230613004/50001

[ghost stip (do not use), 2014-04-11 21:30:27]

The CQ bit was unchecked by stip@chromium.org

[ghost stip (do not use), 2014-04-11 21:30:28]

The CQ bit was checked by stip@chromium.org

[commit-bot: I haz the power, 2014-04-11 23:48:42]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/flackr@chromium.org/230613004/50001

[commit-bot: I haz the power, 2014-04-11 23:48:51]

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

[commit-bot: I haz the power, 2014-04-11 23:48:52]

Failed to apply patch for ash/root_window_controller.cc:
While running patch -p1 --forward --force --no-backup-if-mismatch;
  patching file ash/root_window_controller.cc
  Hunk #1 FAILED at 703.
  1 out of 1 hunk FAILED -- saving rejects to file
ash/root_window_controller.cc.rej

Patch:       ash/root_window_controller.cc
Index: ash/root_window_controller.cc
diff --git a/ash/root_window_controller.cc b/ash/root_window_controller.cc
index
d4878b647d1b9b3ae510e46c37c4e000c09a87e0..4d2dd8da22d3650dbff86f93c6425e60f5f10f3d
100644
--- a/ash/root_window_controller.cc
+++ b/ash/root_window_controller.cc
@@ -703,13 +703,14 @@ void RootWindowController::Init(RootWindowType
root_window_type,
       shell->InitKeyboard();
   } else {
     root_window_layout()->OnWindowResized();
-    shell->desktop_background_controller()->OnRootWindowAdded(root_window());
-    shell->high_contrast_controller()->OnRootWindowAdded(root_window());
     host_->Show();
 
     // Create a shelf if a user is already logged in.
     if (shell->session_state_delegate()->NumberOfLoggedInUsers())
       shelf()->CreateShelf();
+
+    // Notify shell observers about new root window.
+    shell->OnRootWindowAdded(root_window());
   }
 }

[flackr, 2014-04-12 00:23:09]

The CQ bit was checked by flackr@chromium.org

[commit-bot: I haz the power, 2014-04-12 00:25:35]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/flackr@chromium.org/230613004/70001

[commit-bot: I haz the power, 2014-04-12 05:18:31]

Change committed as 263481