Bug 120648 – [GTK] mouse wheel events are not considered to be mouse events

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Grant Gayed]

When a mouse wheel event is received, various WebKitGTK API that is used to get info from the event, such as webkit_dom_mouse_event_get_screen_?() and webkit_dom_mouse_event_get_button(), fail with an error spew like:

** CRITICAL **: glong webkit_dom_mouse_event_get_screen_y(WebKitDOMMouseEvent*): assertion `WEBKIT_DOM_IS_MOUSE_EVENT(self)' failed

** CRITICAL **: gushort webkit_dom_mouse_event_get_button(WebKitDOMMouseEvent*): assertion `WEBKIT_DOM_IS_MOUSE_EVENT(self)' failed

I think MouseWheel events should be considered to be mouse events (?).

[Carlos Garcia Campos]

We don't expose WheelEvent in the DOM bindings, but WheelEvent derives from MouseEvent so it should be considered a mouse event in any case. Could you share more code to try to reproduce the issue?

[Carlos Garcia Campos]

bool WheelEvent::isMouseEvent() const
{
    return false;
}

[Carlos Garcia Campos]

(In reply to comment #2)
> bool WheelEvent::isMouseEvent() const
> {
>     return false;
> }

ok, this is used internally to handle clicks and moves, that's why this returns false. We should check if the event interface type is WheelEventInterfaceType to create a mouse event, but I guess it would be better to expose WheelEvent in our bindings, no?

[Carlos Garcia Campos]

Created attachment 213682 [details]
Patch

Expose WheelEvent in GObject DOM bindings, that way we make sure the generated object is a WheelEvent and therefore a MouseEvent

[Gustavo Noronha (kov)]

Comment on attachment 213682 [details]
Patch

Makes sense to me, I guess we should get a rubber-stamp from someone else just in case, but we have been known to not use the 2 reviews rule for the DOM bindings heh

[Carlos Garcia Campos]

Committed r157163: <http://trac.webkit.org/changeset/157163>