Closed Bug 818494 Opened 7 years ago Closed 7 years ago
Swipe to close tab action is sensitive
Nightly 20.0a1 (2012-12-05) Device: Samsung Galaxy SII OS: Android 4.0.1 Steps to reproduce: 1. Open multiple tabs. 2. Swipe to close a few tabs. Expected: The tab thumbnail should be closed after it covers a reasonable distance to avoid accidentally closing the tab. Actual The tab is closed almost instantly after the swipe action begins.
Ian, what do you think?
Summary: Swipe to close tab action is to sensitive → Swipe to close tab action is sensitive
This is an issue also on Firefox Mobile 18 beta 4. Here is a video from the Samsung Galaxy Tab 2 7.0 running Android 4.0.4: http://youtu.be/8d6hVhM3TTI
That video definitely looks a lot more sensitive than we want, I agree. If we looked at the Android app switcher as a comparison, the threshold to close a tab seems to be roughly 25-30% the width of the screen. I feel like we did that originally for our tab tray too, did that get changed recently?
I also believe this to be a regression. Bug 764812 fixed this when the issue was first seen.
Wes, wasn't this fixed in 17?
(In reply to Aaron Train [:aaronmt] from comment #5) > Wes, wasn't this fixed in 17? No, this has been fixed in 19 (see bug 772940). This bug is a dup of bug 787335.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 787335
https://bugzilla.mozilla.org/show_bug.cgi?id=787335 has been verified fix. This issue is still reproducible on Nightly 20.0a1 2012-12-14.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
getScaledMinimumFlingVelocity is actually a very very small number (62px/sec on my Nexus 7). The stock browser uses a larger number to determine this (1500/2). This feels a bit high to me tbh. 500 felt way too low. I decided to leave it here because I'd rather err on the hard side. Build at: http://dl.dropbox.com/u/72157/fennec-slideClose.apk
Attachment #693101 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 693101 [details] [diff] [review] Patch Review of attachment 693101 [details] [diff] [review]: ----------------------------------------------------------------- Nice. ::: mobile/android/base/TabsTray.java @@ +343,5 @@ > private int mSwipeThreshold; > private int mMinFlingVelocity; > + // same value the stock browser uses for after drag animation velocity in pixels/sec > + // http://androidxref.com/4.0.4/xref/packages/apps/Browser/src/com/android/browser/NavTabScroller.java#61 > + private static final float MIN_VELOCITY = 750; nit: move this to the top of the class.
Attachment #693101 - Flags: review?(lucasr.at.mozilla) → review+
nominate for tracking since this is an issue with a feature that was introduced in 18
Comment on attachment 693101 [details] [diff] [review] Patch [Approval Request Comment] Bug caused by (feature/regressing bug #): Swipe to close rewrite (bug 772940) User impact if declined: Swipe to close is very very easy to trigger Testing completed (on m-c, etc.): landed on mc yesterday. i'd like to at least make sure UX has had a chance to test this, but it matches the stock browser behavior Risk to taking this patch (and alternatives if risky): Very low risk. Changing a pref number String or UUID changes made by this patch: None.
Comment on attachment 693101 [details] [diff] [review] Patch I don't think that bug 772940 is actually in 18. Remove beta request.
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
Just wanted to make sure UX had played with this in nightlies and was ok with pushing this to Aurora.
UX says its good on irc!
Attachment #693101 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified fixed on: Nightly 20.0a1 (2013-01-02) Aurora 19.0a2 (2013-01-02)
You need to log in before you can comment on or make changes to this bug.