Bug 227691 – [GTK] Touchscreen navigation swipe doesn't work when the page scrolls horizontally

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alice Mikhaylenko]

This may sound like https://bugs.webkit.org/show_bug.cgi?id=226173 but it's ever so slightly different.

That bug happens with GTK4 only and the reason for it is different, so filing this one separately.

[Alice Mikhaylenko]

Created attachment 432917 [details]
Patch

Probably doesn't apply without https://bugs.webkit.org/show_bug.cgi?id=226745

[Alice Mikhaylenko]

Hm, there's a crash when tapping after a scroll.

[Alice Mikhaylenko]

It's the fact that we put the event back if WebCore hasn't handled them and then it gets processed again even though it shouldn't be.

Makes me wonder how or why it works for scroll events.

[Alice Mikhaylenko]

Created attachment 433023 [details]
Patch

Fixed. For now, just don't propagate touch events, there's no real point in doing that anyway.

[Alice Mikhaylenko]

Created attachment 433148 [details]
Patch

Oh wow, so the style script can determine if a name is redundant or not?

[EWS Watchlist]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See https://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

[Michael Catanzaro]

(In reply to Alexander Mikhaylenko from comment #5)
> Created attachment 433148 [details]
> Patch
> 
> Oh wow, so the style script can determine if a name is redundant or not?

Yeah that's a little weird, but the rule is to name the parameter only in the source file, and leave it unnamed in the header file to save a bit of space (if the name is going to be something obvious like e.g. "Point point").

[Alice Mikhaylenko]

Yeah, I know the rule, but didn't think the script could catch that.

[Michael Catanzaro]

Comment on attachment 433148 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=433148&action=review

> Source/WebKit/UIProcess/API/gtk/PageClientImpl.cpp:444
> +    // Wheel events can have either scroll events or touch events attached to them.
> +    // We only want to propagate scroll events; touch events are controlled via their
> +    // event sequences and if we're scrolling with touch events, that sequence is
> +    // already claimed and there's no point in propagating it.

Thanks for adding a comment to explain the weird behavior.

[EWS]

Committed r279779 (239546@main): <https://commits.webkit.org/239546@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 433148 [details].