To get form autocomplete to work, I found I had to call .blur() on the input element before I could set its value. Perhaps there's a better solution? See bug 695444 comment 12 and bug 695444 comment 14.

Steps to reproduce: - Go to http://people.mozilla.org/~mwargers/tests/autocomplete_forms/textinput_form.html - Tap on the input, type 'abc' and submit the form - Tap on the input again - Type 'a' -> form autocomplete popup appears with 'abc' in it - Tap on the 'abc' form autocomplete entry Expected result: 'abc' is filled in the input and the virtual keyboard stays open Actual result: 'abc' is filled in the input, but the virtual keyboard is closed (I assume the focus is not there anymore on the input)

What is happening then, when you aren't calling blur()? I noticed this comment in the patch from bug 695444: + // Remove focus from the textbox to avoid some bad IME interactions + this._currentInputElement.blur(); What kinds of bad IME interactions? As a workaround, can you call this._currentInputElement.focus(); (and setSelectionRange() ) afterwards, perhaps in a timer (if needed)?

Perhaps Masayuki knows what's going on here.

(In reply to Martijn Wargers [:mw22] (QA - IRC nick: mw22) from comment #3) > What is happening then, when you aren't calling blur()? > I noticed this comment in the patch from bug 695444: > + // Remove focus from the textbox to avoid some bad IME interactions > + this._currentInputElement.blur(); > > What kinds of bad IME interactions? What we found was happening was that only part of the string we tried to set as the value would actually appear in the input box. I think I also remember the cursor would appear in unexpected places, and part of the word would be underlined, trying to use the keyboard's auto-correct suggestions.

I don't understand what you are asking me. If you need to commit composition from web content, you need to use blur() hack. If you need to commit composition from chrome, you should be able to use nsIEditorIMESupport::forceCompositionEnd() or nsIWidget::ResetInputState(). However, sounds like that the Fennec Native is dispatching wrong key events or not dispatching composition events. According to D3E, we should dispatch keydown and keyup events even during composition. However, we're not doing so now since we need to check all our internal key event handlers before fixing it, though it's in my queue. E.g., autocomplete shouldn't work with composition. It stops working by compositionstart. If it works during composition, it means that key events are fired during composition too.

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.