934470 - Cursor pin disappears on drag in textarea input

Status: VERIFIED FIXED

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

Description

[Konstantine Rybnikov]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131028113308

Steps to reproduce:

I put some text inside textarea. Then pressed on some point in text, and tried to move orange ping (text cursor).


Actual results:

Pin disappeared.


Expected results:

Pin should move with my finger to point to another text location.

Comment 1

[Aaron Train [:aaronmt]]

This is reproducible on all channels. I don't think it's a regression but this should be worth tracking. Reproducible with a simple test-case (see URL, focus the field and attempt to drag the cursor).

Comment 2

[(inactive) Jim Chen [:jchen] [:darchons]]

Reproducible for me as well, but I'm not familiar with the text selection handle code.

Comment 3

[Mark Capella [:capella]]

I'm not seeing the issue on my GS3 with the jellybean keyboard, though on quick glance I see the SwiftKey Beta keyboard auto updating text in ways that discontinue display of our caret. (Swiftkey uses an aggressive text update approach).

This behaviour is fixed with bug 927882, an a quick local test on my N7 confirms.

Let me know if you still see something different.

Comment 5

[Konstantine Rybnikov]

Sorry, but I experience this problem on my Nexus 7 tablet without any additional keyboard installed (on the stock one). When I move the pin it disappears and cursor moves into beginning position of textarea. I believe it's not a duplicate.

Comment 6

[Aaron Train [:aaronmt]]

It will be fixed as part of the patches in bug 927882 is what Mark in comment #3 is referring to. Perhaps Mark can provide you with a try-build with the patches included for you to try out.

Comment 7

[Mark Capella [:capella]]

FYI I'm still looking at this ... testing with N7, the Jellybean keyboard, the Google keyboard, and the Swiftkey board.

In Release I don't see that any of the keybaords are able to manage dragging the caret. I see incredibly slow responses.

For Beta, Aurora, and Nightly I see Jellybean keyboard works fine.

For Beta, Swiftkey doesn't show this problem, but Google does.

For Aurora and Nightly, both the Google and Swiftkey boards exhibit this problem.

Comment 8

[Mark Capella [:capella]]

Attachment: bug934470 (v0)

I think this is different enough from bug 927882 that I want to handle it seperately, and first.

For this bug, I think we're seeing a new source of "compositionend" messages, that is causing us to dismiss the cursor / caret tracking code prematurely (while we're in movement).

( my best guess is this change: https://hg.mozilla.org/mozilla-central/rev/f0760ef9e0bc )

We now see events that we didn't previously, which we are actually triggering back to ourselves.

This patch ignores "compositionend" messages during on-the-fly caret movement, to restore utility.

I've tested it locally on a GS3 and an N7, using Samsung, Jellybean, Swift, and Google keyboards.

Comment 9

[Mark Capella [:capella]]

For those playing at home:
https://tbpl.mozilla.org/?tree=Try&rev=4bd9b5423a90

Comment 10

[:Margaret Leibovic]

Comment on attachment 831351 [details] [diff] [review]
bug934470 (v0)

Review of attachment 831351 [details] [diff] [review]:
-----------------------------------------------------------------

Apologies for the slow review! This seems reasonable to me.

::: mobile/android/chrome/content/SelectionHandler.js
@@ +167,5 @@
>  
>        case "compositionend":
>          if (this._activeType == this.TYPE_CURSOR) {
> +          // Ignore IMM composition notifications during caret movements
> +          if (this._ignoreCompositionChanges)

Nit: I would just turn the if statement above into if `(this._activeType == this.TYPE_CURSOR && !this._ignoreCompositionChanges)`

Comment 11

[Mark Capella [:capella]]

Done! and done :)

https://hg.mozilla.org/integration/fx-team/rev/3a3718b3b441

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3a3718b3b441

Comment 13

[:Margaret Leibovic]

Comment on attachment 831351 [details] [diff] [review]
bug934470 (v0)

Sadly, we should have tried to uplift this for 26 but missed the boat. I made a beta build with this patch applied and it fixes the big problems described in bug 943944.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): uncertain which bug caused this, but it's an issue introduced in 26
User impact if declined: you can't drag the cursor in inputs/textareas
Testing completed (on m-c, etc.): landed on m-c 11/19
Risk to taking this patch (and alternatives if risky): low-risk, baked for a while on nightly/aurora, can only make things better than the currently (totally busted) state
String or IDL/UUID changes made by this patch: none

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 831351 [details] [diff] [review]
bug934470 (v0)

not sure what it means on your end that this is tracking 26+ since that has already shipped, but go ahead with uplift to 27 beta.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/576b38a5c2c7

Comment 17

[Paul Feher]

Verified on Firefox for Android 27 Beta 8 and latest Aurora (2014-01-22). 
Device:LG Optimus 4X (Android 4.1.2)