なぜFx3.0.2からこの修正をバックアウトしたのか、関係者からも質問が来たのでここに明記しておきます。
まず、Fx3.0.xというバージョンは全てMozillaの正式なリリースです。Fx3.0.1以降は、基本的にセキュリティ修正のためのものであり、機能追加等は行われません。なぜなら、これらのバージョン間では互換性が最も重要視されるためです。しかし、例外的に一部のユーザが製品を利用する際に困る、重大な問題は副作用がほとんどないことを前提に修正が許可されます。
このような前提があるため、基本的にFx3.0.xでの修正では、regressionは許されません。regressionがあっても、まず発生させることがないようなレアなものだったり、発生しても実害が無いもので、なおかつ修正による効果が大きい場合は無視されるかもしれませんが、このへんはリリースドライバの判断が基準となるので、明確な線引きはできません。また、セキュリティ上、仕方のない仕様変更もregressionではありますが、こちらは基本的にセキュリティの改善が優先されることになるでしょう。
今回のケースでは、特定のテーマを利用していた場合はブックマークダイアログという、メジャーな機能の利用により、ハングアップ、またはクラッシュという最悪の状態が発生します。つまり、発生する可能性が非常に高く、また、実害が大きすぎます。このような状況下ではアクセシビリティ上の大問題であるこのバグの修正であっても、許されるレベルのものでは無いと私は考えます。
次のように考えてみてください。Fx3.0.xはFx用のテーマのプラットフォームなのです。この、クライアントが動作しなくなると分かっている修正をプラットフォームに入れることがいかに間違った判断であるかは明白です。
また、セキュリティ問題の修正が主眼であるFx3.0.xが特定のバグを修正するために、このような問題を一時的にでも持つことはナンセンスです。これらのユーザがセキュリティ的に問題のあるバージョンを使い続けることを促してしまうからです。セキュリティフィックスバージョンはユーザに互換性を気にせずに安心してアップグレードしてもらえることが大前提となります。
Fxの普及を考えた場合、安心してセキュリティアップデートができないプロダクトであってはいけないのです。
ちなみに、投入していたパッチが非常にアレなアプローチだったのは、XULの仕様変更をしなくて済むという大きな理由があったためです。もし、現在レビュー中のXULの仕様変更を行うパッチを投入した場合、一部の拡張機能がうまく動作しなくなる危険性があります(しかもそれなりに高いと思います)。そのようなリスクは出来る限り回避しなくてはいけないのがBranchでの修正の難しさです。
