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

Status: RESOLVED INVALID

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

Description

[Aaron Train [:aaronmt]]

Attachment: screenshot.png

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

[Aaron Train [:aaronmt]]

Attachment: chrome.mp4

Chrome's behavior

Comment 2

[Mark Capella [:capella]]

I see Chrome (37.0.2062.117) on my GS3 and N7 produce similar results as to what we do
https://www.dropbox.com/s/t6kxkr6jnfsvr0d/bug1064452.mp4?dl=0

Did I repro wrong?

Comment 3

[Aaron Train [:aaronmt]]

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.

Comment 4

[Mark Capella [:capella]]

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

[Aaron Train [:aaronmt]]

No idea heh. Have you tried my exact test-case in the URL field?

Comment 6

[Mark Capella [:capella]]

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

[Aaron Train [:aaronmt]]

Galaxy S5, using the Samsung Keyboard. I wonder, if the zoom level is playing a part here?

Comment 8

[Mark Capella [:capella]]

Testing shows that the new Gecko selectionCarets we're putting together in bug 988143 seems to provide a better solution here:

https://www.dropbox.com/s/2guohykpkqu30qd/bug1064452.mp4?dl=0

Comment 9

[Mark Capella [:capella]]

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 :-)