Closed Bug 876060 Opened 8 years ago Closed 8 years ago

Medium tap on link does not follow the link

Categories

(Firefox for Android Graveyard :: General, defect)

22 Branch
ARM
Android
defect
Not set
normal

Tracking

(firefox22 affected, firefox23 affected, firefox24 verified)

VERIFIED FIXED
Firefox 24
Tracking Status
firefox22 --- affected
firefox23 --- affected
firefox24 --- verified

People

(Reporter: jruderman, Assigned: kats)

References

Details

(Whiteboard: [testday-20130726])

Attachments

(1 file)

Using Firefox Beta 22 on Android 4.2.2 on a Samsung Galaxy Nexus:

1. Hold down a link for half a second (long enough to be sure I tapped the right thing, but not long enough to bring up a menu)

Result: The link background becomes gray, but Firefox does not follow the link.

Expected: Firefox should follow the link.
This works for me, links are followed through every time.
Odd, I can reproduce this almost reliably.
Do you see this on Nightly too? If so I can can create a custom build with some debug logging to isolate the issue.

Also is there a specific page/link you can point to with this problem?
I see this on Nightly too.

This happens on most pages, including:
* Links at the bottom of http://nightly.mozilla.org/
* Links at the bottom of http://www.squarefree.com/start/
I think I know what Jesse means here, 3 possible scenarios:

1. Hold down the link for a very short time
  -> tap on link, link follows through.

2. Hold down the link for not a very short time but short enough to *not* trigger the menu
  -> word gets highlighted.

3. Hold down the link for a longer time than scenario 2.
  -> menu comes up.

Jesse should be hitting the 2nd scenario.
I saw this today too on Nightly (05/29); HTC One (Android 4.1.2)
Assignee: nobody → bugmail.mozilla
Attachment #755951 - Flags: review?(chrislord.net)
Are you sure this doesn't send taps if you tap and pan?
Yeah if you pan you don't get the onSingleTapUp call.
Comment on attachment 755951 [details] [diff] [review]
Treat medium-length taps as clicks

Review of attachment 755951 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine, couple of nits.

::: mobile/android/base/gfx/JavaPanZoomController.java
@@ +1233,5 @@
>  
>          GeckoAppShell.sendEventToGecko(GeckoEvent.createBroadcastEvent(event, json));
>      }
>  
> +    @Override public boolean onDown(MotionEvent motionEvent) {

Don't we usually put @Override on a separate line?

@@ +1238,5 @@
> +        mMediumPress = false;
> +        return false;
> +    }
> +
> +    @Override public void onShowPress(MotionEvent motionEvent) {

ditto.

@@ +1243,5 @@
> +        // If we get this, it will be followed either by a call to
> +        // onSingleTapUp (if the user lifts their finger before the
> +        // long-press timeout) or a call to onLongPress (if the user
> +        // does not). In the former case, we want to make sure it is
> +        // treated as a click.

So I assume that after this, a double-tap won't be recorded? If so, I think this should be added to the comment here. The comment below alludes to this, but I think it could be clearer.
Attachment #755951 - Flags: review?(chrislord.net) → review+
https://hg.mozilla.org/mozilla-central/rev/a18e65a667e1
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Is this annoying enough to be worth uplifting? I don't think it's a regression - it should be happening on previous versions of Fennec too.
Status: RESOLVED → VERIFIED
tracking-fennec: --- → ?
I can verify this is fixed in a Galaxy S2 phone with Android 4.0.3 and the latest Aurora build.
Whiteboard: [testday-20130726]
tracking-fennec: ? → ---
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.