Closed Bug 704579 Opened 13 years ago Closed 13 years ago

No focus selection highlight on tap and hold on links

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: aaronmt, Assigned: wesj)

References

Details

(Keywords: uiwanted, Whiteboard: [parity-stock])

Attachments

(1 file, 1 obsolete file)

Currently when one taps and holds on an element such as a link, there is no selection highlight 'ring' around the element: example, tap and hold on any of the directories here http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/birch-android/

There should be a focus selection highlight on tap and hold.
Keywords: uiwanted
Attached patch Patch (obsolete) — Splinter Review
Patch moves all of our clicking code to use java native handlers. That introduces some delay between when you tap and when clicks fire, but I'll need to introduce it anyway to listen for double taps.

I had to do a lot of weird coordinate conversions here, and I'm not that sure about them. When we fire clicks, we need to make sure we're using window coordinates, which is what we're sending from Android to content. When we call things like DOMWindowUtils.elementFromPoint and getBoundingClientRect, we need/get results in... different coordinate systems.
Assignee: nobody → wjohnston
Attachment #577895 - Flags: review?(chrislord.net)
Comment on attachment 577895 [details] [diff] [review]
Patch

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

r+ if the two following transformations can't be avoided and are correct.

::: mobile/android/chrome/content/browser.js
@@ +1473,5 @@
> +    }
> +    let viewport = tab.viewport;
> +    return [
> +        ((aX-tab.viewportExcess.x)*viewport.zoom + viewport.offsetX),
> +        ((aY-tab.viewportExcess.y)*viewport.zoom + viewport.offsetY)

This looks correct, but I'm not really sure... Couldn't the event be delivered to the window instead of the browser element? That way, Gecko would do the transformations for us.

If events appear correct while zoomed in on a long page both at the top-left, middle and bottom-right, then this must be correct - it's easier to test it than to work through it.

@@ +1486,5 @@
> +    }
> +    let viewport = tab.viewport;
> +    return [
> +        (aX - viewport.offsetX)/viewport.zoom + tab.viewportExcess.x,
> +        (aY - viewport.offsetY)/viewport.zoom + tab.viewportExcess.y

Same here.
Attachment #577895 - Flags: review?(chrislord.net) → review+
Attachment #577895 - Attachment is obsolete: true
Attachment #578009 - Flags: review+
https://hg.mozilla.org/projects/birch/rev/548fd9badc87
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Samsung Nexus S (Android 2.3.6)
20111201040252
http://hg.mozilla.org/projects/birch/rev/d71c91775f9b
Status: RESOLVED → VERIFIED
Depends on: 709663
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: