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

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

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

2010年7月23日

Bug-org 573689 key events lost while page is loading 初回投稿日時: 2010年07月23日15時04分10秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010072300
リンク元: 0件
SNS: (list)

リンクをクリックした時等、次のページをある程度読み込むと、既存の文書はゾンビとなりますが、この状態だとbug-org 519913の修正でキーイベントが処理されずに無視されるようになってしまった、というバグです。

ゾンビ化したドキュメントにキーイベントが渡された場合、その親に処理を丸投げするように修正して解決しています。

Bug-org 389372 Contenteditable node is still editable without focus 初回投稿日時: 2010年07月23日15時20分04秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010072301
リンク元: 0件
SNS: (list)

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と同じ挙動です(もっとも、こんな回りくどいことをテスト以外でやることは無いと思いますが)。

Bug-org 467715 IME doesn't work correctlly in textarea when there is a div with contenteditable="true" in the same page 初回投稿日時: 2010年07月23日15時23分37秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010072302
リンク元: 0件
SNS: (list)

contenteditableなエディタのあるページでは、inputtextareaにIMEから文字入力できない、という信じられないようなバグです。

Bug-org 389372の修正でIMEのイベントもエディタの状態を確認後に処理するようにしたので、同時に修正されています。

2010年7月28日

Bug-org 574340 Cleaning up nsKeyboardLayout which doesn't use our coding style 初回投稿日時: 2010年07月28日00時15分53秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010072800
リンク元: 0件
SNS: (list)

nsKeyboardLayoutが全然Mozillaのコーディングルールに従っていないので修正すべきというバグです。前々から懸案となっていましたが、一年間、誰も修正しておらず、他に誰も触らなさそうなので一気にクリーンナップしました(こんな時期にやるなとも言われましたが)。

この修正により、nsKeyboardLayoutは、mozilla::widget::KeyboardLayoutにクラス名が変わり、実装しているファイル名もKeyboardLayout.*に変更になっているので注意してください。

2010年7月31日

Bug-org 581764 [IMM32] Sometimes ATOK failed to initialize Kana-Nyuryoku mode 初回投稿日時: 2010年07月31日12時47分23秒
最終更新日時: 2010年07月31日12時51分39秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010073100
リンク元: 0件
SNS: (list)

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_COMPOSITIONWM_IME_ENDCOMPOSITIONの前に控えていれば、そのWM_IME_COMPOSITIONを無視しても同じ処理結果になるはずなので、この条件でのみそれを無視するように修正しました。

特に問題がなければbranchでの修正も申請してみます。