もずはっく日記(2010年6月)

Bug 6445 [Win] ATOKでIMEをオンにした直後に文字を入力しようとすると文字がIMEを通さずにダイレクトに入力されることがある
初回投稿日時: 2010年06月02日13時38分25秒
カテゴリ: Mozilla Core バグ修正
SNS: Tweet (list)

個人的には、悲願だったこのバグ修正にようやく成功しました。

ATOKを半角/全角キーのみでオンにしようとすると、

1. WM_KEYUP VK_OEM_AUTO
2. WM_KEYDOWN VK_PROCESSKEY
3. WM_IME_NOTIFY IMN_PRIVATE
4. WM_IME_NOTIFY IMN_PRIVATE
5. WM_IME_NOTIFY IMN_PRIVATE
6. WM_IME_NOTIFY IMN_SETOPENSTATUS
7. WM_KEYDOWN VK_PROCESSKEY...
8. WM_IME_STARTCOMPOSITION

というメッセージの順序で通常は処理されます。ところが、ATOKの起動がディスクスワップ等で遅れると、次に入力したキーが割り込んできて以下のようになります。

1. WM_KEYUP VK_OEM_AUTO
2. WM_KEYDOWN VK_PROCESSKEY
3. WM_IME_NOTIFY IMN_PRIVATE
4. WM_KEYDOWN VK_A
5. WM_CHAR 'a'
6. WM_KEYUP VK_A
7. WM_IME_NOTIFY IMN_PRIVATE
8. WM_IME_NOTIFY IMN_PRIVATE
9. WM_IME_NOTIFY IMN_SETOPENSTATUS

ところが、この現象は普通のアプリでは一切再現しません。Geckoは入力のレスポンス速度を上げるために、キー、IME、マウスのメッセージを優先的に処理しようとするように、メッセージの取得部分が最適化されています。これを無効化すると再現しなくなったので、対応策をずっと考えていました。

つい最近、別のバグで検証している時に初めてVK_PROCESSKEYの存在を知ったのが突破口になりました。IMEを通した入力があった場合、IMEが処理済みのWM_KEYDOWNメッセージにはキーコードにこれが設定されています。つまり、このメッセージが来た場合、通常ならIMEはオンのはずです。しかし、このバグはIMEがオフの間にキーイベントが取り出されるのが問題だったわけです。実際に検証してみると、VK_PROCESSKEYのメッセージが来たときはまだ、ImmGetOpenStatus()はFALSEを返してきました。

このことから、VK_PROCESSKEYのWM_KEYDOWNを処理する時にIMEがオフのままならATOKの開き始めであると仮定し、WM_IME_NOTIFYでIMN_SETOPENSTATUSが来るまでの間、最適化を一時的に中断するようにしました。

ただ、他のIMEがオフの時にVK_PROCESSKEYを送信してこないとも限らないので、想定してないメッセージを受け取った時には最適化処理を再開するようにしています(ここがやや甘い感じもありますので、ご意見があればbugzilla-jpにでもよろしくお願いします)。

この修正により、メモリが少ない環境や、HDDが遅い環境(私の場合、こちらで、なんとHDDの回転数が4200rpm!)のATOKユーザはかなり快適になると思います。