We can let the user customize what each action does by preference, but we should still provide good defaults. I started writing a patch that lets the users select actions by setting a number, e.g., 1 for browser back, 2 for browser forward, but then it seemed pretty arbitrary for which actions I included, and making a "good list for all" is tricky. So I figured that we could just expose any normal command that is available to the browser like keyboard shortcuts. There also should be a way to specify different actions based on pressing Shift or not. Such as close tab vs undo close tab for the same swipe gesture.

Here's an initial stab at allowing pretty much full customization. You can specify complex key combinations or no key combos: browser.gesture.swipe.up.shift.alt.ctrl.meta -> cmd_newNavigator browser.gesture.swipe.up -> cmd_newNavigatorTab This patch will automatically go for the "most-key" preference if it's set then cut back on keys to find a command. It prefers "meta" key over "shift" if you don't have a swipe.up.shift.meta pref set and press both keys. There's a couple TODOs such as probably caching the preference (probably not really a bottleneck -- no need for premature optimization). The bigger issue is that there's no xul:command for next/prev tab...

beltzner: Oh, in the current state of this patch, swipe.up = new tab, swipe.down = close tab, swipe.down.shift = undo close tab. Additionally, holding shift when pinching will cause the zoom to reset.

(In reply to comment #2) > beltzner: Oh, in the current state of this patch, swipe.up = new tab, > swipe.down = close tab, swipe.down.shift = undo close tab. Closing a tab using swipe.down sounds pretty scary. Too easy to close a tab accidentally. Gestures shouldn't delete/destroy/close anything, at least not without confirmation, IMHO (with multimodal UI hat on).

(In reply to comment #3) > Gestures shouldn't delete/destroy/close anything, at least not > without confirmation ...unless undo really does exact undo and is fast. Our current RecentlyClosedTab isn't such undo.

Keeps the gesture behavior the same as current trunk (swipe left/right back/for; swipe up/down scroll top/bot; pinch in/out zoom; twist change tab) with the addition of shift-pinch to reset zoom. So basically the patch is just to make commands configurable by pref without changing behavior.

Wouldn't this be much better served by an extension (which could not only extract all the possible command IDs, but also display any human readable labels associated with it)? BTW: We don't do this for keyboard shortcuts - why should touchpad gestures be any different? IMHO we should ship with sane defaults and then have extension-less Firefox installations always behave exactly the same way WRT user input.

Comment on attachment 344593 [details] [diff] [review] v1.1 r=sdwilsh, but please check with mconnor regarding comment 6

beltzner said that the customization is fine as it should help both advanced end users and add-ons (both those specifically to customize multi-touch with UI to select actions or other add-ons that want to allow the user to activate things with multi-touch). This is basically a refactoring of the code while providing sane defaults. http://hg.mozilla.org/mozilla-central/rev/5b609dfce6c9

Works like a charm. Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090214 Shiretoko/3.1b3pre Ubiquity/0.1.5 ID:20090214020701 Edward, is it somehow possible to get automated tests for?