Closed Bug 721100 Opened 8 years ago Closed 8 years ago

After panning, tap area is offset at wrong place

Categories

(Firefox for Android :: General, defect)

All
Android
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 12
Tracking Status
firefox11 --- unaffected
firefox12 --- verified
firefox13 --- verified

People

(Reporter: martijn.martijn, Assigned: cwiiis)

References

Details

(Keywords: regression, testcase, Whiteboard: [qa-], [not-fennec-11])

Attachments

(2 files)

Attached file testcase
See testcase, steps to reproduce:
- Pan downwards
- Tap on one of the links in the middle

Expected result:
- The link under the tap area should get highlighted

Actual result:
- The link further down the page gets highlighted.

Tested on the LG Optimus Black, Android 2.2.2 in portrait mode.
Possibly regression from touch events landing?
The code looks the same as always to me... I'm bisecting this to see if it was my fault (and figure out who's it was if it wasn't mine) :(
Seeing this too. Possibly regression from tiling.
Yeah, my bisect shows this coming from the tiling patches. Just glancing at the patch, do we need to take into account mRenderOffset when calculating where to send the click?
(In reply to Wesley Johnston (:wesj) from comment #4)
> Yeah, my bisect shows this coming from the tiling patches. Just glancing at
> the patch, do we need to take into account mRenderOffset when calculating
> where to send the click?

Yes, that's probably the culprit. Gecko's display port origin is now different from the origin of the tile, but convertViewPointToLayerPoint() still assumes that the origin of the tile is equal to Gecko's display port origin.

Chris should confirm.
(In reply to Patrick Walton (:pcwalton) from comment #5)
> (In reply to Wesley Johnston (:wesj) from comment #4)
> > Yeah, my bisect shows this coming from the tiling patches. Just glancing at
> > the patch, do we need to take into account mRenderOffset when calculating
> > where to send the click?
> 
> Yes, that's probably the culprit. Gecko's display port origin is now
> different from the origin of the tile, but convertViewPointToLayerPoint()
> still assumes that the origin of the tile is equal to Gecko's display port
> origin.
> 
> Chris should confirm.

Yes, well caught guys - I think this is a problem and I've crafted a patch to fix it. Just testing now...
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
another test case is in about:config
Duplicate of this bug: 721356
Blocks: 717283
tracking-fennec: --- → ?
OS: Windows 7 → Android
Hardware: x86 → All
Comment on attachment 591740 [details] [diff] [review]
Fix incorrect event offset due to render offset

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

r=me
Attachment #591740 - Flags: review?(pwalton) → review+
Thanks, pushed to inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/ddde7a49f6f7
tracking-fennec: ? → ---
OS: Android → Windows 7
Hardware: All → x86
https://hg.mozilla.org/mozilla-central/rev/ddde7a49f6f7
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 12
Duplicate of this bug: 721766
Patrick, please request aurora approval
Chris, please request aurora and beta approval and make sure this applies in the landing patch queue
This patch is already in aurora (Fx 12) as it landed on m-c prior to the version bump.

This patch is not needed on beta, because it is a fixup to the patches in bug 717283. Those were never put into beta, so this is not needed either.
tracking-fennec: --- → ?
OS: Windows 7 → Android
Hardware: x86 → All
Whiteboard: [qa^] → [qa^], [not-fennec-11]
Verified fixed on:

Firefox 13.0a1 (2012-02-16)
20120216031231
http://hg.mozilla.org/mozilla-central/rev/a853f4017192

Firefox 12.0a2 (2012-02-16)
20120216042010
http://hg.mozilla.org/releases/mozilla-aurora/rev/c6fcc091279c

--
Device: Motorola Droid PRO
OS: Android 2.3.3
Status: RESOLVED → VERIFIED
Whiteboard: [qa^], [not-fennec-11] → [qa-], [not-fennec-11]
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.