Closed Bug 1244705 Opened 4 years ago Closed 3 years ago

Text Selection carets slow/not smooth/do not register correct position on slide scroll movement

Categories

(Firefox for Android :: Text Selection, defect)

47 Branch
ARM
Android
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1273045

People

(Reporter: bullionareboy, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

STR:
1. Search for "What is the tallest building in the world?" in different search engines such as Startpage, Google, Yahoo to notice different behaviours.  
2. Try to move the cursor by sliding left and right to the end of the query. 

Notice that on yahoo search bar the cursor doesn't consistently move left or right. A jump occurs and it positions itself at the starting word of the side-scroll. 
The movement isn't smooth as well(Huge difference here and on chrome).  
Tried in on the bugzilla comment form as well as it occurs in a minor way there as well.  

Plus on selection of the search bar - the search icon is cut-off again by zooming in. 
This happens on Google,Yahoo.  

The scrolling doesn't consistently reveal items most of the items that are hidden. 
It does this very slowly.   

Moto G 2nd Gen 5.0.2 FF47
Focusing for the moment on the /Yahoo/ case, I see at least 3+1 issues where we behave differently in nightly/47 [0], than Chrome [1], perhaps needing individual bugs.

(a) Seems to be that on initial tap into the search/editable, we render the height of the field larger / inconsistently. The right-most |Cancel| button splits lines, and then |formhelper.autozoom| kicks in and the close|X| and |Cancel| buttons shift right off screen. 

(b) The initial tap into the pasted text, does not display the AccessibleCaret, requiring a second tap.

(c) Dragging the AccessibleCaret down below the search/editable causes us to jump it's position to the end of the field.

(d) An interesting miscellaneous APZ artificat is noticed [2] with simple, but different STR.

cc-ing: :kats for APZ and :TYLin for AccessibleCaret considerations.



[0] https://www.dropbox.com/s/1cgoeb0c2ii8jgi/bug1244705_yahoo_onNightly.mp4?dl=0
[1] https://www.dropbox.com/s/6z1pa7rtgj959mg/bug1244705_yahoo_onChrome.mp4?dl=0

[2] https://www.dropbox.com/s/upza0edto5lca1o/bug1244705_yahoo_onNightly_APZ.mp4?dl=0
Status: UNCONFIRMED → NEW
Ever confirmed: true
For (c) in comment #1: We had a interesting behavior that clicking on the top edge of the input moves the cursor to the beginning of the input, and click on the bottom edge moves the cursor to the end of the input. Dragging AccessibleCaret to the boundary is being affect by this behavior as well. I had shrink the content boundary by a constant factor to prevent this in [1]. Obviously it doesn't work on input field with more complex css decoration. It might worth to revisit the solution.

[1] https://dxr.mozilla.org/mozilla-central/rev/584870f1cbc5d060a57e147ce249f736956e2b62/layout/base/AccessibleCaretManager.cpp#1032-1033
Attached video fbcommnt2.mp4
Hello 
Just want to add that text selection in a Facebook comment box is impossible. There is no caret
Video attached for more info

Firefox 50
I cannot reproduce the issue described in comment 3 on Firefox 55.0a1 (2017-06-06). Also, this bug should be fixed by bug 1273045. I'm going to close this bug. Feel free to open another bug if you see anything unexpected. Thanks.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1273045
You need to log in before you can comment on or make changes to this bug.