Closed Bug 818494 Opened 7 years ago Closed 7 years ago

Swipe to close tab action is sensitive


(Firefox for Android :: General, defect)

20 Branch
Not set



Firefox 20
Tracking Status
firefox18 - unaffected
firefox19 + verified
firefox20 --- verified
fennec 18+ ---


(Reporter: paul.feher, Assigned: wesj)



(1 file)

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. 

The tab thumbnail should be closed after it covers a reasonable distance to avoid accidentally closing the tab.

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:
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.
tracking-fennec: --- → ?
Flags: needinfo?(wjohnston)
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.
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 787335 has been verified fix. This issue is still reproducible on Nightly 20.0a1 2012-12-14.
Flags: needinfo?(wjohnston)
Resolution: DUPLICATE → ---
Attached patch PatchSplinter Review
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:
Attachment #693101 - Flags: review?(
Comment on attachment 693101 [details] [diff] [review]

Review of attachment 693101 [details] [diff] [review]:


::: mobile/android/base/
@@ +343,5 @@
>          private int mSwipeThreshold;
>          private int mMinFlingVelocity;
> +        // same value the stock browser uses for after drag animation velocity in pixels/sec
> +        //
> +        private static final float MIN_VELOCITY = 750;

nit: move this to the top of the class.
Attachment #693101 - Flags: review?( → review+
tracking-fennec: ? → 18+
Assignee: nobody → wjohnston
nominate for tracking since this is an issue with a feature that was introduced in 18
Comment on attachment 693101 [details] [diff] [review]

[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.
Attachment #693101 - Flags: approval-mozilla-beta?
Attachment #693101 - Flags: approval-mozilla-aurora?
Comment on attachment 693101 [details] [diff] [review]

I don't think that bug 772940 is actually in 18. Remove beta request.
Attachment #693101 - Flags: approval-mozilla-beta?
Closed: 7 years ago7 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.
Flags: needinfo?(madhava)
UX says its good on irc!
Flags: needinfo?(madhava)
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.