461376 - Allow customization of multi-touch actions by preference

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Ed Lee :Mardak]

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.

Comment 1

[Ed Lee :Mardak]

Attachment: v1 (draft)

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...

Comment 2

[Ed Lee :Mardak]

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.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

(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).

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

(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.

Comment 5

[Ed Lee :Mardak]

Attachment: v1.1

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.

Comment 6

[Simon Bünzli]

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 7

[Shawn Wilsher :sdwilsh]

Comment on attachment 344593 [details] [diff] [review]
v1.1

r=sdwilsh, but please check with mconnor regarding comment 6

Comment 8

[Ed Lee :Mardak]

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

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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?