この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
mozilla/accessible以下のファイルのprefへのアクセス部分はmozilla::Preferencesを利用するように置換されました。
このときに教えてもらったのですが、UIの情報を取得するテストは、Windows SDK付属のInspect Objectsを使えばできます。Inspect Objectsでターゲットを指定するとUIに関する様々な情報が一覧表示されますが、ここに表示される情報の一部はa11yのためのAPIを経由して取得しているようです。
mozilla/modules以下のソースコードもprefへのアクセスにmozilla::Preferencesを利用するようになりました。
mozilla/storage以下のソースコードもmozilla::Preferencesを利用するように修正が終わりました。
View Sourceの実装もmozilla::Preferencesを利用するようになりました。
nsImageFrame::IconLoadがprefのobserverを登録しているのに、それを解除することがなかった、というバグです。ただ、インスタンスがひとつだけしか作られず、XPCOMのシャットダウンまで破棄されないので実害はないと思われます。
一応、インスタンスを削除する際に登録を解除するように修正しています。
mozilla::Preferencesに登録されていたobserverはXPCOMのシャットダウンをmozilla::Preferences自身が知った際に削除し、自身のシングルトンインスタンスもリリースしていたため、これよりも後からXPCOMのシャットダウンを知ることになるモジュールからのobserverの登録解除が無用な警告を大量に出力するようになっていました。
この修正で、まずはmozilla::Preferencesは後始末をXPCOMのシャットダウン時ではなく、シングルトンインスタンスが実際に破棄される時に遅らせるように修正しました。これにより、XPCOMシャットダウンの通知がmozilla::Preferencesよりも遅いモジュールがprefsへのアクセスをシャットダウン時に必要としている場合、あらかじめnsCOMPtrでサービスのインスタンスを掴んでおけば可能なように改善しています。
また、RemoveObserver()が既にシングルトンインスタンスが破壊されている状態で呼ばれてもそれはバグにはならないのでこの際には警告を出力しないように修正しています。
このため、もし、なんらかのモジュールからのアクセスで同様の警告が出ていることがあれば、それは実際にバグっていて、prefへのアクセスに失敗していることを意味しますので、発見された場合はバグとして報告してください。
高精度スクロールでXULのリストボックスをスクロールさせると一行単位ではなく、ピクセル単位でスクロールして、さらに再描画がうまくいかない、というバグです。
XULのリストボックスはもともとピクセル単位のスクロールをサポートしていません。ですが、通常のスクロールイベントが発生するよりも前に発生したピクセルスクロールイベントはESMがそのままnsGfxScrollFrameに渡してしまい、予期せぬピクセルスクロールが実行されていました。
一度一行分のスクロールイベントが発生している場合、それはXULのリストボックスが消費してしまうため、それに続くピクセルスクロールイベントは自動的にESMが処理することはなくなるため、非常に分かりにくいバグになっていました。
XULのリストボックスは常にピクセルスクロールイベントも消費するように修正して解決していますが、XULのツリー等、他にも同様のバグを抱えている可能性のあるものもあるかもしれません。
tier-1以外のプラットフォームのwidgetのコードも全て、mozilla::Preferencesを利用するように修正しました。
layoutのコードもmozilla::Preferencesを利用するように修正しました。
gfxも全て、mozilla::Preferencesを利用するようになりました。
この修正で、GetComplex()とSetComplex()がmozilla::Preferencesに追加されました。
また、mozilla::Preferencesのメソッドがコンポーネントマネージャの初期化前に呼び出されると、シングルトンインスタンスの初期化に失敗しているバグがありましたが、それについても修正しています。
Firefoxのビルド時間をPCのベンチマークとして雑誌とか使ってくれないもんですかね、CPUパワーだけじゃなくてディスクのI/Oとか割とPC全体のパフォーマンスの指標として良いとは思うんですが。まあ、それはともかく、ネットブックに限りなく近いスペックのノートPCでのみ発生するバグの検証のためにビルドしてみたんですが、とんでもない時間かかったので、参考に普通の環境との比較を掲載しておきます。
| CPU | システムドライブ | ビルド用のストレージ | ソフトウェア | 時間 |
|---|---|---|---|---|
| Core i7 920 (2.66GHz) | SSD 160GB | SSD 120GB | Windows 7 + Visual Studio 2008 | 89min |
| Core i5 M520 (2.4GHz) | SSD (64GB4台がRAID) | システムドライブ | Windows 7 + Visual Studio 2008 | 112min |
| 同上 | VMWare上のWindows XP + Visual Studio 2008、ホストはWindows 7 | 166min | ||
| Atom N550 (1.5GHz) | 2.5インチHDD 5400rpm | システムドライブ | Windows 7 + Visual Studio 2008 | 325min |
いい加減な計測ですがすべて他に特に何もしていない時にビルドしています。メモリは特に記述しませんでしたが、問題のネットブックまがいのノートPCでも2GBも積んでいて、潤沢です。
そのAtom機が猛烈に遅いのはCPUパワーだけじゃなくて、HDD一台でシステムもビルドも持ってるからだと思いますが、まあFirefox 4を実際に使っていても実用レベルの速度ではないですね、やっぱり値段相応といった感じ。
最上段はデスクトップでその下段はノートPCです。今となってはシングルスレッドの実行速度では低速な部類に入りつつあるCore i7 920でも結構大差をつけてノートPCに勝ててしまうあたり、デスクトップ機はやっぱり強いですね。SandyBridgeだとどこまでビルド時間を短縮できるのか興味がありますが、まあ年末?のLGA2011待ちです。
まだまだ、こつこつとpref関連のコードのメンテを続けています。
これはcaps/配下のコードの置換です。ちなみにcapsはPrivilege Managerの実装コードのようです。知りませんでした。また、CAPSの意味も初めて知りました。詳しいことはComponent Security for Mozillaにあります。暇を見つけて読んでみたいですね。
editor/以下のコードのprefs関連コードの置換です。
char型のprefへのアクセスにあたって、GetColor()やSetColor()というAPIも作った方が良いのかなという気がします。現状、prefにセットされている値のチェックがいい加減ですし、透過も当然サポートしていませんし。
view/配下のコードのpref関連のコードの置換をしようとしたところ、既に利用していたコードは全て無くなっていました。#includeだけ放置されていたので、それだけ削除しています。
Borisからの要望で、デフォルト値にアクセスするためのAPIも一通り用意しました。
mozilla::Preferences::GetDefault*()でアクセスできます。もちろん、SetDefault*()なんてのはありません。
昔懐かしい、xpfe/配下のpref関連コードも置換が終わりました。
いい加減、どこかいい引受先は無いものなんでしょうか。
xpinstall/配下のコードの置換作業だったのですが、今はもう使ってないらしく、削除されるコードだということで却下されました。
docshell/配下のコードも置換終了です。
あと残っているのは、netwerk/、chrome/、embedding/、uriloader/(レビュー中)、dom/(レビュー申請中)、intl/、extensions/、toolkit/、content/(レビュー申請中)、security/。最後のsecurityは手を出して良いのかよく分かりませんが。