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

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

もずはっく日記(2012年1月)

2012年1月10日

Bug-org 713502 input event should be fired after compositionupdate #2 初回投稿日時: 2012年01月10日12時07分30秒
カテゴリ: Javascript Mozilla Core Mozilla12 バグ修正
固定リンク: id=2012011000
SNS: (list)

今のところ無事に修正され、未確定文字列がある時でもinputイベントが発行されるようになりました。もし、これによる副作用があるサイトがあるなら今のうちに修正をお願いしないといけないので、報告をお願いします。

この修正にあわせて、英語版のMDNに、inputイベントのドキュメントを作成し、compositionupdateイベントのドキュメントにも追記を入れました。しばらく放置しておけば文面が修正されると思いますので、その後に日本語版に反映します。

Bug-org 712483 Make WinUtils 初回投稿日時: 2012年01月10日12時19分18秒
カテゴリ: Mozilla Core Mozilla12 バグ修正
固定リンク: id=2012011001
SNS: (list)

Windowsのwidgetのコードで各ファイルからシェアして使えるユーティリティを集めた、mozilla::widget::WinUtilsを作成しました。肥大化したnsWindowの分割には特に有用ですので、staticなメソッドを追加するときはWinUtilsにあるべきかどうかを検討するようにしてください。

2012年1月12日

2012年1月16日

Bug-org 717147 input events during composition are not trusted events 初回投稿日時: 2012年01月16日16時00分36秒
カテゴリ: Firefox Javascript Mozilla Core Mozilla12 Thunderbird バグ修正
固定リンク: id=2012011600
SNS: (list)

IMEの未確定文字列がある時に発行されるinputイベントがtrustedイベントではなかった、というバグです。

FirefoxのUIに対して、前回の修正が特にregressionを引き起こさなかったのはこのバグが原因だったようです。この修正を行ったことで、UIでも未確定文字列の編集中にinputイベントが発生し、様々なリアクションが発生するようになりました。

ひとまず、問題として同時に修正しておいたのはオートコンプリートと、検索バーです。前者は、オートコンプリートのリストが、IMEの候補ウインドウを隠してしまう問題に対応するためです。後者は、読み仮名を入力した時点で検索位置が先にずれてしまい、変換後の本当に検索したい語に最初からきちんとヒットする保証が無くなってしまうためです。

他のinputイベントハンドラを一通り見てみたところ、ボタンのenabled/disabledの変更、リストのフィルターの絞り込みの実行(非同期)、他のUIへの表示のシンクロぐらいだったので、特に問題が無いと判断していますが、かなりの数だったので、判断ミスや漏れがあるかもしれません。このあたり、Nightlyのテスタの方には積極的に確認していただければと思います。

Bug-org 717560 If input event handler shows alert dialog during composition, Fx stops painting everything 初回投稿日時: 2012年01月16日16時04分26秒
カテゴリ: Firefox Javascript Mozilla Core Mozilla12 バグ修正
固定リンク: id=2012011601
SNS: (list)

inputイベントハンドラで、alert()を呼び出すと、そのinputイベントが未確定文字列の変更によって発生していた場合、そのウインドウ内の何もかもが再描画されなくなる(当然、alert()のダイアログも生成されているものの、描画はされない)、というバグです。

原因は、処理の高速化のために一時的に再描画処理を止めている間にinputイベントを生成してしまっているためでした。

2012年1月19日

Bug-org 719320 Implement DOM3 wheel event 初回投稿日時: 2012年01月19日13時07分32秒
カテゴリ: Javascript Mozilla Core バグ報告
固定リンク: id=2012011900
SNS: (list)

とりあえず、バグ報告。スパゲッティ化してるWindowsのマウスホイールのハンドリングのコードを修正したら、とりかかる予定。各ブラウザでのイベントの属性値等を見れるテストケースもあわせて添付しておいたので参考になれば

2012年1月27日

<table>と<caption>のマージンの相殺 初回投稿日時: 2012年01月27日19時10分49秒
最終更新日時: 2012年01月27日19時23分36秒
カテゴリ: CSS
固定リンク: id=2012012700
SNS: (list)

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で表示されました。以下、実例。

Here is a div
caption
cell

全て相殺されると考えたのは、以下のようなケースが頭にあったからです。

<style>
div {
  margin: 1em 0;
}
</style>

<div>Here is a div</div>

<div>
  <div>
    Here is a nested div
  </div>
</div>

当然、全てのmarginは隣接しているので相殺されて1emになります。

Here is a div
Here is a nested div

最初は理由がよく分からなかったんですが、仕様書の以下の文面ではっきりとしました。

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>

これなら、仕様に一貫性が出てきます。以下、実例。

Here is a div
Here is a nested div

table wrapper boxが何故新しいブロックレベルのコンテキストを生成するようになっているのかはまだ理解できていませんが。

2012年1月31日

Bug-org 692145 Firefox Crash [@ nsTextFragment::CharAt(int) ] 初回投稿日時: 2012年01月31日17時19分04秒
最終更新日時: 2012年01月31日17時50分40秒
カテゴリ: Firefox Mozilla Core Mozilla12 Thunderbird バグ修正
固定リンク: id=2012013100
SNS: (list)

週末に、クラッシュだけを抑えるパッチのレビュー依頼が来ていて、初めて気付いた重大なバグです。影響があるのはWindows版のFirefox 7から、Firefox 11までと、Firefox 10ベースでリリースされるESRです。現在のところ、Firefox 12には滑り込みで間に合いました。明日以降にドライバに連絡とってみますが、他のバージョンで修正が許可されるかは今のところ不明なバグです。

このバグは、bug-org 665858の修正のregressionです。Bug-org 665858は、IMEがキャレットの位置等を問い合わせて来た場合のパフォーマンスが、大きな内容を持つエディタ上では異様に遅くなる、というパフォーマンスに関するバグで、その原因は内容をプレーンテキスト化した時の長さを求める処理にありました。当初の実装では、コードのシンプルさのために問い合わせられた内容を実際にプレーンテキスト化してから改行コードの置換処理(\nから\r\n)を行い、文字列の長さを取得するというもので、この置換が遅かったのです。このため、この時の修正では実際にプレーンテキストを生成せずに改行文字の数をカウントして算出するという方法に変更されました。

ですが、このカウントするコードに問題があり、文字列のどの範囲でカウントするのか、という長さを指定するパラメータが、\n時の文字数で受け取ることを前提としているにも関わらず、呼び出し側がここに\r\n時の文字数を渡しているバグがありました。このため、行数が多い文章を書いている時に、エディタの最後で未確定文字列を入力すると、配列外の参照が発生し、希にクラッシュするということになっていました。

このバグによるおかしな挙動はクラッシュ以外にも簡単に見られます。例えば、エディタ上でEnterキーを押して、空の行を大量に入力してから、IMEで一文字だけ入力して変換してみてください。そうすると、未確定文字列と候補ウインドウが重なるという現象が見られることがあります。これは、実際の挿入位置よりも手前の行の座標を算出してしまっているために発生します。ただ、ATOKでは発生しづらく、MS-IMEの方が簡単に再現できます。これは、IMEが発行してくるメッセージの違いによるものだと思います(ATOK側がこちらのバグを踏みづらい状況にあっただけ)。

このバグに対してユーザがとれるワークアラウンドは、外部のエディタで書いて貼り付けるか、先に改行だけ大量に挿入しておいて、先頭の方で編集して、最後に不要な改行を削除する、といったかなり後ろ向きな手段しかありません。