No focus selection highlight on tap and hold on links

VERIFIED FIXED

Status

()

Firefox for Android
General
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: aaronmt, Assigned: wesj)

Tracking

({uiwanted})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-stock])

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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.
(Reporter)

Updated

6 years ago
Keywords: uiwanted
(Assignee)

Comment 1

6 years ago
Created attachment 577895 [details] [diff] [review]
Patch

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 2

6 years ago
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+
(Assignee)

Comment 3

6 years ago
Created attachment 578009 [details] [diff] [review]
Patch for checkin
Attachment #577895 - Attachment is obsolete: true
Attachment #578009 - Flags: review+
https://hg.mozilla.org/projects/birch/rev/548fd9badc87
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
(Reporter)

Comment 5

6 years ago
Samsung Nexus S (Android 2.3.6)
20111201040252
http://hg.mozilla.org/projects/birch/rev/d71c91775f9b
Status: RESOLVED → VERIFIED

Updated

6 years ago
Duplicate of this bug: 698154

Updated

6 years ago
Depends on: 709663
You need to log in before you can comment on or make changes to this bug.