795230 - Use ASCII capable keyboard layout for computing charCode if current input source is an IME mode and open

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

Currently, Gecko generates key events with Japanese Kana characters, Hangul characters or some Chinese characters if the active input source is an IME mode and the mode causes composition (i.e., IME is opened).

Especially when any text editors don't have focus (i.e., IME is disabled), this behavior is odd. Uses don't feel to be using IME, but their key input cause non-ASCII character input. Actually, users cannot use some shortcut keys which are implemented by web applications. E.g., http://hackasaurus.org/en-US/goggles/

On consistency with other platforms, we should use ASCII capable keyboard layout for computing it.

The attached patch does:

1. Make TISInputSourceWrapper manage both input source and keyboard layout.
2. Make key event handlers use current input source instead of current keyboard layout.
3. Make TISInputSourceWrapper compute UCKeyboardLayout with the managing keyboard layout. This makes TISInputSourceWrapper compute charCode with the keyboard layout.
4. Make InitKeyEvent() replace inserting string with current keyboard layout's character for the key when IME is opened and neither meta nor control is pressed.

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

smichaud:

Let's take this as soon as possible due to the risk.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

Sorry for the delay.  I'm perpetually behind these days, especially since I have to deal with a lot of the HiDPI stuff.

I hope to get to this by the end of the week.

(I've actually already looked at your patch.  But I also need to test it.)

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 665812 [details] [diff] [review]
Patch

I can't find any problems with this patch.  But I don't understand it very well (Apple's Text Input Services Reference https://developer.apple.com/library/mac/#documentation/TextFonts/Reference/TextInputSourcesReference/Reference/reference.html isn't really adequate for that purpose).  And I haven't found a way to test it.

http://hackasaurus.org/en-US/goggles/ works fine for me in FF 16.0.1 and today's mozilla-central nightly, whether I've chosen the US, Hiragana or Pinyin - Simplified keyboard layout.  I also never see any difference in the output between the following two branches of the "if" statement, regardless of which keyboard layout I use:

+    if (!aKeyEvent.IsMeta() && !aKeyEvent.IsControl() && IsOpenedIMEMode()) {
+      UInt32 state =
+        nsCocoaUtils::ConvertToCarbonModifier([aNativeKeyEvent modifierFlags]);
+      PRUint32 ch = TranslateToChar(nativeKeyCode, state, kbType);
+      if (ch) {
+        insertString = ch;
+      }
+    } else {
+      // If the caller isn't sure what string will be input, let's use
+      // characters of NSEvent.
+      nsCocoaUtils::GetStringForNSString([aNativeKeyEvent characters],
+                                         insertString);
+    }

Could that be because I'm using a "standard" Apple keyboard (not a JIS keyboard)?

If possible, please find me a way to test this patch -- one that shows problems in current code that your patch fixes.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

> I also never see any difference in the output between the following
> two branches of the "if" statement, regardless of which keyboard
> layout I use:

They do differ if I press the Option key (e.g. Option-p or Option-o).
But I'm not sure that's relevant.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

I should mention that I tested on OS X 10.7.5, with the default language set to US English.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Steven Michaud from comment #3)
> http://hackasaurus.org/en-US/goggles/ works fine for me in FF 16.0.1 and
> today's mozilla-central nightly, whether I've chosen the US, Hiragana or
> Pinyin - Simplified keyboard layout.

Ah, I tested it again. But it works fine with trunk. Maybe fixed by the web app side or the keycode reimplementation fixed the bug. But anyway, we still need to fix this bug. See the charCode by the URL which I set to the "URL". The charCode of keypress event doesn't indicate ASCII character when IME overrides the keyboard layout. This is too bad for websites implementing their own shortcut keys with keypress event.

And I should explain the Kana-input mode for you. Changing keyboard layout to Hiragana isn't enough for testing Kana-input. Japanese IME typically has two input modes.

One is Roman-character input. Most people use this mode, so, this is the default settings. Japanese Hiragana characters are mapped to one or two Western character, such as 'a' -> 'あ'、'ka' -> 'か'. In this mode, the keyboard layout is JIS keyboard layout which can input all ASCII characters and similar to US keyboard layout.

The other is Kana input. You need to change this mode from preferences panel of Kotoeri. In my environment, 10.7, the setting is the left most tab's first dropdown list. I'm not sure what's dialog is used in English environment though. In this mode, almost all keys are mapped to Hiragana characters. E.g, 'a' is mapped to 'ち'、'c' is mapped to 'そ'. Kotoeri switches the keyboard layout to the Kana locked layout when you use Hiragana and the input mode is Kana input. Then, you can see Hiragana characters in keyboard viewer.

The problem is, the key events are generated by the characters with Kana-lock.

I think that the easiest way to test this is using "Changjie". You can see Chinese characters when you change to this, without any other setting changes.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oops, not "Changjie", "Cangjie". The icon is "倉".

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI: If Kotoeri's preferences dialog uses Japanese characters, the left most tab should be "入力操作". And the label for input mode is "入力方法の設定". And it's dropdown list has "ローマ字入力" and "かな入力". The former is Roman-character input mode. The latter is Kana input mode.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 665812 [details] [diff] [review]
Patch

Thanks for the information.

With your new testcase (in this bug's "URL" field) I can see the difference in behavior that your patch makes:  In current nightlies "charCode" is wrong using the Cangjie (倉頡) input method, or using Kotoeri Hiragana with its "Input style" set to "Kana typing".  This problem is fixed by your patch.

("keyCode" is correct with or without your patch.)

With my default language set to English, I find I can open an English-language Kotoeri preferences panel by doing the following:

1) Choose Hiragana in the Flags menu.
2) Click on the Flags menu again (the あ symbol) and choose "Kotoeri Preferences".
3) Click on the leftmost tab ("Operation") and change "Input style" from "Romaji typing" to "Kana typing".

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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

Thank you!

Comment 11

[Ed Morley [:emorley]]

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