Closed Bug 934470 Opened 6 years ago Closed 6 years ago

Cursor pin disappears on drag in textarea input


(Firefox for Android :: Text Selection, defect)

Not set



Firefox 28
Tracking Status
firefox26 --- wontfix
firefox27 --- verified
firefox28 --- verified
firefox29 --- verified
fennec 26+ ---


(Reporter: kost-bebix, Assigned: capella)




(Keywords: reproducible, testcase)


(1 file)

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.
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).
tracking-fennec: --- → ?
Component: General → Keyboards and IME
Ever confirmed: true
OS: Linux → Android
Hardware: x86_64 → ARM
Version: Firefox 27 → Trunk
Summary: Cursor pin disappears on dragging on textarea input → Cursor pin disappears on drag in textarea input
Reproducible for me as well, but I'm not familiar with the text selection handle code.
Component: Keyboards and IME → Text Selection
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.
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 927882
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.
Resolution: DUPLICATE → ---
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.
Closed: 6 years ago6 years ago
Flags: needinfo?(markcapella)
Resolution: --- → DUPLICATE
Duplicate of bug: 927882
tracking-fennec: ? → ---
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.
Flags: needinfo?(markcapella)
Attached patch bug934470 (v0)Splinter Review
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: )

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.
Assignee: nobody → markcapella
Attachment #831351 - Flags: review?(margaret.leibovic)
Resolution: DUPLICATE → ---
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)`
Attachment #831351 - Flags: review?(margaret.leibovic) → review+
Keywords: verifyme
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
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
Attachment #831351 - Flags: approval-mozilla-beta?
tracking-fennec: --- → 26+
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.
Attachment #831351 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Duplicate of this bug: 943944
Flags: needinfo?(aaron.train)
Flags: needinfo?(aaron.train)
Keywords: verifyme
Verified on Firefox for Android 27 Beta 8 and latest Aurora (2014-01-22). 
Device:LG Optimus 4X (Android 4.1.2)
You need to log in before you can comment on or make changes to this bug.