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

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

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

2011年6月14日

Bug-org 660742 accessible should use mozilla::Preferences 初回投稿日時: 2011年06月14日16時42分43秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011061400
リンク元: 0件
SNS: (list)

mozilla/accessible以下のファイルのprefへのアクセス部分はmozilla::Preferencesを利用するように置換されました。

このときに教えてもらったのですが、UIの情報を取得するテストは、Windows SDK付属のInspect Objectsを使えばできます。Inspect Objectsでターゲットを指定するとUIに関する様々な情報が一覧表示されますが、ここに表示される情報の一部はa11yのためのAPIを経由して取得しているようです。

Bug-org 660568 nsImageFrame::IconLoad doesn't remove pref observers 初回投稿日時: 2011年06月14日16時52分38秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011061404
リンク元: 0件
SNS: (list)

nsImageFrame::IconLoadがprefのobserverを登録しているのに、それを解除することがなかった、というバグです。ただ、インスタンスがひとつだけしか作られず、XPCOMのシャットダウンまで破棄されないので実害はないと思われます。

一応、インスタンスを削除する際に登録を解除するように修正しています。

Bug-org 660640 Preferences spams lots of failing NS_ENSURE_TRUE at shutdown 初回投稿日時: 2011年06月14日17時01分24秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011061405
リンク元: 0件
SNS: (list)

mozilla::Preferencesに登録されていたobserverはXPCOMのシャットダウンをmozilla::Preferences自身が知った際に削除し、自身のシングルトンインスタンスもリリースしていたため、これよりも後からXPCOMのシャットダウンを知ることになるモジュールからのobserverの登録解除が無用な警告を大量に出力するようになっていました。

この修正で、まずはmozilla::Preferencesは後始末をXPCOMのシャットダウン時ではなく、シングルトンインスタンスが実際に破棄される時に遅らせるように修正しました。これにより、XPCOMシャットダウンの通知がmozilla::Preferencesよりも遅いモジュールがprefsへのアクセスをシャットダウン時に必要としている場合、あらかじめnsCOMPtrでサービスのインスタンスを掴んでおけば可能なように改善しています。

また、RemoveObserver()が既にシングルトンインスタンスが破壊されている状態で呼ばれてもそれはバグにはならないのでこの際には警告を出力しないように修正しています。

このため、もし、なんらかのモジュールからのアクセスで同様の警告が出ていることがあれば、それは実際にバグっていて、prefへのアクセスに失敗していることを意味しますので、発見された場合はバグとして報告してください。

Bug-org 662191 Profile name are blank in the listbox of Profile manager when scroll the listbox by mouse wheel. 初回投稿日時: 2011年06月14日17時10分01秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011061406
リンク元: 0件
SNS: (list)

高精度スクロールでXULのリストボックスをスクロールさせると一行単位ではなく、ピクセル単位でスクロールして、さらに再描画がうまくいかない、というバグです。

XULのリストボックスはもともとピクセル単位のスクロールをサポートしていません。ですが、通常のスクロールイベントが発生するよりも前に発生したピクセルスクロールイベントはESMがそのままnsGfxScrollFrameに渡してしまい、予期せぬピクセルスクロールが実行されていました。

一度一行分のスクロールイベントが発生している場合、それはXULのリストボックスが消費してしまうため、それに続くピクセルスクロールイベントは自動的にESMが処理することはなくなるため、非常に分かりにくいバグになっていました。

XULのリストボックスは常にピクセルスクロールイベントも消費するように修正して解決していますが、XULのツリー等、他にも同様のバグを抱えている可能性のあるものもあるかもしれません。

Bug-org 663036 gfx should use mozilla::Preferences 初回投稿日時: 2011年06月14日17時18分19秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011061409
リンク元: 0件
SNS: (list)

gfxも全て、mozilla::Preferencesを利用するようになりました。

この修正で、GetComplex()SetComplex()mozilla::Preferencesに追加されました。

また、mozilla::Preferencesのメソッドがコンポーネントマネージャの初期化前に呼び出されると、シングルトンインスタンスの初期化に失敗しているバグがありましたが、それについても修正しています。

2011年6月24日

