1140163 - Text Selector in Firefox for Android is Slow and Counter Productive.

Status: RESOLVED INVALID

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

Description

[bull500]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150305072141

Steps to reproduce:

Enter text in a text field and try moving the text selector tool.
Tested on Bugzilla comment box as well as Yahoo search bar(after an initial search is performed)




Actual results:

On Bugzilla comment box:
Performance slowed down, the text selector tool became very slow and was extremely difficult to move around. 
Even touching to reposition the "I" cursor was frustrating. Its hard to reposition it into the middle of a word.
Zooming in to change the "I" cursor always zoomed me back out. Very difficult editing when you have a large para typed out.

On Yahoo search bar:
Moving the orange selector left or right on the entered search term is slow and laggy


Expected results:

Smooth movement of text selector tool and text selection.
No lags whatsoever

Also:
Why isn't the default android text selector used? Its much faster and stable.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

What device are you using? I've never noticed performance issues on my Nexus devices.

(In reply to bull500 from comment #0)
> Also:
> Why isn't the default android text selector used? Its much faster and stable.

As far as I know, we need to implement a custom text selector because Android's built-in text selection support does not work with the web content because we draw text using a canvas, not Android components.

Comment 2

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

NI capella to better respond to comment 0.

Comment 3

[bull500]

Attachment: textbox1.png

My device is moto g (2nd Gen 2014). Stock Android 5.0.2
The slowness happens after quite some time usage of the browser, its hard to reproduce it, i got it once again. But its kind of unknown whats truly causing it. I use SwiftKey keyboard, switch apps at times during Firefox usage and sometimes lock the screen with Firefox running.
I think its mostly because i've left entered text in a text/comment box, had the screen locked for some time and by the time i try to unlock & continue typing the slowness has begun. The orange selector disappers and only the "I" cursor is left. Attached pic for this.

Also the zooming out while tapping to move cursor on another portion in the viewable area of a text/comment box still exists.

Comment 4

[bull500]

Attachment: yahoo2.png

The movement issue remains in yahoo search bar though, its quite difficult to get to the left end or the right end smoothly when the search term is a bit long. Attached pictures to show this(hope it gives an idea).

Comment 5

[Mark Capella [:capella]]

mcomella's response in comment #1 sums it up nicely. The content displayed on webpages is rendered in Gecko vs a native Android/Java view. The Selection handles and the text Caret *are* native views, but their positioning and movement is coordinated by message passing between Java and our Native/c++ and JS modules via XPCOM.

We agree this is less than optimal in terms of speed, have done a lot to improve the performance of the current design over time, and are still looking for ways to improve.

We also have challenges imposed by the various keyboards in use (as you've noticed). I also prefer SwiftKey, and haven't noticed any recent major issues / regressions related to that keyboard. Have you tried switching to the Google keyboard and done comparison testing?

I understand this won't be easy until you can reliably reproduce specific errors, but further details you can provide will be helpful. I know there are some outstanding "odd" bugs in the Keyboard/IME backlog. TextSelection and Keyboard code are closely coupled, and problems in one area are often related to those in the other.

re: Your comment #4, I do see an issue where dragging the caret all the way right or left in an editable field can suddenly cause it to disappear and close the action bar. This seems like a valid complaint that I hadn't noticed before, and will look into it under this bug#.

FYI, Mozilla's FF/OS (or Boot-To-Gecko as it used to be called) recently implemented built-in Selection/Caret support tied more directly to Gecko. See bug 988143, where we're looking at replacing the current Android TextSelection logic almost entirely with new code, with the expectation that a lot of the speed issues will be solved at a lower level.

(This still won't involve native Android handles, but will cut out almost all of the associated message passing between Java <-> C++ <-> JS and localize logic to the Native C++.)

We don't have a project plan with an estimated completion date for that yet. The new code there has been available for a short time, and we're only now seriously exploring integrating the two.

Comment 6

[bull500]

(In reply to Mark Capella [:capella] from comment #5)
> mcomella's response in comment #1 sums it up nicely. The content displayed
> on webpages is rendered in Gecko vs a native Android/Java view. The
> Selection handles and the text Caret *are* native views, but their
> positioning and movement is coordinated by message passing between Java and
> our Native/c++ and JS modules via XPCOM.
> 
> We agree this is less than optimal in terms of speed, have done a lot to
> improve the performance of the current design over time, and are still
> looking for ways to improve.
> 
> We also have challenges imposed by the various keyboards in use (as you've
> noticed). I also prefer SwiftKey, and haven't noticed any recent major
> issues / regressions related to that keyboard. Have you tried switching to
> the Google keyboard and done comparison testing?
> 
> I understand this won't be easy until you can reliably reproduce specific
> errors, but further details you can provide will be helpful. I know there
> are some outstanding "odd" bugs in the Keyboard/IME backlog. TextSelection
> and Keyboard code are closely coupled, and problems in one area are often
> related to those in the other.
> 
> re: Your comment #4, I do see an issue where dragging the caret all the way
> right or left in an editable field can suddenly cause it to disappear and
> close the action bar. This seems like a valid complaint that I hadn't
> noticed before, and will look into it under this bug#.
> 
> FYI, Mozilla's FF/OS (or Boot-To-Gecko as it used to be called) recently
> implemented built-in Selection/Caret support tied more directly to Gecko.
> See bug 988143, where we're looking at replacing the current Android
> TextSelection logic almost entirely with new code, with the expectation that
> a lot of the speed issues will be solved at a lower level.
> 
> (This still won't involve native Android handles, but will cut out almost
> all of the associated message passing between Java <-> C++ <-> JS and
> localize logic to the Native C++.)
> 
> We don't have a project plan with an estimated completion date for that yet.
> The new code there has been available for a short time, and we're only now
> seriously exploring integrating the two.

Well its good to know that more improvements will be coming along the way. :D
Glad the comment #4 bug is reproducible.

I shall try simulate the slowness issue with Google keyboard and see if its turns up anything.
Also please have a look at the zooming issue in comment #3, i think its fairly reproducible as well.

Request: Can the orange text selector be given the new Lollipop shape? 
http://i-cdn.phonearena.com/images/articles/167429-image/Typing-Left---KitKat-Right---Lollipop.jpg
http://www.droid-life.com/wp-content/uploads/2015/02/cut-copy-paste-lollipop2.jpg

Comment 7

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


Specific note here, for further Android compatibility, see bug 1097398, and bug 1171110.

Comment 8

[bull500]

(In reply to Mark Capella [:capella] from comment #7)
> 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 :-)
> 
> 
> Specific note here, for further Android compatibility, see bug 1097398, and
> bug 1171110.

I think the zooming thing seems to be improved by there are issues - https://bugzilla.mozilla.org/show_bug.cgi?id=1244705  
Please do check on it!
Thank You :)