この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

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

2010年6月2日

Bug 6445 [Win] ATOKでIMEをオンにした直後に文字を入力しようとすると文字がIMEを通さずにダイレクトに入力されることがある
初回投稿日時: 2010年06月02日13時38分25秒
カテゴリ: Mozilla Core バグ修正
SNS: (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_PROCESSKEYWM_KEYDOWNを処理する時にIMEがオフのままならATOKの開き始めであると仮定し、WM_IME_NOTIFYIMN_SETOPENSTATUSが来るまでの間、最適化を一時的に中断するようにしました。

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

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

関連するかもしれないエントリ

bug 6445を含むエントリ

このエントリへのリンク元