Firefoxのビルドでベンチマーク 初回投稿日時: 2011年06月24日14時56分47秒
最終更新日時: 2011年06月24日14時57分11秒
カテゴリ: Firefox 雑談
固定リンク: id=2011062400
リンク元: 0件
SNS: (list)

Firefoxのビルド時間をPCのベンチマークとして雑誌とか使ってくれないもんですかね、CPUパワーだけじゃなくてディスクのI/Oとか割とPC全体のパフォーマンスの指標として良いとは思うんですが。まあ、それはともかく、ネットブックに限りなく近いスペックのノートPCでのみ発生するバグの検証のためにビルドしてみたんですが、とんでもない時間かかったので、参考に普通の環境との比較を掲載しておきます。

環境によるFirefox(デバッグビルド)のビルド時間の比較表
CPUシステムドライブビルド用のストレージソフトウェア時間
Core i7 920 (2.66GHz)SSD 160GBSSD 120GBWindows 7 + Visual Studio 200889min
Core i5 M520 (2.4GHz)SSD (64GB4台がRAID)システムドライブWindows 7 + Visual Studio 2008112min
同上VMWare上のWindows XP + Visual Studio 2008、ホストはWindows 7166min
Atom N550 (1.5GHz)2.5インチHDD 5400rpmシステムドライブWindows 7 + Visual Studio 2008325min

いい加減な計測ですがすべて他に特に何もしていない時にビルドしています。メモリは特に記述しませんでしたが、問題のネットブックまがいのノートPCでも2GBも積んでいて、潤沢です。

そのAtom機が猛烈に遅いのはCPUパワーだけじゃなくて、HDD一台でシステムもビルドも持ってるからだと思いますが、まあFirefox 4を実際に使っていても実用レベルの速度ではないですね、やっぱり値段相応といった感じ。

最上段はデスクトップでその下段はノートPCです。今となってはシングルスレッドの実行速度では低速な部類に入りつつあるCore i7 920でも結構大差をつけてノートPCに勝ててしまうあたり、デスクトップ機はやっぱり強いですね。SandyBridgeだとどこまでビルド時間を短縮できるのか興味がありますが、まあ年末?のLGA2011待ちです。

2011年6月30日

Bug-org 660770 caps should use mozilla::Preferences 初回投稿日時: 2011年06月30日14時59分23秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011063000
リンク元: 0件
SNS: (list)

まだまだ、こつこつとpref関連のコードのメンテを続けています。

これはcaps/配下のコードの置換です。ちなみにcapsはPrivilege Managerの実装コードのようです。知りませんでした。また、CAPSの意味も初めて知りました。詳しいことはComponent Security for Mozillaにあります。暇を見つけて読んでみたいですね。

Bug-org 664437 editor should use mozilla::Preferences 初回投稿日時: 2011年06月30日15時03分53秒
最終更新日時: 2011年06月30日15時04分22秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011063001
リンク元: 0件
SNS: (list)

editor/以下のコードのprefs関連コードの置換です。

char型のprefへのアクセスにあたって、GetColor()SetColor()というAPIも作った方が良いのかなという気がします。現状、prefにセットされている値のチェックがいい加減ですし、透過も当然サポートしていませんし。

Bug-org 664917 Add Preferences API for getting default pref values 初回投稿日時: 2011年06月30日15時10分29秒
最終更新日時: 2011年06月30日15時10分56秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011063003
リンク元: 0件
SNS: (list)

Borisからの要望で、デフォルト値にアクセスするためのAPIも一通り用意しました。

mozilla::Preferences::GetDefault*()でアクセスできます。もちろん、SetDefault*()なんてのはありません。

Bug-org 666901 docshell should use mozilla::Preferences 初回投稿日時: 2011年06月30日15時27分30秒
カテゴリ: Mozilla Core Mozilla7 バグ修正
固定リンク: id=2011063006
リンク元: 0件
SNS: (list)

docshell/配下のコードも置換終了です。

あと残っているのは、netwerk/chrome/embedding/uriloader/(レビュー中)、dom/(レビュー申請中)、intl/extensions/toolkit/content/(レビュー申請中)、security/。最後のsecurityは手を出して良いのかよく分かりませんが。