この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
リンクをクリックした時等、次のページをある程度読み込むと、既存の文書はゾンビとなりますが、この状態だとbug-org 519913の修正でキーイベントが処理されずに無視されるようになってしまった、というバグです。
ゾンビ化したドキュメントにキーイベントが渡された場合、その親に処理を丸投げするように修正して解決しています。
contenteditableなノードがフォーカスを失っていてもキーボードで文字が入力できてしまう、つまり他の要素でキーボードイベントが正しく処理できない、というバグです。Bug-org 567213でEhsanが多くのケースでこの問題自体は発生しなくなる修正を入れてくれて、あまり目にすることは既に無くなっていましたが、当初の予定通り、本対応のパッチを入れました。
このパッチにより、nsEditorEventListenerがエディタにイベントを通知する前に、そのエディタが処理するべき状況かどうかを確認するようになりました。その条件は、そのエディタがそのDOM window上でフォーカスを持っている、つまり、document.activeElementで、エディタに関連する要素が返される状態でのみ文字入力を受け付けるようになりました。
この処理により、以下のようなコードは動作しなくなっていることに注意してください。
var editor = document.getElementById("editor");
var anotherElement = document.getElementById("anotherElement");
anotherElement.focus();
var keyEvent = document.createEvent("KeyEvents");
keyEvent.initKeyEvent("keypress", true, true, null, false, false,
false, false, 0, "A".charCodeAt(0));
editor.dispatchEvent(keyEvent);
今まではこのコードで、editorに"A"が入力されていましたが、今後は無視されるようになります。この挙動は(イベントの違いはありますが)WebKitと同じ挙動です(もっとも、こんな回りくどいことをテスト以外でやることは無いと思いますが)。
contenteditableなエディタのあるページでは、inputやtextareaにIMEから文字入力できない、という信じられないようなバグです。
Bug-org 389372の修正でIMEのイベントもエディタの状態を確認後に処理するようにしたので、同時に修正されています。
nsKeyboardLayoutが全然Mozillaのコーディングルールに従っていないので修正すべきというバグです。前々から懸案となっていましたが、一年間、誰も修正しておらず、他に誰も触らなさそうなので一気にクリーンナップしました(こんな時期にやるなとも言われましたが)。
この修正により、nsKeyboardLayoutは、mozilla::widget::KeyboardLayoutにクラス名が変わり、実装しているファイル名もKeyboardLayout.*に変更になっているので注意してください。
Mozillazineへの書き込みから修正できたバグです。前々から時々、かな打ちができなくなることはありましたが、再現方法や原因がまったく分かりませんでした。しかし、この書き込みで再現方法を絞り込んでくれたため、割と楽に修正することができました。ためしてみたさん、ありがとう。
原因は古いMS-IME向けに、WM_IME_STARTCOMPOSITIONが送信されていなくてもWM_IME_COMPOSITIONを処理するときに強制的にcompositionを開始していたことでした。
ATOKは、何故かWM_IME_STARTCOMPOSITIONの直前でWM_IME_COMPOSITIONを送信してきます。おそらく何らかのアプリのバグへの対応だと思うのですが、問題はこの時にAPIを使ってATOKにアクセスすると、ATOK内部のかな打ち入力モード固有の初期化処理が走りきらないまま、処理を打ち切っているような印象の振る舞いをしていることでした(ちなみに、文字パレットからの入力だとこのWM_IME_COMPOSITIONが来なかったりするのでもう要らない処理なのにリスクマネージメントから残してるだけじゃないかという感じがしますが)
今回、compositionが始まっていない状態でWM_IME_COMPOSITIONを受信した時に、次のcompositionのメッセージがWM_IME_STARTCOMPOSITIONで、なおかつその後ろにWM_IME_COMPOSITIONがWM_IME_ENDCOMPOSITIONの前に控えていれば、そのWM_IME_COMPOSITIONを無視しても同じ処理結果になるはずなので、この条件でのみそれを無視するように修正しました。
特に問題がなければbranchでの修正も申請してみます。