Closed Bug 1235632 Opened 5 years ago Closed 5 years ago

Selection handles in edit boxes do not reflect actual cursor position

Categories

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

ARM
Android
defect
Not set
normal

Tracking

(firefox46 affected)

RESOLVED DUPLICATE of bug 1241558
Tracking Status
firefox46 --- affected

People

(Reporter: gcp, Unassigned)

References

Details

Attachments

(1 file)

1) Go to reddit.com, to some subreddit, say r/firefox. Wait, no, don't do that. Try https://www.reddit.com/r/puppies instead.
2) Find a cute puppy.
3) Click the comments link.
4) Start explaining how cute the puppy is.
5) Click in the txet you already wrote to corract a spelling error. See cursor move. 
6) Start typing.

Expected result:

New text appears at cursor position.

Actual result:

New text appears at the end of the line.

For extra fun, try zooming the webpage and see the cursor fly off the page.
I am using SwiftKey FWIW.
It looks like if there's an active composition in the editable, and you tap into a different part of the same editable, we commit the composition, re-position the caret.

Then the next key typed first re-positions the caret back to the end of the previous composition commit text first, and inserts the char at that point.

[0] https://www.dropbox.com/s/oib80kcgmi9g5fc/bug_1235632_cursorJump.mp4?dl=0
Bisecting points out the regression is caused by changeset: 274598:cc0dde3ac2a8, the most-awesome bug 1206872, that enabled C++ APZ in Fennec nightly builds.

It's probable the issue is in the new code path (introduced prior to APZ but not enabled until this patch), for "Gesture:SingleTap" ... Bug 1223296.
Attached file debugLog.txt
I'm concerned with the timing here [0] (though it may not be this particular issue).

It seems the "Gesture:SingleTap" is sent to mobile/../browser.js [1] before or concurrently with the actual mouse events triggered [2] to:
  ) move/update the mouse position
  ) update FocusManager focus
  ) update Text Selection
  ) .. etc.

(See attached log, above)

Work done in browser seems to expect the mouse has already been positioned ... results returned from FocusManager via BrowserApp.getFocusedInput() for example may not be correct.

?ni to kats ... maybe I'm wrong, but I think I'll check, as I'm also watching bug 1233272, and bug 1233056.


[0] http://mxr.mozilla.org/mozilla-central/source/widget/android/AndroidContentController.cpp?rev=44c953535f7a&mark=80-81,84-84#53
[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js?rev=fe8054f2ac3e#4911
[2] http://mxr.mozilla.org/mozilla-central/source/gfx/layers/apz/util/APZCCallbackHelper.cpp?rev=1521ec5f317e&mark=581-583#571
Flags: needinfo?(bugmail.mozilla)
Cancelling ?ni after reading a little closer.
Flags: needinfo?(bugmail.mozilla)
(In reply to Mark Capella [:capella] from comment #3)
> Bisecting points out the regression is caused by changeset:
> 274598:cc0dde3ac2a8, the most-awesome bug 1206872, that enabled C++ APZ in
> Fennec nightly builds.
...
>For extra fun, try zooming the webpage and see the cursor fly off the page.

It sounds like the last part (zoom) might be worthy of a separate bug? Doesn't sound like it is related to the causes for the other problem that you've identified so far.
Sounds fair... see: bug 1236434
Duplicate of this bug: 1231162
All remaining work being done under IME/Keyboard bug 1241558
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1241558
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.