Linux: Fake a mouse move event when the render view gains focus and the mouse...

Linux: Fake a mouse move event when the render view gains focus and the mouse is over it.

On windows, when the render view regains focus it receives a mouse move event with the coordinates of the pointer. We don't on linux, so we have to fake this. Without this, webkit doesn't know where the pointer is, so can have a wrong cursor or other graphical glitches.

TEST=bug is fixed
BUG=12879
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=17693

[Evan Stade, 2009-05-29 03:58:24]

At first I figured this was the wrong approach, but I debugged on windows and
found that they were getting mouse move events even with the mouse didn't move.
That is, if you right click on a link, then move the mouse over the render view,
then hit escape, then just after the escape keypress the render view gets a
mouse move.

iGoogle eyes testing shows that, with the above sequence of events:
Windows:
-IE + chrome get a mouse move event after the context menu is canceled
Linux:
-firefox gets mouse move events the whole time the context menu is showing
-epiphany gets no mouse move event at all

With this patch we'll match windows ie + chrome. I doubt users will notice/care
when the mouse move events are getting sent as long as it's not ridiculous.

[Evan Martin, 2009-05-29 16:38:49]

+dean, arbiter of purity

http://codereview.chromium.org/113987/diff/1/2
File chrome/browser/renderer_host/render_widget_host_view_gtk.cc (right):

http://codereview.chromium.org/113987/diff/1/2#newcode134
Line 134: host_view->GetRenderWidgetHost()->ForwardMouseEvent(
Maybe it'd be better to construct a WebMouseEvent directly?  That includes all
needed fields by definition.

See webkit/api/public/WebInputEvent.h .

[tony, 2009-05-29 17:35:45]

In win chrome, where does the mouse move event after esc is pressed come from? 
I don't see a WM_MOUSEMOVE event in winspector, so are they making a fake event
too?

[Evan Stade, 2009-05-29 18:06:58]

I'm not too sure. The callstack is the same as the mouse events you get just
from waving the mouse around:

Function: RenderWidgetHostViewWin::OnMouseEvent(unsigned int, unsigned int,
long, int &), Thread: 0x1B88 Chromium_BrowserMain
	chrome.dll!RenderWidgetHostViewWin::OnMouseEvent() 
	chrome.dll!RenderWidgetHostViewWin::ProcessWindowMessage() 
	chrome.dll!ATL::CWindowImplBaseT<ATL::CWindow,ATL::CWinTraits<1174405120,0>
>::WindowProc() 
	user32.dll!7e418734() 
	[Frames below may be incorrect and/or missing, no symbols loaded for
user32.dll]
	user32.dll!7e418816() 
	user32.dll!7e42a013() 
	user32.dll!7e42a039() 
	chrome.dll!views::FocusWindowCallback() 
	user32.dll!7e418734() 
	user32.dll!7e418816() 
	chrome.dll!std::_Iterator_base::~_Iterator_base() 
	user32.dll!7e4189cd() 
	user32.dll!7e418a10() 
	chrome.dll!views::AcceleratorHandler::Dispatch() 
	chrome.dll!base::MessagePumpForUI::ProcessMessageHelper()

[Evan Stade, 2009-05-29 18:09:40]

http://codereview.chromium.org/113987/diff/1/2
File chrome/browser/renderer_host/render_widget_host_view_gtk.cc (right):

http://codereview.chromium.org/113987/diff/1/2#newcode134
Line 134: host_view->GetRenderWidgetHost()->ForwardMouseEvent(
On 2009/05/29 16:38:49, Evan Martin wrote:
> Maybe it'd be better to construct a WebMouseEvent directly?  That includes all
> needed fields by definition.
> 
> See webkit/api/public/WebInputEvent.h .
> 

Yea, that file's how I decided which fields to fill out. I wanted to use that
function in case they change it somehow some day, but it's pretty much a
straight copy, so I guess it's somewhat pointless to take this approach.

[Evan Stade, 2009-06-01 07:44:09]

I noticed a similar issue on windows chrome (in the beta channel at least--I
don't have anything newer to test with at the moment). When you use the mouse
wheel, the mouse cursor/position does not update (try hovering over a link that
changes colors on hover, then wheel scroll).

This may justify creating a new ViewMsg called "MouseIsHere" or whatever,
basically the same as a mouse move event but doesn't irritate the hack detection
nerve as much. Or maybe wheel events are just not doing everything they're
supposed to, and the fix is separate.

[Evan Stade, 2009-06-01 18:03:38]

ping

(I found https://bugs.webkit.org/show_bug.cgi?id=17052 which covers the scroll
wheel thing)

[Evan Martin, 2009-06-01 18:06:46]

This still feels like a hack to me.  Would you mind starting a thread on
chromium-dev about it?  Sorry to hang up your fix... :\

[Evan Stade, 2009-06-04 18:06:59]

well that thread was a bit of a flop

[Evan Martin, 2009-06-04 18:10:30]

On 2009/06/04 18:06:59, Evan Stade wrote:
> well that thread was a bit of a flop

I think it's because Darin is on vacation.  :(

[tony, 2009-06-04 18:29:30]

I think it's ok to fake the event for now, but we should probably add a TODO and
file a bug about the hack?  Seems better to have a hacky fix than to not have
the fix at all.

[Evan Martin, 2009-06-04 18:30:36]

Tony is right.  LGTM, but please file a bug