[Webkit-unassigned] [Bug 181996] [GTK] Page crash after swipe gesture running GNOME3 under wayland

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jan 23 17:47:20 PST 2018


https://bugs.webkit.org/show_bug.cgi?id=181996

--- Comment #5 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Oh wow, thanks! You might want to review https://webkit.org/contributing-code/ before attaching your patch. Key steps are (a) run the prepare-ChangeLog script, and (b) set the r? and cq? flags on the Bugzilla attachment.

I notice that in webkitWebViewBaseTouchEvent() (in WebKitWebViewBase.cpp) also needs fixed. There a NativeWebTouchEvent is created from the received GdkEventTouch* regardless of its GdkEventType. But that is illegal unless the GdkEventType is GDK_TOUCH_BEGIN, GDK_TOUCH_UPDATE, or GDK_TOUCH_END, according to the switch case you already found in createWebTouchEvent(). So webkitWebViewBaseTouchEvent() needs to be updated as well, to not create a new NativeWebTouchEvent in this case. So in the default case, webkitWebViewBaseTouchEvent() ought to return FALSE instead of continuing on. That way, if some new GdkEventType for GdkEventTouch* were to be added in the future (not likely for GTK+ 3, but it could happen in future major versions) WebKit will at least not crash like this.

Now, according to the GTK+ documentation, the only other valid GdkEventType for a GdkEventTouch* is GDK_TOUCH_CANCEL, so fortunately you're right that that's the only additional GdkEventType we need to support. I'm going to blindly guess that should be handled exactly the same as GDK_TOUCH_END in webkitWebViewBaseTouchEvent...? So that switch case in webkitWebViewBaseTouchEvent() should *probably* just fall through:

    case GDK_TOUCH_END:
    case GDK_TOUCH_CANCEL:
        ASSERT(priv->touchEvents.contains(sequence));
        priv->touchEvents.remove(sequence);
        break;

At least, that *seems* like it would be the right thing to do....

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180124/9b0550f9/attachment.html>


More information about the webkit-unassigned mailing list