Hide bounding selection handles when text selection is being scrolled in inputs; bounding selection handles break off editable element




Firefox for Android
Text Selection
4 years ago
2 years ago


(Reporter: aaronmt, Unassigned)



35 Branch

Firefox Tracking Flags

(Not tracked)




(2 attachments)



4 years ago
Created attachment 8485898 [details]

Visit the bug URL; select all the text in the <input> and start scrolling the selection. The selection handles will drop off the element and end up into content.

When we scroll a selection we should hide the selection handles and only show them (will only be one visible in this case when a selection is scrolled into view) again when the boundary characters are visible again in the element.

We should match Chrome's behaviour here.

Comment 1

4 years ago
Created attachment 8485900 [details]

Chrome's behavior
I see Chrome (37.0.2062.117) on my GS3 and N7 produce similar results as to what we do

Did I repro wrong?

Comment 3

4 years ago
That's odd, I don't see that. I double checked, I'm on the same Chrome version. Do you have a 4.4 device, maybe it's different on that platform? I see it as I captured in the video, on scroll the handles disappear and don't de-attach from the input.
Both my N7/4.4.3 and my GS3/CM11/4.4.4

I'm using this snip:
data:text/html,<input value="hchchchchcxdhddhxychucgcdgggv"></input>

Paste into urlbar, hit enter, longtap text in <input>

Onscroll the handles float with the text for me (?)

Comment 5

4 years ago
No idea heh. Have you tried my exact test-case in the URL field?
I tried your exact test case with the same results. The handles float above the content, outside the bounds of the input box. What device are you using? What keyboard / IME ?

I've disliked our "floating handles" also, but I looked into this before and realized at the time Fennec isn't the only one with this behavior. Opera and Browser for example act the same also.

Comment 7

4 years ago
Galaxy S5, using the Samsung Keyboard. I wonder, if the zoom level is playing a part here?
Testing shows that the new Gecko selectionCarets we're putting together in bug 988143 seems to provide a better solution here:

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 :-)
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.