Closed Bug 607657 Opened 14 years ago Closed 13 years ago

single swipe shouldn't take you from one sidebar to the other

Categories

(Firefox for Android Graveyard :: Panning/Zooming, defect, P1)

Tracking

(fennec2.0+)

VERIFIED FIXED
Firefox 4.0
Tracking Status
fennec 2.0+ ---

People

(Reporter: madhava, Assigned: mbrubeck)

References

Details

(Keywords: polish, Whiteboard: [has-patch])

Attachments

(2 files, 3 obsolete files)

Currently:

- I'm in one side bar or the other
- I swipe to close the sidebar, but do so a bit too aggressively
- my swipe closes the sidebar, but also takes me past content and opens the other sidebar
- I have to be more precise and close that one too

We should just not allow a swipe from one sidebar to also open the other (though a bit of movement into the other with a snapback would be great).
tracking-fennec: --- → ?
With our fast, smooth panning, this is more of an issue.
Assignee: nobody → mbrubeck
tracking-fennec: ? → 2.0b3+
OS: Mac OS X → All
Hardware: x86 → All
tracking-fennec: 2.0b3+ → 2.0+
Keywords: polish
Severity: normal → major
Priority: -- → P1
This occurs more often with the undo tab visible.  ie close a tab in the tab side bar and then swipe to the main content.  the control side tab will open.
Attached patch patch (obsolete) — Splinter Review
This very simple patch just stops abruptly right before you reach the other sidebar.  It affects both kinetic and non-kinetic panning.
Attachment #514482 - Flags: review?(mark.finkle)
Status: NEW → ASSIGNED
Component: General → Panning/Zooming
QA Contact: general → pan-zoom
Whiteboard: [has-patch]
Target Milestone: --- → fennec2.0
Comment on attachment 514482 [details] [diff] [review]
patch

_fromSidebar  -> _stopAtSidebar  (might be easier to understand what's happening)

Keep the | this._panScroller | calls together. Maybe add a blank line before the  | this._updateScrollbars |

This behavior, stopping abruptly at a sidebar is the simplest thing we can do for Fennec 4 and still improves the UX. We can file followup bugs for using momentum and kinetics.
Attachment #514482 - Flags: review?(mark.finkle) → review+
Attached patch patchSplinter Review
I noticed a bug in the previous patch: Once you started panning away from one sidebar, it prevented you from panning either sidebar into view, including the one that was already visible (and even if it is still partially visible).

This fixes the patch so that only the opposite sidebar is prevented from showing.
Attachment #514482 - Attachment is obsolete: true
Attachment #514497 - Flags: review?(mark.finkle)
Attachment #514497 - Flags: review?(mark.finkle) → review+
Attached patch followup: kinetic only? (obsolete) — Splinter Review
At Madhava's request, made this change apply only to kinetic panning.
Attachment #514497 - Attachment is obsolete: true
Attachment #514514 - Flags: ui-review?(madhava)
Attachment #514514 - Flags: review?(mark.finkle)
Pushed the original patch (stops for both kinetic and non-kinetic panning):
http://hg.mozilla.org/mobile-browser/rev/0f9296ac88e6

Marking this bug fixed.  Will push the second patch (stop for kinetic panning only) as a followup if mfinkle and madhava sign off on it.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Let's file a new bug for the kinetic panning patch
Comment on attachment 514514 [details] [diff] [review]
followup: kinetic only?

We decided not to take this patch now.  Will open a followup bug if it's desired in the future.
Attachment #514514 - Flags: ui-review?(madhava)
Attachment #514514 - Flags: review?(mark.finkle)
Attachment #514497 - Attachment is obsolete: false
The current implementation is definitely not the best. Now it is difficult to open another sidebar - you have to wait for a second until it's possible.

I like that another sidebar now does not appear on the same swipe which closes the opened sidebar, but it must be possible to open another sidebar with a second swipe done right away. This basically means: single swipe closes the sidebar, double-swipe switches from one sidebar to another. This, I think, would be the ideal implementation.

Is this issue really considered resolved? I don't think this is right.
I'm working on finding the right tweak to make this less intrusive, while still making it easier to dismiss one sidebar without accidentally opening the other.
Attached patch followup (obsolete) — Splinter Review
Here's a work-in-progress followup to allow scrolling again after a short timeout.  There's a bug where it sometimes stops scrolling in the wrong place; working on it.
Attachment #514514 - Attachment is obsolete: true
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch followup v2Splinter Review
Fixed the bug where it stopped in the wrong place.
Attachment #515143 - Attachment is obsolete: true
Attachment #515149 - Flags: review?(ben)
Whiteboard: [has-patch] → [has-patch][needs review]
Comment on attachment 515149 [details] [diff] [review]
followup v2

Looks good!
Attachment #515149 - Flags: review?(ben) → review+
Pushed followup: http://hg.mozilla.org/mobile-browser/rev/c7ae590eca80
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Whiteboard: [has-patch][needs review] → [has-patch]
Depends on: 637936
VERIFIED FIXED on:
Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b13pre) Gecko/20110315
Firefox/4.0b13pre Fennec /4.0b6pre
Device: HTC Desire
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: