715207 - First character entered in any input field with Google Japanese Input is prevalidated

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect, P3)

Description

[Mike Hommey [:glandium]]

The way the Google Japanese Input works (and most other Japanese IMEs, but i don't think i've had such problems with e.g. Simeji or Openwnn) is that you first type kanas and switch a set of a few characters into the appropriate combination of kanji/hiragana/katakana. So when you type a few characters, they are all selected to be converted together. There are also predictive results but that doesn't really matter for the current problem.

Not sure how to best describe the issue. The problem in itself is that when first starting to type in an input field, instead of all characters being selected, the first is left out as if it had been validated by itself to stay as hiragana, and the remaining ones are selected. Hope it's clear enough.

Comment 1

[Alex Pakhotin (:alexp)]

Mike, I'm not really familiar with Japanese input, can you please upload a video, which illustrates the problem? Ideally - two videos: for the incorrect behavior and expected result (though even just the first one would help).
Thanks.

Comment 2

[Mike Hommey [:glandium]]

Attachment: Typing あ for the first time

So, assuming you start typing あか, what you see first is this, after a brief moment where the あ is highlighted.

Comment 3

[Mike Hommey [:glandium]]

Attachment: Typing か

After typing the あ, typing a か highlights the か alone. Subsequently typed characters are also highlighted. The highlighted characters are those used for predictive and conversion engine, which result is shown above the virtual keyboard.

Comment 4

[Mike Hommey [:glandium]]

Attachment: Typing あ again

After you try a first, if you hit backspace and start over, the normally expected behavior happens: あ is highlighted.

Comment 5

[Mike Hommey [:glandium]]

Attachment: Typing か again

After typing か again, both characters are hightlighted, as expected.

Comment 6

[Alex Pakhotin (:alexp)]

Do I understand correctly? Is this incorrect behavior in the AwesomeBar only? An edit box on a web page seems to show predictions like when both characters are used, except they are not highlighted. Is the latter behavior on the web pages better?

Comment 7

[Mike Hommey [:glandium]]

I'll restate what I said on IRC yesterday. This apparently happens in the awesomebar only, and is not a regression: FF9 has the same problem. Input fields in web content however work properly for the prediction and conversion data, but they don't show any highlight.

Comment 8

[Makoto Kato [:m_kato]]

I think that this is a regression by bug 710843.  This bug's fix reset IME on updateGoButton().  Don't call imm.resetInput() during inputing by IME.

Comment 11

[Makoto Kato [:m_kato]]

Attachment: fix

Comment 12

[Makoto Kato [:m_kato]]

Comment on attachment 604311 [details] [diff] [review]
fix

If having composition string on Awesome bar, doesn't update Go/Search button.

Comment 13

[Makoto Kato [:m_kato]]

Attachment: fix v1.1

whitespace fix

Comment 14

[Chris Peterson [:cpeterson]]

Comment on attachment 604313 [details] [diff] [review]
fix v1.1

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

r+ with these minor changes.

::: mobile/android/base/AwesomeBar.java
@@ +200,5 @@
> +                mAwesomeTabs.filter(text);
> +
> +                // If awesome bar has composing string, don't call
> +                // updateGoButton().
> +                // Since that method resets IME, compositing state will be

* Did you mean "composing state", not "compositing state"?
* Also, you don't need to wrap the comments at column 80. We follow Google/Android's Java conventions and wrap at column 100.

@@ +204,5 @@
> +                // Since that method resets IME, compositing state will be
> +                // broken.
> +                Object[] span = s.getSpans(0, s.length(), Object.class);
> +                if (span != null) {
> +                    for (int i = 0; i < span.length; i++) {

I would suggest:
* renaming |Object[] span| to |Object[] spans| (plural)
* and replacing the for loop with a for-each loop like |for (Object span : spans)|.

Comment 15

[Makoto Kato [:m_kato]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c77b00ff2c80

Comment 16

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/c77b00ff2c80