Closed Bug 591398 Opened 9 years ago Closed 9 years ago

Use three-finger gesture swipe to enter/exit Tab Candy

Categories

(Firefox :: General, defect, P1)

defect

Tracking

()

RESOLVED FIXED
Firefox 4.0
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: aza, Assigned: aza)

References

Details

(Keywords: dev-doc-complete, Whiteboard: [can land])

Attachments

(1 file, 2 obsolete files)

A simple change to firefox.js to allow using a gesture to get into/out of Tab Candy.
Attached patch Changing the gesture meaning. (obsolete) — Splinter Review
Attachment #469927 - Flags: review?(dolske)
Target Milestone: --- → Firefox 4.0b5
Please get this ui-reviewed.
Component: TabCandy → General
QA Contact: tabcandy → general
Comment on attachment 469927 [details] [diff] [review]
Changing the gesture meaning.

Yeah, this needs ui-review first. I already use the existing gesture a lot, seems like having it for page navigation is extremely useful.

Sadly (AIUI) OS X doesn't give us access to the 4-finger gestures, which would be a natural fit on OS X.
Attachment #469927 - Flags: review?(dolske) → ui-review?(limi)
Fair enough. I'll wait for Limi's review (thanks for pointing out the need, Dão!). I've always used the keyboard for jumping up and down in a page, never used the three finger swipe.

The main interaction I care about is the getting-to-Panorama gesture, and less the getting out again gesture (which brings you to the top of the page, which is by far more useful).
Thus, I propose this behavior (of course, this bit-rots my first and only patch, naturally):

* Swipe Down always gets you into Panorama
* Swipe Up zooms back to the tab you were on, unless you have moved the mouse and are pointed at another tab
* Swipe Up when not in Panorama jumps to the top of the page.

Thus, the only collateral is jumping to the bottom of a page via a gesture, which I argue is not a super-high usage use-case.
Huh I thought that there could be some way to access 4-finger swipes on 10.6 but  I didn't find any discussions on an API to do that.

Two thoughts: there are the rotate gestures that are available but aren't mapped to anything. Perhaps they'd work well for TabCandy (not considering discoverability). Twist right to enter, twist left to exit (or twist in any direction would toggle). I think we tried to map these to next tab/previous tab at some point but people found it too sensitive. It would be a matter of experimenting and see how it works.

Also, if Swipe Up/Down is the way to go, why not simplify it like this: If you're already at the top of the page, swipe up would enter tabcandy. Otherwise, it works as is. Swipe down would always scroll the page because it's harder to tell when you're in the bottom of a page (personally I sometimes try to swipe down to check if I reached the end)
The rotate gestures are generally harder to perform physically, so I'd like to stick to the swipe up/down gestures.

Consistency is key to having gestures feel reliable. So I'd like to stick with the proposal in comment 5.
(In reply to comment #4)
> Fair enough. I'll wait for Limi's review (thanks for pointing out the need,
> Dão!). I've always used the keyboard for jumping up and down in a page, never
> used the three finger swipe.

It's established, and in use, so I think the four-finger swipe would be a much better fit here, since we're not using that already.

Trying to make three-finger swipe do different things depending on where you are on the page is going to cause mode errors.

I wouldn't do rotate, and even the current pinch-to-zoom gestures are extremely error-prone, and we should look into heightening the threshold for those (but that's a different issue, sorry :).
(In reply to comment #6)
> Huh I thought that there could be some way to access 4-finger swipes on 10.6
> but  I didn't find any discussions on an API to do that.

BetterTouchTool seems to be able to get to the four-finger swipe, maybe email the author and ask how?

http://superuser.com/questions/53308/can-you-rebind-four-finger-swipe-in-new-macbooks/71387#71387
Then four-finger swipe it is.
Assignee: nobody → edilee
FYI, you can add this to about:config to test:

browser.gesture.swipe.up.shift = Browser:ToggleTabView
Tom Dyas implemented the original 3-finger swipe logic, so he might be able to comment on the 4-finger swipe.
Assignee: edilee → nobody
Also, fyi, the prefs also support various combinations of shift/alt/ctrl/meta.. you could even use all 4 modifiers! ;)

