466487 - ATOK (Japanese IME) fails to eat key message

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

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

Attachment: Patch v1.0

I'm using ATOK which is Japanese IME of a third party. When I turn on the IME and type keys for Japanese text inputting, sometimes (in most cases, the system resource is busy) the first key inputs ASCII character directly (not via IME). I checked message queue of the both cases (normal case, and failure case). On normal case, the first key doesn't input text directly, so, there are not WM_KEYDOWN/WM_KEYUP/WM_CHAR messages for the key. Instead of them, there are only IME related messages.

Maybe, ATOK eats the key messages when IME is opened. However, we eat the messages earlier than ATOK. We give priority to key messages, IME messages and mouse messages. So, this hack is bad for some middle wares, probably.

I think we should not use such hack. However, I suggest the following patch which doesn't give priority to the key/IME messages when the keyboard local is Japanese. This is safer, and this doesn't regress the response performance for other locales.

Comment 1

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

https://build.mozilla.org/tryserver-builds/2008-11-24_18:[e-mail]-attachment349761 [review]/

test build.

Comment 2

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

Attachment: Patch v2.0

Kimura-san hate my previous patch. Because that may hide some bugs/regressions from non-Japanese locale users. I agree to it. I hope the cause of this bug will be removed completely.

Comment 3

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

Attachment: Patch v2.0

oops, sorry, I posted another bug's patch.

Comment 4

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

test build:
https://build.mozilla.org/tryserver-builds/2008-11-26_00:[e-mail]-attachment350117 [review]/

Comment 5

[Ere Maijala (slow)]

Comment on attachment 350117 [details] [diff] [review]
Patch v2.0

Ewww, this is scary ad we've been here before. Unless this patch has been extensively tested and something else had changed in the mean time, this change would cause trouble. As far as I remember, this change would kill responsiveness at least in case of a some Flash applets but there was probably more.

Comment 6

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

Ere:

What problems were there? The result of my patch should be same as standard win32 applications. The cause of the problem is really here??

Comment 7

[Ere Maijala (slow)]

At least bug 378830.

Comment 8

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

Attachment: Patch v3.0

This is an experimental patch. This patch tries to prevent the optimization only when IME is opening.

Comment 9

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

Attachment: Patch v3.1

fix a nit.

Comment 10

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

Attachment: Patch v4.0

better approach.

Comment 11

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

Comment on attachment 447743 [details] [diff] [review]
Patch v4.0

Ah, this is wrong. The wParam isn't VK_PROCESSKEY here.

Comment 12

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

Attachment: Patch v5.0

This works fine for me.

When I press 全角/半角 key (with ATOK, and it's closed) and press 'A', in most cases, the messages are received as following order:

WM_KEYUP VK_OEM_AUTO
WM_KEYDOWN VK_PROCESSKEY
WM_IME_NOTIFY IMN_PRIVATE
WM_IME_NOTIFY IMN_PRIVATE
WM_IME_NOTIFY IMN_PRIVATE
WM_IME_NOTIFY IMN_SETOPENSTATUS
WM_KEYDOWN VK_PROCESSKEY...
WM_IME_STARTCOMPOSITION

However, if system is busy, sometimes the messages are received as following order:

WM_KEYUP VK_OEM_AUTO
WM_KEYDOWN VK_PROCESSKEY
WM_IME_NOTIFY IMN_PRIVATE
WM_KEYDOWN VK_A
WM_CHAR 'a'
WM_KEYUP VK_A
WM_IME_NOTIFY IMN_PRIVATE
WM_IME_NOTIFY IMN_PRIVATE
WM_IME_NOTIFY IMN_SETOPENSTATUS

So, when ATOK works slowly, the 'A' key messages are sent during ATOK being opening. Therefore, if we can prevent the key/IME message order optimization during IME being opening, we can fix this bug.

We can know the start timing by the first WM_KEYDOWN with VK_PROCESSKEY. If the message comes when IME has been closed (i.e., ImmGetOpenStatus() returns FALSE), the key message should be a trigger of opening IME because the message should be received only when IME has been opened.

And we can know the end timing by the WM_IME_NOTIFY with IMN_SETOPENSTATUS. And also, if we receives unexpected IME related messages and non-IME processed key message, we can see the WM_KEYDOWN with VK_PROCESSKEY was sent for unknown purpose. So, when these messages are received, we should restart the message order optimization.

Comment 13

[Jim Mathies [:jimm]]

Comment on attachment 447981 [details] [diff] [review]
Patch v5.0

I can't manually test this myself, but I assume you've worked it through.

Comment 14

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

Thank you, Jim. This patch is a little tricky. I believe this approach is safest. Even if another IME sends WM_KEYDOWN with WM_PROCESSKEY when it's not opened, this patch stops only the optimizing, doesn't change the behavior. And this patch is sensitive for the unexpected IME messages. So, with such IMEs, this patch restarts the optimization immediately.

The worst story is, if another application (non-IME) sends WM_KEYDOWN with WM_PROCESSKEY to our window, we stop optimization fortunately on non-IME users. However, there are not such needs.

I'll land this tomorrow.

Comment 15

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

Attachment: Patch v5.0.1

fix the switch-case indentation for the new coding style.

Comment 16

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

http://hg.mozilla.org/mozilla-central/rev/5e3e8590b6e5