1002882 - Replace sendMouseEventToWindow() method of modifying TextSelection in SelectionHandler

Status: RESOLVED INVALID

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

Description

[Mark Capella [:capella]]

Currently we move the caret position in SelectionHandler in response to "TextSelection:Move" messages which isn't as performant as it could be, and also introduces background issues ("clicking" into editable inputs actually generates selectionChange notifications, incidental element "blur" messages, etc).

We can improve this by simply modifying the selection position as we do in several other places in the code.

See original work done in bug 864582, including some rough timing tests in bug 864582 comment #5.

Comment 1

[Mark Capella [:capella]]

NOTES:

   caretPositionFromPoint() returns interesting results when applied to all point positions within a test <textarea>.

For example, using code :
   <textarea id="textArea" style="width:45px; height:55px;">This XYZZY is really long</textarea>

And examining caretPositionFromPoint() results of the Rect/array at this place in SelectionHandler.js :
   http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/SelectionHandler.js?rev=cf75dbf2383d&mark=829-829#811

We notice several things ...

With contents scrolled to top:
   image: https://www.dropbox.com/s/iz6i8e6040jp6m2/scrolledTop.png
   resulting array: https://www.dropbox.com/s/u1a0phxtenaup85/caretPosTop.png

With contents scrolled at middle:
   image: https://www.dropbox.com/s/fmc62cwyubodenz/scrolledMiddle.png
   resulting array: https://www.dropbox.com/s/abu4lwfovkwr5os/caretPosMiddle.png

With contents scrolled to bottom:
   image: https://www.dropbox.com/s/iyhpbuxk2ic10xe/scrolledBottom.png
   resulting array: https://www.dropbox.com/s/1b9maxtx2hxytae/caretPosBottom.png

The two most interesting things are:
   1) There seems to be a couple horizonatal lines of offset information appended to the top -and/or- bottom of the results array, based on where we're currently scrolled, either indicating STARTOFFSET (0's) ... or ENDOFFSET (25's in this case).

   2) Most noticeable in the scrolledBottom example, it's possible to receive an offset value indicating STARTOFFSET (0's) in the array to the right of valid text, and before the next line of valid text.


   I would think in this case of 2), where the example goes from offsets of 21's -> 0's, that we might reasonably expect caretPositionFromPoint() to return values of 21's uniformly across instead.

   Hoping further review of the original implementation bug Bug 824965 yields clues.

Comment 2

[Mark Capella [:capella]]

NOTES:

Another issue associated with moving caret position in the contents of a <textarea> by setting:
   foo.selectionStart = foo.selectionEnd = fooOffset;

the CaretPosition object returned from .caretPositionFromPoint() lacks some information provided by the ContentOffset object, notably |associateWithNext|. 

   http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsIFrame.h?rev=48070863848c&mark=1353-1356#1332

In cases where we'd like to drag/position the caret after the final character on one line (where fooElement.style.direction == "ltr"), we wind up placing it before the next character on the line below.

Comment 3

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