In bug 758820, I disabled the form autocomplete popup after the user starts typing. This bug is track work necessary to re-enable form autocomplete after the user starts typing. Some example problems when form autocomplete is enabled: * Most VKBs with suggestions will ignore autocomplete text when an autocomplete entry is selected mid-word. * Swype will select the current word or move the cursor when an autocomplete entry is selected mid-word.

This bug should probably be blocking-fennec1.0=.N+

I don't think I will be able to fix this bug and all its blocking bugs before Fennec 14.1. Form autocomplete is currently disabled after the user starts typing in a text input form. If we re-enable the form autocomplete popup, numerous IME-specific bugs are revealed. Swype, Hacker's Keyboard, TouchPal Keyboard, and OpenWnn Plus all have problems and they all misbehave differently. Thus, I don't think we can safely re-enable the form autocomplete popup (after the user starts typing) until ALL those IME-specific bugs are fixed. We currently display the form autocomplete popup until the user starts typing, so we are not losing a lot of functionality when we disable the popup after the user starts typing.

WIP: Commit composition string before sending autocomplete notification.

If we fix this bug in Firefox 16, we should uplift the fix for TouchPal bug 768106, too.

Blocklist form autocomplete for some IMEs: * Google Japanese Input (bug 775850) * OpenWnn Plus (bug 768108) * Simeji (bug 768108) * Swype (bug 755909) * Swype Beta (bug 755909)

Comment on attachment 644203 [details] [diff] [review] blocklist-some-IMEs.patch >diff --git a/mobile/android/base/GeckoInputConnection.java b/mobile/android/base/GeckoInputConnection.java >+ if (DEBUG && blocklisted) { >+ Log.d(LOGTAG, "FormAssist: Blocklisting \"" + mCurrentInputMethod + "\" IME"); >+ } >+ GeckoApp.mAppContext.mFormAssistPopup.block(blocklisted); Should this be null checked? I am more paranoid since we made things non-static in GeckoApp. >+ private static String getCurrentInputMethod() { >+ return Secure.getString(GeckoApp.mAppContext.getContentResolver(), >+ Secure.DEFAULT_INPUT_METHOD); Same

(In reply to Mark Finkle (:mfinkle) from comment #6) > >+ GeckoApp.mAppContext.mFormAssistPopup.block(blocklisted); > > Should this be null checked? I am more paranoid since we made things > non-static in GeckoApp. I'll null check mFormAssistPopup, but I'm concerned that we're uglifying our code because we don't have a good understanding of GeckoApp's Activity lifetime (which probably an important thing to know). :)

(In reply to Mark Finkle (:mfinkle) from comment #6) > >+ private static String getCurrentInputMethod() { > >+ return Secure.getString(GeckoApp.mAppContext.getContentResolver(), > >+ Secure.DEFAULT_INPUT_METHOD); > > Same GeckoApp initializes `mAppContext = this` in onCreate() and never resets `mAppContext = null`.

https://hg.mozilla.org/integration/mozilla-inbound/rev/b6b76a38e015 Form autocomplete popup has been re-enabled, but some IMEs are now blocklisted until their individual bugs are fixed.

(In reply to Chris Peterson (:cpeterson) from comment #7) > (In reply to Mark Finkle (:mfinkle) from comment #6) > > >+ GeckoApp.mAppContext.mFormAssistPopup.block(blocklisted); > > > > Should this be null checked? I am more paranoid since we made things > > non-static in GeckoApp. > > I'll null check mFormAssistPopup, but I'm concerned that we're uglifying our > code because we don't have a good understanding of GeckoApp's Activity > lifetime (which probably an important thing to know). :) Perhaps we could add getters instead of accessing the data members directly. The getters could new the data member if it is null.

Aurora/Beta approval?

Comment on attachment 644203 [details] [diff] [review] blocklist-some-IMEs.patch [Approval Request Comment] Bug caused by (feature/regressing bug #): User impact if declined: Form autocomplete will still be disabled once user starts typing in text field. Testing completed (on m-c, etc.): Baked on m-c for 3 days without complaints or new autocomplete bugs. Risk to taking this patch (and alternatives if risky): Some buggy IMEs break form autocomplete, but this patch blocklists those IMEs for now: Swype, Swype Beta, OpenWnn Plus, and Google Japanese Input Beta. String or UUID changes made by this patch: None

Comment on attachment 644203 [details] [diff] [review] blocklist-some-IMEs.patch Looks low risk enough to land on Aurora at this point in the cycle. Will add qawanted to verify this does what's intended.

Correct me if I'm wrong, looks like this is wont-fix on mozilla-beta 15

Thanks for fixing the status. You are correct.