Allow customization of multi-touch actions by preference

VERIFIED FIXED in Firefox 3.1b2

Status

()

Firefox
General
VERIFIED FIXED
10 years ago
9 years ago

People

(Reporter: Mardak, Assigned: Mardak)

Tracking

(Depends on: 1 bug)

Trunk
Firefox 3.1b2
All
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

10 years ago
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.
(Assignee)

Comment 1

10 years ago
Created attachment 344496 [details] [diff] [review]
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...
Assignee: nobody → edilee
Status: NEW → ASSIGNED
Attachment #344496 - Flags: review?(sdwilsh)
(Assignee)

Comment 2

10 years ago
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.
(Assignee)

Updated

10 years ago
Depends on: 246720

Comment 3

10 years ago
(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

10 years ago
(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.
(Assignee)

Comment 5

10 years ago
Created attachment 344593 [details] [diff] [review]
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.
Attachment #344496 - Attachment is obsolete: true
Attachment #344593 - Flags: review?(sdwilsh)
Attachment #344496 - Flags: review?(sdwilsh)

Comment 6

10 years ago
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
Attachment #344593 - Flags: review?(sdwilsh) → review+
(Assignee)

Comment 8

9 years ago
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
(Assignee)

Updated

9 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.1b2
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?
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.