Long Press Strategy should be configurable

[brian-superlist]

With recent changes, the new Long Press + Mangifier work breaks the Superlist app, and we cannot update to the latest version.

The superlist app does two things on long press:

1. Enable Drag n Drop, where a user can drag a document node around to reposition it.
2. Enable "Swipe to Open," where a user can swipe from right to left to navigate into task details.

With PR #1489, these interactions are broken. This PR introduced custom long-press functionality which cannot be overridden. The IosLongPressSelectionStrategy and AndroidDocumentLongPressSelectionStrategy. Neither of these can be configured from the consumer of super_editor, which means our drag n drop & swipe to open functionality no longer works correctly.

This functionality needs to be configurable so we can opt-in or opt-out of this behavior.

Demos

Broken Swipe to Open

RPReplay_Final1698151105.mp4

Broken Drag n Drop

RPReplay_Final1698151148.mp4

[miguelcmedeiros]

Cc @matthew-carroll @angelosilvestre

[matthew-carroll]

@brian-superlist @miguelcmedeiros Where do you guys try to add your own long press behavior? Is it per component? Is it in a SuperEditor ancestor? Something else?

[matthew-carroll]

@brian-superlist @miguelcmedeiros I think the critical question here is what it means to make long press configurable.

Long-press is carefully built into SuperEditor's gesture interactor, which also includes tap down, single tap, double tap, triple tap, drag, press and drag. If long-press can be "turned off", then I think one would expect that any of those interactions can be "turned off". So we face an issue of consistency here.

Technically, we probably can make all of those interactions configurable, but it raises the question as to how we want developers to control that. That's a lot of configuration options, and those options may need be duplicated per-platform.

Another approach might be to let developers supply their own gesture interactor, entirely. Then they can make it do whatever they want. But in that case, there's an awful lot of responsibility baked into those interactors. If a developer wants everything that's already there, minus long-press, then that's a huge amount of complex duplication for very little difference.

A third possible approach is to let developers provide some kind of override. It's unclear what form that would take. But I could imagine attempting to send touch events to a delegate, first, and if it's not responded, then the main interactor responds. However, this makes it very difficult to do the nuanced internal accounting. For example, tap down is the starting point for multiple possible interactions: long-press, long-press and drag, tap, double tap, triple tap, and pan. All of those interactions begin with the user pressing down. What would it mean for a developer to override tap down? Which gestures is SuperEditor still responsible for handling?

This analysis can keep going. The point is, the idea of making long-press configurable is a deep hole and we need to agree on what that should look like.

[brian-superlist]

Thanks, Matt. Completely agree, it's a complex problem and we should build the API carefully.

Where do you guys try to add your own long press behavior? Is it per component? Is it in a SuperEditor ancestor? Something else?

We add the interaction at the component level.

1. We use a Dimissible widget in our custom TaskComponent. When the user swipes from right to left, after they reach a certain point, we run a callback that navigates our app into the task details screen.
2. We also wrap that component with a SuperDraggableWidget. This widget allows a person to long-press on the widget to either start dragging or pull up the context menu on mobile, so it's quite a complex problem.

Perhaps I shouldn't describe any solution, but we'd like to maintain these interactions, since it allows our users to move tasks to different lists; rearrange tasks, images, and paragraphs, in the document; or navigate into a task with a quick gesture.

[brian-superlist]

@knopp Would be curious on your opinion here, since I know the drag & context menu interactions are quite complex as well.

[matthew-carroll]

Based on discussion about Superlist, we're going to introduce a half-measure to let Superlist disable long-press with a global property. We plan to remove this half-measure ASAP, but Superlist can't upgrade to the latest super_editor due to this long-press conflict.