この日記はMozilla Japanのプロダクトへの貢献を中心に書いていますが、断り書きがある場合を除き、 オフィシャルな発表ではありません。あくまでも個人的なものです。 Mozilla Japan、Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
ちなみに、誰の日記なのかよく分からないという方はInside Mozilla Japan内の 私の自己紹介 を参照してください。
Fx10のリリース関連の情報を見ていて、ちょっと気になったので以下のようなテストをしてみました。
<style>
div {
margin-bottom: 1em;
}
table {
margin-top: 1em;
}
caption {
margin-top: 1em;
}
</style>
<div>here is a div</div>
<table>
<caption>caption</caption>
<tr><td>cell</td><tr>
</table>
これを実際に表示した場合に、<div>と<caption>間のマージンは全て相殺されて1emになると考えました。でも、どのブラウザも2emで表示されました。以下、実例。
| cell |
全て相殺されると考えたのは、以下のようなケースが頭にあったからです。
<style>
div {
margin: 1em 0;
}
</style>
<div>Here is a div</div>
<div>
<div>
Here is a nested div
</div>
</div>
当然、全てのmarginは隣接しているので相殺されて1emになります。
最初は理由がよく分からなかったんですが、仕様書の以下の文面ではっきりとしました。
The table wrapper box establishes a block formatting context.
Two margins are adjoining if and only if:
- both belong to in-flow block-level boxes that participate in the same block formatting context
つまり、<table>の外側に自動的に生成される、table wrapper boxは別のブロックコンテキストを内部に生成するので、その内側にある<caption>のマージンはその外側のマージンとは相殺されない、ということです。
すなわち、比較すべきは以下の例だったわけです。
<style>
div {
margin: 1em 0;
}
</style>
<div>Here is a div</div>
<div style="overflow: auto;">
<div>
Here is a nested div
</div>
</div>
これなら、仕様に一貫性が出てきます。以下、実例。
table wrapper boxが何故新しいブロックレベルのコンテキストを生成するようになっているのかはまだ理解できていませんが。
とりあえず、バグ報告。スパゲッティ化してるWindowsのマウスホイールのハンドリングのコードを修正したら、とりかかる予定。各ブラウザでのイベントの属性値等を見れるテストケースもあわせて添付しておいたので参考になれば。
inputイベントハンドラで、alert()を呼び出すと、そのinputイベントが未確定文字列の変更によって発生していた場合、そのウインドウ内の何もかもが再描画されなくなる(当然、alert()のダイアログも生成されているものの、描画はされない)、というバグです。
原因は、処理の高速化のために一時的に再描画処理を止めている間にinputイベントを生成してしまっているためでした。
IMEの未確定文字列がある時に発行されるinputイベントがtrustedイベントではなかった、というバグです。
FirefoxのUIに対して、前回の修正が特にregressionを引き起こさなかったのはこのバグが原因だったようです。この修正を行ったことで、UIでも未確定文字列の編集中にinputイベントが発生し、様々なリアクションが発生するようになりました。
ひとまず、問題として同時に修正しておいたのはオートコンプリートと、検索バーです。前者は、オートコンプリートのリストが、IMEの候補ウインドウを隠してしまう問題に対応するためです。後者は、読み仮名を入力した時点で検索位置が先にずれてしまい、変換後の本当に検索したい語に最初からきちんとヒットする保証が無くなってしまうためです。
他のinputイベントハンドラを一通り見てみたところ、ボタンのenabled/disabledの変更、リストのフィルターの絞り込みの実行(非同期)、他のUIへの表示のシンクロぐらいだったので、特に問題が無いと判断していますが、かなりの数だったので、判断ミスや漏れがあるかもしれません。このあたり、Nightlyのテスタの方には積極的に確認していただければと思います。
nsToolkitからも、WinUtilsに持って行けるものは持って行きました。
Windowsのwidgetのコードで各ファイルからシェアして使えるユーティリティを集めた、mozilla::widget::WinUtilsを作成しました。肥大化したnsWindowの分割には特に有用ですので、staticなメソッドを追加するときはWinUtilsにあるべきかどうかを検討するようにしてください。
今のところ無事に修正され、未確定文字列がある時でもinputイベントが発行されるようになりました。もし、これによる副作用があるサイトがあるなら今のうちに修正をお願いしないといけないので、報告をお願いします。
この修正にあわせて、英語版のMDNに、inputイベントのドキュメントを作成し、compositionupdateイベントのドキュメントにも追記を入れました。しばらく放置しておけば文面が修正されると思いますので、その後に日本語版に反映します。