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).
With our fast, smooth panning, this is more of an issue.
Assignee: nobody → mbrubeck
tracking-fennec: ? → 2.0b3+
tracking-fennec: 2.0b3+ → 2.0+
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.
Created attachment 514482 [details] [diff] [review] patch 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
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+
Created attachment 514497 [details] [diff] [review] patch 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 #514497 - Flags: review?(mark.finkle) → review+
Created attachment 514514 [details] [diff] [review] followup: kinetic only? At Madhava's request, made this change apply only to kinetic panning.
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
Last Resolved: 7 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 #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.
Created attachment 515143 [details] [diff] [review] followup 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 → ---
Created attachment 515149 [details] [diff] [review] followup v2 Fixed the bug where it stopped in the wrong place.
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
Last Resolved: 7 years ago → 7 years ago
Resolution: --- → FIXED
Whiteboard: [has-patch][needs review] → [has-patch]
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.