Bug 226681 – [GTK] Long press context menu only appears after releasing the finger

• Status: RESOLVED
• Resolution: INVALID
• Component: WebKitGTK

[Alice Mikhaylenko]

Haven't bisected, but probably a fallout from https://bugs.webkit.org/show_bug.cgi?id=212324, same as https://bugs.webkit.org/show_bug.cgi?id=226680 and https://bugs.webkit.org/show_bug.cgi?id=226679

[Carlos Garnacho]

This is not a bug from my perspective. This was made to unbreak the pointer-emulation mode that allows text selection and was broken by other additional layers of input handling.

Like with GtkScrolledWindow/GtkTextView, long press now disables scroll mode and enables pointer alike interaction with the content, i.e. text selection and drags. Only if the long press turned out to be stationary after releasing it does know that neither scroll nor text selection happened, thus the context menu can be shown, it can't be had both ways.

TBH, I consider the context menu here nothing more than a temporal workaround. Even though it's a shortcut that's been popularized by apps, GTK has stayed away from reusing pointer-oriented UI on its own widgets, and from "long press to popup something" in general, I think WebKitGTK should follow that.

I consider the touch-friendly special UI to be an integral part of text handles support, I do intend to work on that feature altogether at some point.

[Alice Mikhaylenko]

Well, as is it breaks existing behavior. Everything that uses long press in GTK, and on both iOS and ANdroid has the timeout as a trigger, not release.

[Carlos Garnacho]

> (In reply to Alexander Mikhaylenko from comment #2)
> Well, as is it breaks existing behavior.

Well, seems we both have the same point :p.

> Everything that uses long press in
> GTK, and on both iOS and ANdroid has the timeout as a trigger, not release.

As said, "long press for menu" is something the GTK toolkit actively moved away from. Some GTK apps do that, but they don't define the platform. GtkGestureLongPress has no logical action associated, it can be used both to trigger and inhibit a certain state.

Since we're stuck with the context menu here, if we want to address this as a regression and not regress again on text selection, I think we would need to make the long press 2-leveled, so a shorter wait turns off scroll mode (allowing text selection), and a longer wait brings the context menu. When text selection is initiated the context menu action would be cancelled. That is roughly what would happen in GTK across 2 widgets with GtkScrolledWindow and a child widget trying to use GtkGestureLongPress to bring a context menu.

[Alice Mikhaylenko]

2-level long press should be fine, indeed.

And I don't think it's possible to get rid of the menu here completely, it's used for many more things than text selection: opening links in new tab, saving, copying link address, etc. Similarly, both iOS and Android still have menus for these actions even though both provide popovers for text selection similarly to the GTK one.

Also GTK still has a long press in color picker dialog, in the file chooser sidebar, in the emoji picker etc.

[Carlos Garnacho]

(In reply to Alexander Mikhaylenko from comment #4)
> 2-level long press should be fine, indeed.
> 
> And I don't think it's possible to get rid of the menu here completely, it's
> used for many more things than text selection: opening links in new tab,
> saving, copying link address, etc. Similarly, both iOS and Android still
> have menus for these actions even though both provide popovers for text
> selection similarly to the GTK one.

Maybe, and it's probably wise to involve the design team at that point, all I'm clear about is that it shouldn't be a GtkMenu, and that the remaining contextual actions don't seem to justify it popping up everywhere.

> 
> Also GTK still has a long press in color picker dialog, in the file chooser
> sidebar, in the emoji picker etc.

You are pointing out pickers (i.e. self-contained complex UIs) and a widget that was a straight port from an application. Also, these use popovers, that are significantly friendlier to touch interaction (and can/do contain UI optimized for it, as opposed to GtkMenu).

OTOH, none of the widgets that you can embed in your UI does this by default (with the exception of GtkPlacesSidebar). If GTK wanted to show pointer-oriented menus and call it a day, it would have hardcoded a long-press gesture to GtkWidget::popup-menu long ago.

[Alice Mikhaylenko]

To be clear, the bug is not about whether it's a menu or a popover, but about when it appears.

[Alice Mikhaylenko]

Ok, so somehow I didn't realize it broke text selection even though you mentioned it multiple times. Not sure what I was thinking, but absolutely fair enough. Closing.