Fixes 105886

Added code to propagate clicks to parents of the target as well.

Tested using html5 drag demo and bookmark dragging to make sure that the patch didn't break dragging

BUG = 105886
Test = Manual


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

[pkotwicz, 2011-12-02 22:39:25]

This fixes the issue. I am not sure what dragging you mean in the code comment
though, so please comment =]

[pkotwicz, 2011-12-02 22:39:37]

This fixes the issue. I am not sure what dragging you mean in the code comment
though, so please comment =]

[Ben Goodger (Google), 2011-12-06 04:31:59]

Why is this needed? We don't do anything like this in views.

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

http://codereview.chromium.org/8788002/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:511: return false;
Was something broken by this returning true?

This interferes with Windows event handling.

[pkotwicz, 2011-12-06 15:18:26]

This is to fix the problem with the status bubble not moving out of the way when
the mouse is over it (Bug 105886). As the code currently stands the mouse motion
event was never propagated to the native_tab_contents_view_aura because the
event is consumed by the render_widget_host_view_aura.cc.

An other option would be to make native_tab_contents_view_aura
PreHandleMouseEvents

[Ben Goodger (Google), 2011-12-06 17:06:56]

On Tue, Dec 6, 2011 at 7:18 AM, <pkotwicz@chromium.org> wrote:

> This is to fix the problem with the status bubble not moving out of the
> way when
> the mouse is over it (Bug 105886). As the code currently stands the mouse
> motion
> event was never propagated to the native_tab_contents_view_aura because the
> event is consumed by the render_widget_host_view_aura.**cc.
>
> An other option would be to make native_tab_contents_view_aura
> PreHandleMouseEvents
>
>
>
>
http://codereview.chromium.**org/8788002/<http://codereview.chromium.org/8788...
>

[Ben Goodger (Google), 2011-12-06 17:07:17]

Oops, didn't mean to send.

How is this implemented on Windows?

-Ben

On Tue, Dec 6, 2011 at 9:06 AM, Ben Goodger (Google) <ben@chromium.org>wrote:

>
>
> On Tue, Dec 6, 2011 at 7:18 AM, <pkotwicz@chromium.org> wrote:
>
>> This is to fix the problem with the status bubble not moving out of the
>> way when
>> the mouse is over it (Bug 105886). As the code currently stands the mouse
>> motion
>> event was never propagated to the native_tab_contents_view_aura because
>> the
>> event is consumed by the render_widget_host_view_aura.**cc.
>>
>> An other option would be to make native_tab_contents_view_aura
>> PreHandleMouseEvents
>>
>>
>>
>>
http://codereview.chromium.**org/8788002/<http://codereview.chromium.org/8788...
>>
>
>

[pkotwicz, 2011-12-06 18:12:14]

In render_widget_host_view_win we return false unless
native_tab_contents_view_win processes the mouse event. In
render_widget_host_view_win we always return false on a mouse move.

In both the windows and the gtk case the mouse event is passed to the parent via
the window manager if the widget is not top level.

[pkotwicz, 2011-12-06 18:12:35]

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

http://codereview.chromium.org/8788002/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:511: return false;
Which event handling in particular does it interfere with?

[Ben Goodger (Google), 2011-12-08 18:00:05]

The desktop harness expects this to return a specific value that determines how
windows then post-processes the event.

Anyway, how is this implemented on windows and why does this have to be
different?

[Ben Goodger (Google), 2011-12-08 18:00:15]

How is this feature implemented I mean

[Ben Goodger (Google), 2011-12-08 19:10:26]

http://codereview.chromium.org/8788002/diff/2001/ui/aura/desktop.cc
File ui/aura/desktop.cc (right):

http://codereview.chromium.org/8788002/diff/2001/ui/aura/desktop.cc#newcode472
ui/aura/desktop.cc:472: for (Window* window = target; !handled && window; window
= window->parent()) {
So, after discovering how this feature is implemented on windows, my objection
now becomes that you're doing this here on Desktop, rather than just
reconstructing the same hack in RWHVA that RWHVW has. :-)

[pkotwicz, 2011-12-10 23:15:26]

Hacked it the same way its done on Windows. Using an aura::EventFilter would
feel a bit less like a hack but would less consistent across OSes.

[Ben Goodger (Google), 2011-12-11 21:49:40]

LGTM

[commit-bot: I haz the power, 2011-12-12 22:47:14]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/pkotwicz@chromium.org/8788002/14001

[commit-bot: I haz the power, 2011-12-12 23:48:46]

Change committed as 114117