Closed Bug 1023418 Opened 7 years ago Closed 6 years ago

Auto-selecting a phone number does not stop at element breaks


(Firefox for Android :: Text Selection, defect)

Not set



Firefox 34
Tracking Status
fennec + ---


(Reporter: mfinkle, Assigned: capella)




(1 file, 1 obsolete file)

Bug 980197 added support for auto-selecting a phone number when long tapping on something like looks like a phone number. The current implementation does not stop selecting when hitting a linebreak, so it can select too much text.
Can we add tests for this feature too?
tracking-fennec: --- → ?
Can you provide a screenshot? Does this happen when selecting (long-press) editable text <input> / <textarea> or just display text?

I can get a (what I'm imagining you refer to) similar effect as here:

But it's not phone-number logic related ... you can do the same thing by long pressing a blank char in between two words, or simply the final white space on a line as here:

Based on SELECT_WORDNOSPACE selection logic here:
I'll get a testcase
tracking-fennec: ? → +
Flags: needinfo?(mark.finkle)

example: long tap on the "456-7890" and we select "123 | 456-7890"

So it's not a linebreak issue. It's an element break issue. We should not go outside the TD in the table. We should not go outside the div in both of the div examples. But I assume we want to select numbers that go across styling. Like the "styling" case.

Maybe we could generalize this to look for "container" type elements, and stop trying to select numbers outside the container where we start.
Flags: needinfo?(mark.finkle)
Summary: Auto-selecting a phone number does not stop at linebreaks → Auto-selecting a phone number does not stop at element breaks
Attached patch bug1023418p0.diff (obsolete) — Splinter Review
This makes things a little better. We'll still have interesting edge-cases based on where the user fine-grain-taps initially, and the subsequent results returned from Ci.nsIDOMWindowUtils.SELECT_WORDNOSPACE.

Consider where <CONTAINER>a has text and <CONTAINER>b has text and the user long-taps (somewhere in and around) <DIV>a ...

Does our initial nsISelection return focusNode = <CONTAINER>b offset.0? Or do we have <CONTAINER>a offset.testLen?
Assignee: nobody → markcapella
Attachment #8456745 - Flags: review?(mark.finkle)
Slight tweak.
Attachment #8456745 - Attachment is obsolete: true
Attachment #8456745 - Flags: review?(mark.finkle)
Attachment #8456818 - Flags: review?(mark.finkle)
Comment on attachment 8456818 [details] [diff] [review]

>diff --git a/mobile/android/chrome/content/SelectionHandler.js b/mobile/android/chrome/content/SelectionHandler.js

>+// Define elements that bound phone number containers.
>+const PHONE_NUMBER_CONTAINERS = "td,div";

I wish we could make the check a different way. Something less "a list of HTML elements"

>+      // Don't extend the selection into a new container.
>+      if (selection.focusNode != focusNode) {
>+        let nextContainer = (selection.focusNode instanceof Text) ?
>+          selection.focusNode.parentNode : selection.focusNode;
>+        if (nextContainer.mozMatchesSelector &&
>+            nextContainer.mozMatchesSelector(PHONE_NUMBER_CONTAINERS)) {

Do we need the | nextContainer.mozMatchesSelector | check? All elements should have mozMatchesSelecor, iirc.
Attachment #8456818 - Flags: review?(mark.finkle) → review+
I had cribbed that from , and did try to remove the line to explore why it was there.

Originally in testing I encountered something that barfed into logcat complaining of "not a function" or some-such... though I've removed it and tested again and can't seen to re-create towards identifying the element type.
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
You need to log in before you can comment on or make changes to this bug.