Relanding the EventTarget fixes for Aura (Ash) as the previous attempt was reverted due to interact…

Relanding the EventTarget fixes for Aura (Ash) as the previous attempt was reverted due to interactive test failures
on the linux_chromeos builder. 

Disabled the failing BookmarkBarViewTest8.DNDBackToOriginatingMenu test on AURA for now and logged a bug
http://code.google.com/p/chromium/issues/detail?id=158564&thanks=158564 to track this. Will work on that in a subsequent
change.

Register a separate default ui::EventTarget for Aura (Ash) to ensure that it does not interfere with the
event handling in desktop chrome in Aura. 

On Windows 8 in chrome metro mode we have a desktop chrome process
which runs as a server to the viewer process in Metro. Reusing the default EventTarget across both environments
causes desktop chrome to crash as a number of EventFilters registered on the default EventTarget get called twice.

The Ash specific EventTarget is implemented by the Ash::Shell class. The RootWindow in its GetParentTarget implementation
delegates this call to the EventClient implementation if one exists and if not it returns the default Aura::Env interface.

The EventClient interface is implemented by Ash and has been updated to return the default EventTarget via the new method
GetToplevelEventTarget

Fixes bug http://code.google.com/p/chromium/issues/detail?id=158105

BUG=158105
R=ben
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=165026

[Ben Goodger (Google), 2012-10-30 02:10:24]

https://codereview.chromium.org/11273098/diff/11010/ash/shell.cc
File ash/shell.cc (right):

https://codereview.chromium.org/11273098/diff/11010/ash/shell.cc#newcode736
ash/shell.cc:736: aura::client::SetEventClient(root, event_client_.get());
this should probably be done in rootwindowcontroller. that way you'll catch all
of them.

[Ben Goodger (Google), 2012-10-30 02:25:38]

It looks like code in chrome/test/base/view_event_test_base.cc is hurting you.
That code explicitly sets EventClient to NULL on the root window, unhooking your
code.

I added that code a while back, I think after I discovered the ash interactive
tests run with a locked screen. Rather than having them not run with a locked
screen I guess I just hacked around it in that way. Seems like we should just
have them run unlocked and rmeove this line.

[ananta, 2012-10-30 17:52:06]

On 2012/10/30 02:25:38, Ben Goodger (Google) wrote:
> It looks like code in chrome/test/base/view_event_test_base.cc is hurting you.
> That code explicitly sets EventClient to NULL on the root window, unhooking
your
> code.
> 
> I added that code a while back, I think after I discovered the ash interactive
> tests run with a locked screen. Rather than having them not run with a locked
> screen I guess I just hacked around it in that way. Seems like we should just
> have them run unlocked and rmeove this line.

I will look into getting the interactive ui tests on chrome os to run without a
locked screen and will remove the view_event_test_base.cc hack in a subsequent
change. I disabled the failing BookmarkBarViewTest8.DNDBackToOriginatingMenu
test on AURA for now.
Logged a bug to track this.
http://code.google.com/p/chromium/issues/detail?id=158564&thanks=158564

[Ben Goodger (Google), 2012-10-30 22:02:17]

lgtm