1218201 - Gecko caret issue with longTap-link (partially obscured by layer) on Breitbart homepage

Status: RESOLVED DUPLICATE of bug 1221335

(Firefox for Android Graveyard :: Text Selection, defect)

Description

[Mark Capella [:capella]]

Check the video: [0]

I've gone to the Breitbart main page, scrolled down the headlines to display one partially obscured by the banner layer.

The Android longpress touch debug-circle is observable.

expected: contextmenu should be displayed for link
actual: Something between browser.js / nsWindow.cpp / TouchCaret.cpp goofs

This may be resolved during bug 1215959 - (GeckoCaret2) Convert Android experimental Text-Selection front end ... tracking there also.

[0] https://www.dropbox.com/s/nftmub9ozsxocm9/edgeCaseLongtapFail.mp4?dl=0

Comment 1

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

On B2G, when long-pressing on the screen, APZ will fire contextmenu event first. If it isn't handled, then APZ fires long tap event so that AccessibleCaret could have a chance to handle the long tap. The logic is in APZEventState::ProcessLongTap()

Comment 2

[Mark Capella [:capella]]

Status: this appears to be a combination of small things adding up. Long pressing the large text <i> wrapped in an <a> causes selection start point above the floating z-layer, in this case under the hamburger menu button.

This seems to owe to un-decided Bug 1221335, |AccessibleCarets seem to select some things (images, etc) that contain no text|, where we now differ from the old Android-style of disallowing (amongst other things) elements that aren't expected to contain selectable text [0].

Duping to that bug, as the best overall solution.


[0] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/SelectionHandler.js?rev=5a814b26505b&mark=878-883#862