1443710 - Support touchscreen swiping for back/forward navigation

Status: NEW

(Firefox :: General, enhancement)

Description

[Mike Conley (:mconley) (:⚙️)]

Note that this is distinct from scrollpad swiping - this is specific to touchscreens.

There are a number of mailing list and forum posts asking about this. Here are a few:

https://groups.google.com/forum/#!topic/mozilla.support.firefox/fiRgxY13Fok
https://www.reddit.com/r/firefox/comments/4b4z7w/what_plugin_will_let_me_swipe_back_on_a/
http://forums.mozillazine.org/viewtopic.php?f=38&t=3034770

It doesn't look like we support this, or at least we don't out of the box. Touchscreens aren't going anywhere it seems, so it might be worth considering adding this (since it appears to be quite common in other applications, and in other browsers).

Comment 1

[Botond Ballo [:botond]]

We recently implemented the touchpad version of this for Windows in bug 1348786, and I came across this bug which is making me wonder if we should consider prioritizing this as an extension of that existing work.

From a technical point of view, I expect the implementation can reuse some of the infrastructure from touchpad swipe-to-nav (i.e. parts of SwipeTracker), but we would also need to add some new parts to teach it about a different category of events (touch events rather than pan-gesture events) and possibly work through issues specific to touch events that may come up.

Martin, I'm curious: from a product point of view, how important do you think this feature is, in comparison to touchpad swipe-to-navigate, and in general?

Comment 2

[Martin Balfanz [:mbalfanz]]

Thanks for flagging this, Botond!

This is a great feature to work on, and would make our touch/swipe support much more complete. I also had a quick look at our data, and a lot of users seem to have touch enabled devices. If you have cycles to pick this up, I'd say go for it! But I don't know what it's competing with (in terms of time) to assess the relative priority.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

It may be possible that just calling SendAnAPZEvent here makes the feature happen.

Comment 4

[Botond Ballo [:botond]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

It may be possible that just calling SendAnAPZEvent here makes the feature happen.

That codepath is only taken for touchpads that produce touch events; we turn the touch events into pan gesture events (otherwise a two-finger touchpad scroll would be gesture-detected as PinchGestureInput which can only scroll the root).

Comment 5

[Jürg Lempen]

(In reply to Botond Ballo [:botond] from comment #1)

Martin, I'm curious: from a product point of view, how important do you think this feature is, in comparison to touchpad swipe-to-navigate, and in general?

Hi all,
Considering that every Chromium-based browser supports touchscreen swiping navigation on Windows and even on Linux/Wayland, and considering that many modern laptops such as the hugely popular convertible/2-in-1 Microsoft Surface or Lenovo Yoga devices feature multi-touch touchscreens, I believe that this feature should be very high on the priority list.
In my book, the lack of touchscreen navigation is a major showstopper for every owner of a touchscreen device. As far as I am concerned, and as much as I like Firefox, I decided to switch to one of the Chromium-based browsers on all my devices due to the lack of touchscreen swipe navigation, and I'm probably not the only one in this situation.
If you decided to pick up work on this feature, I'd gladly help out with testing and debugging, even if I'm not a developer myself.
Cheers,
Jürg

Comment 6

[Botond Ballo [:botond]]

We discussed two possible implementation strategies for this, given that for touchscreens, the events we get are raw touch points (as opposed to touchpads where we get higher-level gesture information from the OS), and therefore we need to detect the swipe gesture ourselves:

1. Reuse APZ's gesture detection logic, and send synthesized PanGestureInput events for swipe gestures to the SwipeTracker.
2. Send the raw touch events to the SwipeTracker and have it perform its own gesture detection.

The first approach would allow us to reuse more existing code, but it would also mean a different event flow than for touchpad swipe-to-nav (since the SwipeTracker lives in the parent process and APZ in the compositor process). It's unclear at this point which approach is preferable.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

I am trying to understand how APZ's gesture detection (GestureEventListener) works, now I am leaning to the second approach. Two reasons;

1. SwipeTracker is supposed to work with/without APZ
2. SwipeTracker needs to tell APZ whether the initial pan gesture event (i.e. pan-start event) can be used for swipe-to-nav or not, i.e. in the pan-start event case APZ needs to handle first, whereas GestureEventListener can handle the event first, in other words for swipe-to-nav the initial event flow is OS -> Widget -> APZC -> SwipeTracker, for GestureEventListener it's OS -> Widget -> GestureEventListener -> APZC, that's another difference in terms of event flows.

Comment 8

[ryanwest6]

I'd like this as well, another reason to stay on Chrome when using touch-friendly Surface Pro devices.