Closed Bug 876060 Opened 12 years ago Closed 12 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+
Status: NEW → RESOLVED
Closed: 12 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.

Attachment

General

Created:
Updated:
Size: