I wanted to add on to this. This is an issue affecting multi-touch touchpad users as well. Between the initiation of a scroll event, and the moment the user releases the scroll, we need to consider this a "scroll start event". When this event happens, we need to store the horizontal scroll value of the active element. IE, check if the user is hovering over a horizontal list that an be scrolled, and store the value of the scrollbar. Or, if the user is zoomed in with pinch to zoom or something, store whether it can be scrolled left or right at the initiation of the scroll. Based on this, we can do some checks. Here's some pseudo-code: ``` on scroll_start h_scroll=(get_initial_h_scroll_position) if scroll_right; then enable_back_gesture=false if h_scroll=100%; then enable_forward_gesture=true else; enable_forward_gesture=false elif scroll_left; then enable_forward_gesture=false if h_scroll=0%; then enable_back_gesture=true else enable_back_gesture=false fi ``` The way I've designed this is so that if a user scrolls horizontally at all, the gestures are disabled. This would make a huge difference and users may not end up accidentally discarding forms all the time or losing their place reading or doing whatever. Also, yes, on touchscreens, the sensetivity needs to be reduced. If you meet all the conditions to do a back gesture, the user should still need to swipe like, at lest 65% to actually activate the gesture. You currently need only a little bit of overscrolling/velocity to navigate back. Perhaps on a phone form factor, require that the gesture is started with the finger at the left 3% of the screen and pull the page at least 75% back, requiring you to swipe from the left or right edge and skip the aforemnentioned checks. This will prevent accidental back navigation. On laptops/tablets, require at least swiping the page 75% of the way to make sure this action is deliberate.

I think this is (probably?) a duplicate of bug #236583. If you disagree, then please explain why and I can reopen this. Otherwise, please add your commentary to bug #236583 so we have it in one place. *** This bug has been marked as a duplicate of bug 236583 ***