Closed Bug 826601 Opened 13 years ago Closed 10 years ago

Press on text selects nearby link instead of selecting the word at the press position

Categories

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

Product:
Firefox for Android Graveyard
Component:
Text Selection
Version:
17 Branch
Platform:
Other
Android
Type:
defect

Tracking

(fennec+)

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
fennec + ---

People

(Reporter: vincent-moz, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Android; Mobile; rv:17.0) Gecko/17.0 Firefox/17.0 Build ID: 20121116114411 Steps to reproduce: On a page, I press the screen over a word that is near a link (with the pen or a finger) Actual results: The link is selected (a popup appears: "Open link in a new tab" / "Copy link" / ...), as if the press position were just over it. Expected results: The pressed word should have been selected (in order to do a copy-paste). This bug makes some copy-paste impossible.
Are you using the Firefox from Google Play? Can you also try Firefox Beta? also can you let us know what kind of device/OS are you currently using? Thanks!
Flags: needinfo?(vincent-moz)
Yes, Firefox from Google Play. The device is a Samsung Galaxy Note II under Android 4.1.2.
Flags: needinfo?(vincent-moz)
Same problem with Firefox Beta (18.0) from Google Play.
Brian, anything actionable here with respect to the re-write using document.caretPositionFromPoint?
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
Flags: needinfo?(bnicholson)
I think this happens because all clicks have a touch radius, and if you tap an element that isn't clickable but it's close to a clickable element, the clickable element gets the focus instead. This is mentioned briefly here: http://hg.mozilla.org/integration/mozilla-inbound/file/bceda048221b/mobile/android/chrome/content/browser.js#l4410 CC'ing kats to see what our options are.
Flags: needinfo?(bnicholson)
I think this is more or less expected behaviour. You should be able to copy/paste the word by long-pressing on some other piece of text, and then dragging the selection handles to highlight the word you want to copy. I agree it's not ideal, but making that use case easier means it will be harder to click on links, which is a more common use case. We might also be able to solve this problem using some other method, like a magnifying-glass view, but that's going to be much harder to implement and unlikely to happen in the near future.
(In reply to Brian Nicholson (:bnicholson) from comment #5) > I think this happens because all clicks have a touch radius, and if you tap > an element that isn't clickable but it's close to a clickable element, the > clickable element gets the focus instead. Actually the problem occurs even when the element can be quite far (e.g. more than 5mm, which is huge compared to the radius of the point of the pen). (In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #6) > You should be able to copy/paste the word by long-pressing on some other piece of text, > and then dragging the selection handles to highlight the word you want to copy. This isn't really possible if there are many links. Moreover the selection handles sometimes disappear too quickly (after a fraction of second), which is also a problem to be able to copy the text one has just selected. > I agree it's not ideal, but making that use case easier means it will be > harder to click on links, which is a more common use case. The distance threshold could be chosen as an option. > We might also be able to solve this problem using some other method, like a > magnifying-glass view, but that's going to be much harder to implement and > unlikely to happen in the near future. The Maemo browser has a "copy mode". One advantage is that one can easily copy text from links.
It might be interesting to use the touch radius to determine how "fuzzy" to make our link detection.
(In reply to Vincent Lefevre from comment #7) > Actually the problem occurs even when the element can be quite far (e.g. > more than 5mm, which is huge compared to the radius of the point of the pen). > Oh, you're using a pen? We assume all touch input is coming from a finger, which is generally less precise. So the touch radius may be fatter than you'd want. Try modifying the browser.ui.touch.top (and .left, .right, and .bottom) prefs in about:config and see if that helps. > This isn't really possible if there are many links. Can you provide a URL to reproduce this case? > Moreover the selection > handles sometimes disappear too quickly (after a fraction of second), which > is also a problem to be able to copy the text one has just selected. > This sounds like a separate bug. > The distance threshold could be chosen as an option. > It is somewhat configurable, try adjusting the prefs I mentioned above. > > The Maemo browser has a "copy mode". One advantage is that one can easily > copy text from links. I need an addon to do that even on Desktop FF :(
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9) > Oh, you're using a pen? Yes, the Galaxy Note II comes with a pen. > We assume all touch input is coming from a finger, > which is generally less precise. So the touch radius may be fatter than > you'd want. Try modifying the browser.ui.touch.top (and .left, .right, and > .bottom) prefs in about:config and see if that helps. I've tried the value 4, and even 0 (instead of the default 16 / 32 / 32 / 48), but this doesn't change anything. > > This isn't really possible if there are many links. > > Can you provide a URL to reproduce this case? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696282 which currently shows: [...] Reported by: Vincent Lefevre <vincent@vinc17.net> Date: Tue, 18 Dec 2012 22:12:01 UTC Severity: grave Tags: confirmed, upstream Merged with 658732 [...] For instance, pressing on "upstream" in the Tags line selects either "658732" (just below) or "Vincent Lefevre [...]", which is 3 lines above!
(In reply to Vincent Lefevre from comment #10) > For instance, pressing on "upstream" in the Tags line selects either > "658732" (just below) or "Vincent Lefevre [...]", which is 3 lines above! Yeah, that seems bad (and not expected). I can't reproduce it with my finger on the Galaxy Nexus though; I don't have a Note II to test with so I can't debug it. You said in comment #0 that you can reproduce this behaviour with your finger as well - was that also on this debian bug page, or was that a different site? And if you have any other android devices, can you try to reproduce it there as well?
Strange. I've tried again on the same page, and I can no longer reproduce the bug with the pen. For instance, if I press "12" (in "22:12:01"), "12" is selected, even though it is just below the link. This is fine. But if I try with the finger, it gets completely wrong: if I press "12", then "grave" is selected, though it is quite far away! I don't have other Android devices. I think that what I've said in comment #0 concerning the finger was also on the same page, but I'm not sure, as I had tried several pages to see whether this could come from something particular on the Debian bug page.
(In reply to Vincent Lefevre from comment #12) > Strange. I've tried again on the same page, and I can no longer reproduce > the bug with the pen. For instance, if I press "12" (in "22:12:01"), "12" is > selected, even though it is just below the link. This is fine. I've just looked at the browser.ui.touch.* values, and they are all set to 0. I don't know why, because I've never set them to 0! I had just reset them to their initial values by clicking on "Reset", which are not 0. The difference may come from that. > But if I try with the finger, it gets completely wrong: if I press "12", then "grave" is > selected, though it is quite far away! This may be normal: if I try a bit higher, "12" is selected as expected. It seems that here, Firefox necessarily selects a word on the same line, even if there is a big blank between the press point and the last word of the line.
(In reply to Vincent Lefevre from comment #13) > I've just looked at the browser.ui.touch.* values, and they are all set to > 0. I don't know why, because I've never set them to 0! I had just reset them > to their initial values by clicking on "Reset", which are not 0. > > The difference may come from that. Strange. Does resetting them make the original problem reproducible again?
Assignee: nobody → wjohnston
tracking-fennec: ? → +
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14) > Strange. Does resetting them make the original problem reproducible again? Yes, but only after restarting Firefox.
Ah yes, the browser.ui.touch.* prefs only take effect upon restarting Firefox. So it sounds like if you set those values to zero (and restart) the problem goes away, and resetting them (and restarting) makes the problem come back. I wonder if we just use a zero radius if the MotionEvent is coming from an InputDevice.SOURCE_STYLUS or SOURCE_MOUSE. :wesj, thoughts?
Flags: needinfo?(wjohnston)
I filed bug 837752 to make us use the touch radius for fluffing instead. Thats my preferred approach to this stuff.
Depends on: 837752
Flags: needinfo?(wjohnston)
This was fixed in bug 772280, although I think we need to unify some of these touch distance prefs. I'll file a new bug for that.
Assignee: wjohnston → nobody
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
The description of bug 772280 is different ("Some nearby text will be selected, even though you are only pressing whitespace!"). Here I press over text, not whitespace, and the problem is that a link is selected (instead of the text that was pressed). This is rather different. So, I don't see this as a duplicate. Or perhaps you mean that the change fixes both bugs?
Ahh, you're right. Sorry about that. I'll have to think about this. We do some magic to try to find links near your finger when you tap. If you want to select text near (or in) a link right now, you have to select somewhere else and then edit the selection.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
filter on [mass-p5]
Priority: -- → P5
Pruning some old bugs (part 2) either: ) obviated by new Core/Layout AccessibleCaret implementation in m-c and stable, targeted for 47. ) Or no longer being observable. If you still see what you consider incorrect behaviour with the new version, please file a new bug targeted there, and attach a test-case or example link to help things :-)
Status: REOPENED → RESOLVED
Closed: 12 years ago → 10 years ago
Resolution: --- → INVALID
The bug is not invalid! The problem still occurs (whether I use a pen or the finger, still at the same URL) with 45.0b1, which is the latest beta. IMHO, the bug should be left open until 47 is out, unless you know that the bug was fixed by this new implementation.
Thanks for commenting. I'd was hoping you'd check in m-c and re-file as a new issue, as the code there is completely replacing what you see in 45 (hence "invalid"). If you'd like to comment here, that's fine, I can morph the bug for you. Can you try using the new version?
If you're unable to test using nightly / v47, feel free to re-open here of course :-)
New bug, tested with Nightly: bug 1244498.
I believe Bug 1247095 will address this issue.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.