Closed Bug 856155 Opened 11 years ago Closed 11 years ago

Unable to change the value of a focused input field

Categories

(Firefox for Android Graveyard :: Keyboards and IME, defect)

ARM
Android
defect
Not set
normal

Tracking

(fennec23+)

RESOLVED FIXED
Firefox 23
Tracking Status
fennec 23+ ---

People

(Reporter: rshearer, Assigned: kats)

References

()

Details

Attachments

(1 file)

You can't change the value of an input field while it has focus. Setting the value clears the input field instead.

Example: http://jsfiddle.net/xyLJB/3/ . This example listens for 'touchstart' on a target and then changes the value of an input field.

Steps to reproduce:
1. Open that URL on Firefox for Android. You can use the embedded URL http://jsfiddle.net/xyLJB/3/embedded/result/ to make it easier.
2. Type something into the input field.
3. Tap on the box with the red border.

Expected results: The value of the input field is set to "changed!"

Actual results: The input field is cleared.

Tested on Firefox Nightly for Android on Galaxy Nexus 4.2.2. This works as expected on Chrome for Android.
I cannot reproduce this issue on Galaxy Nexus (Android 4.2.2) using the latest Nightly build 22.0a1 (2013-04-01) 

Can you please re-check using the latest nightly: ftp://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-android/
I still see this issue on the latest Nightly build 23.0a1 .

Here are some clarifications to the repro steps:
- As you type something into the Android keyboard it will make suggestions along the top.  If you select one of these and then tap the red box, the example will work (i.e. the bug does not repro).
- If you try to then alter the word changed by adding or deleting characters the bug does not repro.
- If you tap elsewhere on the screen to shift position or zoom before you tap the red box, the example will also not repro.

- But if you start out just typing some letters and then directly tap the red box, the bug repros and the example will fail.

So clearer steps to reproduce are:
1. Open the URL I provided.
2. Without putting focus in the input field, zoom in so both the input field and the box are large enough to perform steps 3-5.
3. Tap on the input field. The Android IME should pop up.
4. Type "r"
5. Without doing anything else, tap the red box.

(In reply to Catalin Suciu from comment #1)
> I cannot reproduce this issue on Galaxy Nexus (Android 4.2.2) using the
> latest Nightly build 22.0a1 (2013-04-01) 
> 
> Can you please re-check using the latest nightly:
> ftp://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-
> android/
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
Jim, when I perform the steps in comment 2, I get the logcat output below. I also stuck a breakpoint in AndroidBridge::NotifyIMEChange and the values passed in there are aText="", aTextLen=0, aStart=0, aEnd=4, aNewEnd=0 which seems wrong to me. (I'm guessing aEnd=4 reflects the length of the string I put into the text field before tapping the red box). Any idea what's happening here?

04-03 00:23:14.330 I/Gecko   (19884): void mozilla::AndroidBridge::HandleGeckoMessage(const nsAString_internal&, nsAString_internal&)
04-03 00:23:14.330 I/GeckoSubdocumentScrollHelper(19884): Got message: Panning:Override
04-03 00:23:14.330 I/Gecko   (19884): leaving void mozilla::AndroidBridge::HandleGeckoMessage(const nsAString_internal&, nsAString_internal&)
04-03 00:23:14.380 I/Gecko   (19884): ###!!! ASSERTION: Cannot Collapse: 'NS_SUCCEEDED(result)', file /Users/kats/zspace/mozilla-git/editor/libeditor/base/IMETextTxn.cpp, line 303
04-03 00:23:14.380 I/Gecko   (19884): ###!!! ASSERTION: Cannot Collapse: 'NS_SUCCEEDED(result)', file /Users/kats/zspace/mozilla-git/editor/libeditor/base/IMETextTxn.cpp, line 360
04-03 00:23:14.380 I/Gecko   (19884): AndroidBridge::NotifyIMEChange
04-03 00:23:14.380 E/SpannableStringBuilder(19884): SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length
04-03 00:23:14.380 E/SpannableStringBuilder(19884): SPAN_EXCLUSIVE_EXCLUSIVE spans cannot have a zero length
04-03 00:23:14.380 I/Gecko   (19884): AndroidBridge::NotifyIMEChange
04-03 00:23:14.700 I/Gecko   (19884): ###!!! ASSERTION: Cannot Collapse: 'NS_SUCCEEDED(result)', file /Users/kats/zspace/mozilla-git/editor/libeditor/base/IMETextTxn.cpp, line 360
04-03 00:23:14.710 I/Gecko   (19884): void mozilla::AndroidBridge::HandleGeckoMessage(const nsAString_internal&, nsAString_internal&)
04-03 00:23:14.710 I/Gecko   (19884): leaving void mozilla::AndroidBridge::HandleGeckoMessage(const nsAString_internal&, nsAString_internal&)
04-03 00:23:14.710 I/Gecko   (19884): AndroidBridge::NotifyIME
04-03 00:23:14.710 I/Gecko   (19884): AndroidBridge::NotifyIME
04-03 00:23:14.751 I/Gecko   (19884): void mozilla::AndroidBridge::HandleGeckoMessage(const nsAString_internal&, nsAString_internal&)
04-03 00:23:14.751 I/Gecko   (19884): leaving void mozilla::AndroidBridge::HandleGeckoMessage(const nsAString_internal&, nsAString_internal&)
04-03 00:23:14.761 I/Gecko   (19884): AndroidBridge::NotifyIMEContext
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #3)
> Jim, when I perform the steps in comment 2, I get the logcat output below. I
> also stuck a breakpoint in AndroidBridge::NotifyIMEChange and the values
> passed in there are aText="", aTextLen=0, aStart=0, aEnd=4, aNewEnd=0 which
> seems wrong to me. (I'm guessing aEnd=4 reflects the length of the string I
> put into the text field before tapping the red box). Any idea what's
> happening here?

Right, aEnd=4, aNewEnd=0 is expected because the text field is (incorrectly) cleared. This looks like an underlying issue in Gecko, but I think there is an acceptable workaround:

At the beginning of the touch event handler, we can call nsWindow::RemoveIMEComposition(). That should avoid the asserting code path above. We already do the same thing for key events here, http://mxr.mozilla.org/mozilla-central/source/widget/android/nsWindow.cpp#1598.

I'm not familiar enough with touch events to know where's the best place to put that call, but if you want to put together a patch, I'd be happy to review it!
The start of nsWindow::OnMultitouchEvent would be the equivalent spot to put that call. I don't think I'll be able to try this out today but I can get to it tomorrow if you don't do it before then.
Attached patch PatchSplinter Review
Indeed, this seems to do the trick!
Assignee: nobody → bugmail.mozilla
Attachment #733068 - Flags: review?(nchen)
Comment on attachment 733068 [details] [diff] [review]
Patch

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

Thanks!

I think a comment mentioning this bug would be good.
Attachment #733068 - Flags: review?(nchen) → review+
tracking-fennec: ? → 23+
https://hg.mozilla.org/mozilla-central/rev/b50cc6512288
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 23
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: