I accidentally swipe back 100% of the time (i.e, it's never an intentional navigation) and I'm willing to bet that I'm not alone. Since we haven't gotten around to fixing bug 860493, I propose that we disable back/forward navigation using the Mac trackpad. That is, set these two prefs to empty strings: browser.gesture.swipe.left browser.gesture.swipe.right

you're probably not alone, but don't assume that your experience is universal - i use this feature a lot, and it works perfectly fine even without the animations from bug 860493. i this it would be wise to make this decision based on telemetry data.

> i this it would be wise to make this decision based on telemetry data. wow, not sure how i ended up writing that :) i think it would be wise to make this decision based on telemetry data.

(In reply to Byron Jones ‹:glob› from comment #2) > i think it would be wise to make this decision based on telemetry data. Telemetry will indicate that swiping back does happen (as it does for me 100% of the time.) How about we test this with an add-on experiment?

I also dislike the feature and have had the pref disabled for a long time. But I am sympathetic to those who might use it. :-) It's certainly possible Safari users would be used to it, and for those users used to that platform feature, it could help them feel more at home in Firefox. But I so think the lack of animation makes it difficult to notice what's going on, so I think there is some merit in tying the availability of the two together. Telemetry data would be good. We could measure how many times a user initiates the gesture per <time period>; if it's relatively high, then it's likely they are deliberately using the feature.

FTR, I use it almost exclusively to go back and forth in history. There's also the occasional "this stupid thing", but it's frequently tied to in-page horizontal scrolling. I wonder how that technically behaves right now? Do we hame some sort of bump that you need to overcome from in-page scrolling to history swipe? In terms of measuring, there are probably two things to measure: - how frequently is this used? - how often is it used my mistake? The latter is probably hard to guesstimate? Maybe measure how often people go back and forth quickly, and compare that to different UX flows, probably also spanning platforms? All things here are soft, sadly.

(In reply to Cameron McCormack (:heycam) from comment #4) > I also dislike the feature and have had the pref disabled for a long time. > But I am sympathetic to those who might use it. :-) It's certainly possible > Safari users would be used to it, and for those users used to that platform > feature, it could help them feel more at home in Firefox. That implies that we offer the platform feature, which I'm asserting we currently do not. Safari on OSX has always had both the gesture and animation, and the Safari feature is gated by an OS pref that we don't check either. > But I so think the lack of animation makes it difficult to notice what's > going on, so I think there is some merit in tying the availability of the > two together. That's what I'm thinking. I can be convinced that we do something else (e.g., see Chromium) but as it is, this is a Lost Data bug in my mind, as an accidental navigation can delete the current page's state. > Telemetry data would be good. We could measure how many times a user > initiates the gesture per <time period>; if it's relatively high, then it's > likely they are deliberately using the feature. I'm not convinced this is measurable via telemetry. The values for <time period> and "relatively high" seem rather subjective.

Maybe unrelated but I would love to see this feature turned on for touch swipe on touch screens for windows users. Anyone know if we support this?

(In reply to Jim Mathies [:jimm] from comment #7) > Maybe unrelated but I would love to see this feature turned on for touch > swipe on touch screens for windows users. Anyone know if we support this? We don't. A good chunk of the code right now is specific to the cocoa widget, we'd have to reimplement that part in the windows widget. And figuring out the interaction with existing touch gestures might be a bit tricky.

(In reply to Axel Hecht [:Pike] from comment #5) > In terms of measuring, there are probably two things to measure: > > - how frequently is this used? > - how often is it used my mistake? > > The latter is probably hard to guesstimate? Maybe measure how often people > go back and forth quickly, and compare that to different UX flows, probably > also spanning platforms? All things here are soft, sadly. All assumptions about usage that could be measured seem very tricky to me. I also use this feature a lot and do sometimes browse back to the previous page for a quick peak and forward within seconds again, back to my current content. So while Jet might have accidentally hit the history navigation, my case would cause a false positive here.

Just want to add my two cents that I use this feature a lot. I think the problem has less to do with the feature itself, and more with the UX surrounding it. As there's no visual feedback, the feature is effectively invisible unless you know to look for it. Chrome and Safari both get around this by showing an animation as you perform the gesture: in Chrome's case, an arrow appearing from the edge of the page, in Safari's case, the page is scrolled over the reveal the previous / next page underneath. With that visual feedback, it's easy to see that the gesture is being activated, and also easy to cancel out of it. I can see the rationale behind disabling the feature as it exists today, but i think it would be valuable to improve the feedback it gives and eventually enable it by default again.

As of bug 860493, we now display arrows while swiping right and left. Hopefully, this addresses the concern raised here about accidentally swiping back and forth in history since there is now UX indicating that this may occur. It is possible to disable the arrows by setting the following pref: browser.history_swipe_animation.disabled = true As mentioned in comment 0, history swiping can be disabled completely by setting the following two prefs to empty strings: browser.gesture.swipe.left browser.gesture.swipe.right