browser.gesture.swipe.up.shift.alt.ctrl.meta -> Browser:ToggleTabView
Attachment #469927 - Attachment is obsolete: true
Attachment #469927 - Flags: ui-review?(limi)
Isn't four-finger swiping bound to Exposé (down) and Show-Desktop (up) by default in 10.6?

Also, Google Chrome uses the three fingers gesture for its Tab Overview (enter = down, exit = up or down).  Would be nice if similar things worked similarly across browsers.
I am once again advocating 3-finger swipe. Here is why:

* 4-finger swipe is in use by the OS
* 3-finger swipe I would argue isn't used that often currently and can be re-appropriated (need Test Pilot data)
* From a interaction hierarchy standpoint 1 finger means move the cursor over the page, 2 means move the page, 3 should mean move the tab, 4 means move the window. It doesn't make sense for 3 to also be at the page level.
* We shouldn't used a modifier key because it requires two hands (and using a gesture enables one-handed browsing in the first place)
(In reply to comment #12)
> Tom Dyas implemented the original 3-finger swipe logic, so he might be able to
> comment on the 4-finger swipe.

Cocoa only passes the three-finger swipe to applications via the swipeWithEvent: method of NSResponder. (The event passed in to that method has no information regarding how many fingers were involved in the swipe.)  So you are not going to be able to easily determine when a four-finger swipe has occurred using the documented Cocoa API.

On Mac OS X 10.6, you could try tracking the individual touches on multi-touch trackpads that support such tracking using the following methods of NSResponder: touchesBeganWithEvent:,touchesMovedWithEvent:, touchesCancelledWithEvent:, and touchesEndedWithEvent:.  However, not all trackpads support that and it is only a documented API on 10.6.  I am not sure if it is available or not on 10.5 as an undocumented API.

Regardless, the cocoa widget code only monitors for swipeWithEvent:, magnifyWithEvent:, and rotateWithEvent: gestures.  While we have DOM events now for multi-touch, it is for multi-touch on a touch display and not for a multi-touch trackpad.  Some thought would need to be done, I think, for how touch events should integrate into the browser when the touches are not performed on the display itself.  (Of course, that would be the subject for new bug.)

Link to the info:  http://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSResponder_Class/Reference/Reference.html#//apple_ref/doc/uid/20000015-SW35

(In reply to comment #15)
> I am once again advocating 3-finger swipe. Here is why:
> 
> * 4-finger swipe is in use by the OS
> * 3-finger swipe I would argue isn't used that often currently and can be
> re-appropriated (need Test Pilot data)
> * From a interaction hierarchy standpoint 1 finger means move the cursor over
> the page, 2 means move the page, 3 should mean move the tab, 4 means move the
> window. It doesn't make sense for 3 to also be at the page level.
> * We shouldn't used a modifier key because it requires two hands (and using a
> gesture enables one-handed browsing in the first place)

You have my vote.

I added the top page / bottom page behavior for the three-finger swipes out of my personal need to jump to the bottom of certain large web pages faster.  I certainly did not study, and I do not believe any Mozilla people have truly studied, what the "proper" use for those two swipe gestures should be.

If changing the meaning of the up/down swipe gestures will bring us into parity with Google Chrome, I'm all for it.  And even more for it if it gives access to Tab Candy.
I would also add that, if this change is to be made, it is critical to make it  now in 4.0 because a major version bump is the time to break such user expectations if warranted and not later in the 4.x series itself.
(In reply to comment #15)
> I am once again advocating 3-finger swipe. Here is why:
> 
> * 4-finger swipe is in use by the OS
> * 3-finger swipe I would argue isn't used that often currently and can be
> re-appropriated (need Test Pilot data)
> * From a interaction hierarchy standpoint 1 finger means move the cursor over
> the page, 2 means move the page, 3 should mean move the tab, 4 means move the
> window. It doesn't make sense for 3 to also be at the page level.
> * We shouldn't used a modifier key because it requires two hands (and using a
> gesture enables one-handed browsing in the first place)

Yeah, I think this makes sense. Probably have to re-train Beltzner's muscle memory ;) — but I think three fingers to activate Panorama makes sense.
Somewhat unrelated to this bug, but if we're doing 3 fingers = move the tab, should left/right be set to move to the previous and next tab instead of back/forward?

You can do this now through about:config:
browser.gesture.swipe.left = Browser:PrevTab
browser.gesture.swipe.right = Browser:NextTab
(In reply to comment #19)
> Somewhat unrelated to this bug, but if we're doing 3 fingers = move the tab,
> should left/right be set to move to the previous and next tab instead of
> back/forward?

Safari and Chrome both assign left/right swipe to back/forward.  For consistency, Firefox should keep those mappings as the default.
Priority: -- → P1
Whiteboard: [b8][interaction][good first bug]
Target Milestone: Firefox 4.0b5 → Firefox 4.0
Blocks: 597043
(In reply to comment #5)
> * Swipe Up when not in Panorama jumps to the top of the page.
> 
> Thus, the only collateral is jumping to the bottom of a page via a gesture,
> which I argue is not a super-high usage use-case.

'Swipe Up to jump to top of page' makes the gestures asymmetric and more prone to mode error, imho.

You would also need a more complex value for browser.gesture.swipe.up.
Assignee: nobody → aza
Attached patch Patch v2 (obsolete) — Splinter Review
This patch has the following implementation (ui+ by Limi):

* swipe down with three fingers shows Panorama
* swipe up with three fingers either
  - hides Panorama if in Panorama
  - scrolls to the top of the page if not
Attachment #477166 - Flags: ui-review+
Attachment #477166 - Flags: feedback?(ian)
Comment on attachment 477166 [details] [diff] [review]
Patch v2

Actually, I'm never in favor of overloading operations to mean two different things. I think three-finger swipe should be either Panorama or top/bottom page, but not both, depending on where you are.

How about using three-finger tap for Panorama instead? Since it doesn't need two different operations, that might be an option if we can detect it. (Don't know what our capabilities are here)
(In reply to comment #23)
> How about using three-finger tap for Panorama instead? Since it doesn't need
> two different operations, that might be an option if we can detect it. (Don't
> know what our capabilities are here)

Three-finger tap is not a viable option in my view currently for the following reasons:

1.  There is no DOM support to pass such a gesture up to the browser code from the widget level.

2.  You would only be able to detect a three-finger tap if the cocoa widget code implemented the touch tracking methods that are only available on Mac OS X 10.6 and not 10.5.  Gesture methods only exist for zooms, rotation, and three-finger swipes.

3.  Moreover, at least on Mac OS X, the gesture would be inconsistent with how single and double taps are interpreted as left and right clicks, respectively. A triple tap would not be as discoverable in my opinion for user as up and down swipes.
Using three-finger tap wouldn't be that intuitive in my opinion.  The zoom-out/in animation of Panorama just fits better with a swipe gesture.
Exposé, which has similarities with Panorama, also uses a swipe gesture.  And there's Google Chrome which already uses 3-fingers down for its Tab Overview.

I'd just make 3-fingers up unbound outside of Panorama mode for now by default.

(A three-finger tap would be more something for a direct context sensitive action, like 'open link in new tab'.)
> Actually, I'm never in favor of overloading operations to mean two different
> things. I think three-finger swipe should be either Panorama or top/bottom
> page, but not both, depending on where you are.

For reasons I stated in comment 21, I concur.

> How about using three-finger tap for Panorama instead? Since it doesn't need
> two different operations, that might be an option if we can detect it. (Don't
> know what our capabilities are here)

A tap is more like a click. Entering Panorama is like zooming out, which is more like the default 4-finger down _swipe_. I think that doing nothing on three-finger up swipe when not in Panorama works best for now.

FWIW, I don't know how often people do this, but I sometimes map three-finger tap/click to middle-click (which opens link in new tab, closes tab, etc.)
Comment on attachment 477166 [details] [diff] [review]
Patch v2

Implementation looks fine, but sounds like it needs to be updated due to the continued UI discussion.
Attachment #477166 - Flags: feedback?(ian) → feedback-
Attached patch Patch v3Splinter Review
New functionality as per Limi:

* three-finger swipe down to enter Panorama
* three-finger swipe up to leave Panorama
Attachment #477166 - Attachment is obsolete: true
Attachment #477707 - Flags: feedback?(ian)
Comment on attachment 477707 [details] [diff] [review]
Patch v3

Looking good.
Attachment #477707 - Flags: review?(dietrich)
Attachment #477707 - Flags: feedback?(ian)
Attachment #477707 - Flags: feedback+
Status: NEW → ASSIGNED
Any word on the review?
blocking2.0: --- → ?
This isn't a blocker, IMO.

Grudgingly I'll agree with the three-finger gesture changes. My only fear is that it's a pretty high-impact accidental thing to go into, but our exit-from-Panorama behaviour's pretty good.

For those like me who're upset by the change, the prefs are re-mappable in about:config, no worries.
blocking2.0: ? → -
Adding this to b7 as per Beltzner's comment in IRC.
blocking2.0: - → ?
This stays betaN until we get a reviewed patch, then we can switch it to beta7 to get it in (mostly for bookkeeping reasons, we go to war with the system we have!)

Should be a simple review, though.
blocking2.0: ? → betaN+
Comment on attachment 477707 [details] [diff] [review]
Patch v3

r=me. as a followup, would be nice to get the other enter/exit code to use these commands instead of calling the methods directly.
Attachment #477707 - Flags: review?(dietrich) → review+
blocking2.0: betaN+ → beta7+
Keywords: checkin-needed
Whiteboard: [b8][interaction][good first bug] → [can land]
http://hg.mozilla.org/mozilla-central/rev/9f96a631ecca

(In reply to comment #34)
> r=me. as a followup, would be nice to get the other enter/exit code to use
> these commands instead of calling the methods directly.

I'll leave followup filing to someone here.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
(In reply to comment #19)
> Somewhat unrelated to this bug, but if we're doing 3 fingers = move the tab,
> should left/right be set to move to the previous and next tab instead of
> back/forward?
> 
> You can do this now through about:config:
> browser.gesture.swipe.left = Browser:PrevTab
> browser.gesture.swipe.right = Browser:NextTab

No, those should match what's done in Safari.
Flags: in-litmus?(twalker)
Depends on: 601090
> Thus, the only collateral is jumping to the bottom of a page via a gesture,
> which I argue is not a super-high usage use-case.

This is the "I want to comment on this bug" use case!

Also, jumping to top of page via three-finger swipe no longer works either, as expected per comments here.  This is also a very common use case for me (most commonly with W3C specs so I can get to the "newest version" link, but also on many other pages.
Yes, we all agree that it's a very common use case with Mozilla Developers and Web Developers. Those people are also very likely to be people who'll know how to set their about:config prefs back to how they like them.

This bug is FIXED now; please only add comments if verifying or re-opening. We don't need a bunch of pile-on hatred or love. :)
While I agree that being able to jump to the top of a page using 3-finger swipe is awesome, the UX team wasn't able to reach consensus there. See Limi's comment above. Patch v2 includes an implementation of that method.
> Those people are also very likely to be people who'll know how
> to set their about:config prefs back to how they like them.

Only if we document that; adding dev-doc-needed.  And sorry about the comment, but sheppy needs to know what needs documenting here....
Keywords: dev-doc-needed
Could an option be added in preferences to let users set the behavior they want without having to use about:config?
(In reply to comment #43)
> Could an option be added in preferences to let users set the behavior they want
> without having to use about:config?

No.
backed out as part of bug 613909. Can be manually restored by using about:config using the prefs as shown in http://hg.mozilla.org/mozilla-central/rev/556d2c5bef08
I have long since been owner of this feature.  removing myself from the request field.
Flags: in-litmus?(twalker)
You need to log in before you can comment on or make changes to this bug.