Keep the mouse cursor within desktop

* Keep the mouse in the desktop in multi monitor environment. I ended up using XFIXES to make launcher autohide  works smoothlyl.
* Made dtor of ML::Dispatcher publiic and Eliminated aura::Dispatcher
* Refactored DispatcherLinux so that it re-dispatch event per window.
* Removed ConfineToWindow in RHWVA::LockMouse because a) it's not necessary on device (mouse is always confined to root window), b) it should
confine to the RWHVA's window but not root window, so this is not exactly right.  I'll work on this in separate CL after m19.

BUG=115510
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=128739

[oshima, 2012-03-23 16:24:20]

derat -> xfixes (root_window_host_linux), dispatcher linux refactoring. 
ben -> everything.
willchan -> /base
varunjain -> RWHVA change.

[oshima, 2012-03-23 16:27:56]

On 2012/03/23 16:24:20, oshima wrote:
> derat -> xfixes (root_window_host_linux), dispatcher linux refactoring. 
> ben -> everything.
> willchan -> /base
willchan, I'm not sure who is right owner to review linux change (used to be
evan, but...),
so I'm sending to you. Let me know if I should send this to another owner.

[Daniel Erat, 2012-03-23 16:49:16]

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
File ui/aura/root_window_host_linux.cc (right):

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:373: if (pointer_barriers_.get()) {
It looks like you only update if we already had barriers enabled before.  How
does this get enabled in the first place?  Does ConfineCursorToRootWindow() get
called from somewhere else?

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:584: if (pointer_barriers_.get())
DCHECK(!pointer_barriers_.get()) instead?

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:587: // the bottom.
Can the monitors be different widths?  If so, it seems like you might need
barriers on the left and right as well.

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:591: 0, 0, bounds_.width(), 0,  // barrier
line
Should you be using bounds_.x() and bounds_.y() here?  Or is the monitor that
we're using always guaranteed to be on top?  If it is, why do you need this
barrier?

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:603: void
RootWindowHostLinux::UnConfineCursor() {
Should probably call this from the d'tor too.

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
File ui/aura/root_window_host_linux.h (right):

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.h:15: #include "base/memory/scoped_ptr.h"
nit: fix alphabetization

[varunjain, 2012-03-23 16:56:01]

RWHVA lgtm

http://codereview.chromium.org/9808010/diff/7018/content/browser/renderer_hos...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

http://codereview.chromium.org/9808010/diff/7018/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:623: //
TODO(oshima): Support Window::ConfineCursorToWindow.
Please also make sure that we are ok with mouse lock not working on non-chromeos
aura

[oshima, 2012-03-23 18:25:09]

http://codereview.chromium.org/9808010/diff/7018/content/browser/renderer_hos...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

http://codereview.chromium.org/9808010/diff/7018/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:623: //
TODO(oshima): Support Window::ConfineCursorToWindow.
On 2012/03/23 16:56:01, varunjain wrote:
> Please also make sure that we are ok with mouse lock not working on
non-chromeos
> aura

will do.

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
File ui/aura/root_window_host_linux.cc (right):

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:373: if (pointer_barriers_.get()) {
On 2012/03/23 16:49:16, Daniel Erat wrote:
> It looks like you only update if we already had barriers enabled before.  How
> does this get enabled in the first place?  Does ConfineCursorToRootWindow()
get
> called from somewhere else?

This is enabled for root window for primary monitor in 
MonitorManager::CreateRootWindowForPrimaryMonitor

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:584: if (pointer_barriers_.get())
On 2012/03/23 16:49:16, Daniel Erat wrote:
> DCHECK(!pointer_barriers_.get()) instead?

I added it. I kept "if" because this isn't critical enough to crash. let me know
if you disagree.

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:587: // the bottom.
On 2012/03/23 16:49:16, Daniel Erat wrote:
> Can the monitors be different widths?  If so, it seems like you might need
> barriers on the left and right as well.

There are already barriers on sides.

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:591: 0, 0, bounds_.width(), 0,  // barrier
line
On 2012/03/23 16:49:16, Daniel Erat wrote:
> Should you be using bounds_.x() and bounds_.y() here?  Or is the monitor that
> we're using always guaranteed to be on top?  If it is, why do you need this
> barrier?

I'm creating barriers relative to xwindow_, so this is correct.

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.cc:603: void
RootWindowHostLinux::UnConfineCursor() {
On 2012/03/23 16:49:16, Daniel Erat wrote:
> Should probably call this from the d'tor too.

Good point. Done.

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
File ui/aura/root_window_host_linux.h (right):

http://codereview.chromium.org/9808010/diff/7018/ui/aura/root_window_host_lin...
ui/aura/root_window_host_linux.h:15: #include "base/memory/scoped_ptr.h"
On 2012/03/23 16:49:16, Daniel Erat wrote:
> nit: fix alphabetization

Done.

[Daniel Erat, 2012-03-23 18:31:11]

LGTM for X if Ben's happy with the dispatcher changes.

[Ben Goodger (Google), 2012-03-23 19:40:02]

So... ash shouldn't know anything about X11. Why did you need to move the
monitor observer out of aura?

[oshima, 2012-03-23 19:56:06]

On 2012/03/23 19:40:02, Ben Goodger (Google) wrote:
> So... ash shouldn't know anything about X11. Why did you need to move the
> monitor observer out of aura?

I thought this makes sense only when ash manages multi monitors, but on second
thought, I was probably wrong because this also makes send for linux_aura. I'll
move it back.

[Ben Goodger (Google), 2012-03-23 20:02:48]

Thanks let me know when to look again.

-Ben

On Fri, Mar 23, 2012 at 12:56 PM, <oshima@chromium.org> wrote:

> On 2012/03/23 19:40:02, Ben Goodger (Google) wrote:
>
>> So... ash shouldn't know anything about X11. Why did you need to move the
>> monitor observer out of aura?
>>
>
> I thought this makes sense only when ash manages multi monitors, but on
> second
> thought, I was probably wrong because this also makes send for linux_aura.
> I'll
> move it back.
>
>
http://codereview.chromium.**org/9808010/<http://codereview.chromium.org/9808...
>

[oshima, 2012-03-23 20:46:13]

uploaded new patch. PTAL.

[Ben Goodger (Google), 2012-03-23 21:58:09]

lgtm

[oshima, 2012-03-23 22:44:41]

brett, can you review /base?

[brettw, 2012-03-23 23:14:54]

base LGTM

[commit-bot: I haz the power, 2012-03-24 10:32:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/oshima@chromium.org/9808010/7058

[commit-bot: I haz the power, 2012-03-24 14:16:53]

Change committed as 128739

[oshima, 2012-03-24 18:19:39]

http://codereview.chromium.org/9808010/diff/7058/ui/aura/env.cc
File ui/aura/env.cc (right):

http://codereview.chromium.org/9808010/diff/7058/ui/aura/env.cc#newcode37
ui/aura/env.cc:37: instance_->Init();
Ben, I had to move init code out of constructor to avoid infinite loop. Let me
know if you have concern or comment. I'll address them in separate CL.