この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
前に使ってたバージョンが使い勝手悪かったのでアップグレードしたのですが、IMEを爆発物製造業者協会と訳してくれてびっくりしました。(もちろん辞書のカスタマイズ等で修正できますが。)
私の担当範囲でFx2からのregressionで修正の目処が立っていない大きな(言い換えればヤバイ)バグはいよいよこれだけになりました。
私しか修正する人間の居ないIME関係のバグは、現時点においても修正されていないバグは最終版に残ることになるでしょう。もしあなたが未だにnightlyで修正されていないIMEのバグを知っているなら急いで報告してください。ただし、余程簡単なもの以外は間に合いませんが。
ちなみに、Fx3での修正のチャンスを逃すと、修正はFx4(早くても2年後?)まで先送りとなる可能性も高いです。
Ctrlキーとの組み合わせが一切IMEにまで届いていなかったため、そういうショートカットキーを持つIMEの機能が使えなかったというバグです。
キー入力まわりがごそっと書き換えられて、修正されました。しかし、まだ若干問題が残っています。
cocoaのキー入力を取り扱うNSTextInputの仕様が非常にアレなので、IMEがキー入力を食ったかどうかがアプリからは分からないというのがいやらしいです。
Bug 5845で文字列を選択した際にreflowを発生させるために、textframeが一度dirtyになり、その時にnsISelectionController::scrollSelectionIntoViewが呼び出されるとスクロール先の座標算出に失敗するというバグでした。
APIの互換性を保つために、scrollSelectionIntoViewが座標計算前にpendingとなっているreflowをflushするようにしました。このため、特殊な拡張のみがこのバグの影響を受けるかもしれません。このメソッドを呼び出している拡張が、C++のネイティブなコードを持ち、その中からこれを呼び出している場合です。この際に、呼び出し前にnsPresContextやnsIPresShellやnsIFrameのポインタをweakで保持していた場合や、nsIFrameのプロパティ等をキャッシュしていた場合、scrollSelectionIntoView呼び出し後には再取得する必要があります。前者はstrongで保持していた場合、問題にはなりませんが、それらのオブジェクトは解放されてしまうかもしれませんので、期待通りの動作が維持できるかどうかは未知数です。
Beta5を追加することが決定しました。
これは非常に妥当で、良い判断だと思います。Geckoエンジンにもいくつかクリティカルな問題が残っていますし、なによりUI側が実装が色々と終わったばかりで全然ブラッシュアップされていないことを考えると、開発者にとって、そして何より、(リリースビルドを長く使う)ユーザにとって大きな意味を持つ一ヶ月だと思います。
IE8 betaがリリースされたようですね。こちらはそれどころではない状況なのでダウンロードもしていませんが、暇がとれ次第、どのようなデキか試してみたいと考えています。
宣伝文句がいささか誇大で、CSS2.1フルサポートと謳っていますが、あの大きな仕様をバグなく実装するというのは不可能なので、あり得ない謳い文句ではあるのですが、それを言えるというだけでも、それなりのレベルのエンジンが用意できるという自信の表れだと思います。また、標準仕様に準拠したレンダリングモードを標準にする等、改善した点が大きく、非常に評価されるべきものであると思います。もし、モダンブラウザとして恥ずかしくないレベルのものが最終的にリリースされることになれば、デザイナの業界はともかくとして、フルブラウザのベンダ側の業界はようやく非標準志向の製品が淘汰された、一昔前にはあり得ないと思われたような現実がやってきます。
これが現実となったとき、ライトユーザが「やっぱりIEでいいや」となるのか、「どのブラウザでも問題無くWebが利用できるなら乗り換えようか」となるかは今後のブラウザベンダの仕事次第ということになるでしょう。一定以上のクオリティの製品を作り、良い時流に乗れた(もしくは時流そのものを作れた)ベンダが生き残っていける、そういう健全な業界になることを一応期待しています。
それにしても今回のFx3のリリースに向けた追い込みで改めて感じましたが、ブラウザのエンジンは中途半端な完成度で出してはいけませんね。将来数年にわたる混乱の原因となりうる可能性を考えると、見切り発車は厳禁、リリース予定がいくら遅れようともそれなりのクオリティに達していないと社会全体の不利益がもの凄く大きいものだと思います。IE8もあまり急がずにじっくりとクオリティをあげてもらいたいものです。
フランス語等のキーボードレイアウトの時に、チルダを二回入力しても、チルダが二文字入力されず、何も起こらなかったというバグです。
ヨーロッパの一部のキーボードレイアウトでは、チルダはアクセント記号として利用するためにデッドキーとして入力を受け付けています。そのため、一文字入力した段階ではまだチルダは表示されません。この状態でa等のアルファベットを入力するとã等が入力される訳ですが、チルダをもう一度入力するとチルダが二文字出力されるということになります。ところが、trunkではregressionで何も起こらなくなっていました。
原因はKeyDown時にKeyPressイベントを処理するために、次に来るWM_CHARメッセージ等を削除してメッセージが実際に届く前に処理を行っていたのですが、デッドキーが入力された場合で、なおかつ、特定のキーの組み合わせの場合に、デッドキー入力なのですぐに処理しないにも関わらず、メッセージだけを削除してしまい、何文字チルダを入力しても「二文字目の」入力とはならずに、メッセージが破棄され続けるというものでした。
キーの組み合わせに関係無く、デッドキーの入力の場合には特殊な処理を行わないように変更することで修正できています。
下線位置を決定するために小数点を丸める際に通常の四捨五入をしていたため、上方向にはみ出していてnsIFrameのY座標が負になっている場合に算出結果が逆方向に丸められる、というバグでした。修正完了です。
MacOS XでQuickTimeのプラグインの説明がabout:pluginsでは表示されない、アドオンマネージャでは文字化けするというバグです。
以前にも説明したような気もしますが、MacOS Xはテキストファイル等ではShift_JIS等のローカルなエンコーディングを使いますが、ファイルシステムはUTF-8です。このようなエンコーディングのずれはMacOS Xでのみ発生するものなので、旧MacOSの時代に書かれたコードではこれらを意識して使い分けていませんでした。そのため、Shift_JISで取得されたQuickTimeプラグインの情報がUTF-8としてデコードしようとする訳ですが、UTF-8としてはInvalidなバイト列であるため、処理を中断して無かったことにしている、というのがabout:pluginsの場合の問題でした。
また、about:pluginsはDOM経由で文字列を取得するため、マルチバイトを意識した構造になっていたのですが、アドオンマネージャではプラグイン情報を管理しているだけだった国際化されていないクラスから直接文字列をISO-8859-1として取得していたため、文字化けしていました。
前者はnsPluginHost、後者はnsPluginTagで、nsPluginHostはnsPluginTagのDOM用のラッパーのようなものでした。そこで、nsPluginHostは文字のエンコーディングを気にしないように修正し、nsPluginTagはUTF-8で常にデータを持つように修正しました。これによって、どちらのクラスにアクセスしても、国際化された文字列が返されるようになっています。また、MacOS X固有のエンコーディングの違いにも配慮した設計に修正しています。
こちらはBug 5988と根が同じバグだったので、Bug 5988の修正で修正されました。
完成からすっかり時間が経っているので安心していたのですが、テストに裏で関わってたバグで思いっきりregressionを見逃してしまっていました。修正、完了しています。
Windows版のGecko1.8.1以前はlangがCJKなら下線位置をdecentの一番下にずらすようにしていたのですが、Gecko1.9ではそのコードがばっさりと無くなっていたため、一部のフォントで、全てのサイズ、もしくは一部のサイズで下線がくっつきすぎるという問題がありました。これはGeckoのバグという訳ではなく、適当ではないメトリックスを持つフォントが悪いのですが、とはいえなんらかの補正はやはり必要なので、今回からフォント名のブラックリストから特定のフォントでのみ、XPレベルで下線位置を今までのように補正するようになりました。
ブラックリストはfont.blacklist.underline_offsetという設定でカスタマイズ可能です。内容はカンマ区切りのフォント名ですが、Macでは英語のフォント名しか利用できないことに注意してください。Windowsはそのフォントの名前なら何語でも問題ありません。設定変更後はFxの再起動が必要です。
なお、gfxPangoFont*の実装の都合上、Linuxではこの機能はまだ使えません。これは将来のバージョンで修正されるかもしれません。
また、下線位置は、font-familyによる指定と、lang属性から取得したフォント設定(font.name.*とfont.name-list.*の双方)から、一番最初のフォントのものと、一番最初のブラックリストに載っていたフォントのものとで比較を行い、下側になる方を採用します。そのため、Gecko1.8.1までの表示結果とは少し違った結果になる可能性が高いです(Gecko1.8.1までは常に一番最初のフォントの下線位置が使われていました)。フォントのリストは、font-familyの指定順、font.name.*のうち、要素の言語に合ったもの、font-.name-list.*のうち、要素の言語にあったものの順に作られます。
なお、システムフォント(CSSのシステムフォント指定、ということです)にはこの補正は適用されないので注意してください。これはそのプラットフォーム上での他のアプリケーションとの表示結果に互換性を持たせるための措置です。また、XUL要素内の下線位置も今までから変更はありません。ブラックリストは利用されず、下線位置は常に一番最初のフォントのものになります。あくまでWebページのコンテンツのレンダリングでのみ影響がある修正です。
例えば日本語環境のOS上だと、韓国語や中国語のフォントが、フォントの設定画面で、設定通りのフォントが選択された状態にならない、というバグです。
デフォルト設定では、各言語にローカライズされた名前でフォント名を保存していたのですが、設定画面のフォントリストはシステムロケールに依存するので、設定ではローカライズされた名前でも、リストでは英語名になってしまっていると、それが選択された状態にはならなかった、というものです。実際のWebページの表示に関わるバグではありません。
バックグラウンド側のフォント名の解決には各プラットフォーム毎に私以外の方の協力が多分に含まれています。地味ですが、非常に多大な貢献で修正が可能になりました。協力してくれた全ての方に感謝します。
恥ずかしすぎるバグなので説明省略。
言いたいことはなんとなく分かるんですが、そもそも勝つ、ということが目標ではないのです。Mozillaは。
もちろん、関係者として、勝ちたいっていう漠然とした願望はありますが、それって少なくとも私にとっては一番の目標ではないです。ご存知の通り、IE6の独占状態によりWebの技術的進歩は完全に数年間停滞していました。そして、これを再び動かしたのはFirefoxの急激なシェア拡大でした。Operaがどんなに別のところでシェアを持とうと、実際にシェアが握られているところを突き崩さない限り、こういった改善は起きなかったでしょう。
シェア奪って、金儲けに走って、というのは営利企業としては正しい発想ですが(手段は選べよ、と常々思いますけどね、特に某A社)、それはユーザの求める部分とは異なっています。私はユーザにとってはまともな選択肢がある状況が一番幸せな状況だと思いますが、そういった状況はMozillaも含めてあらゆる企業のブラウザがシェアを握りすぎると実現できません。本音を言うなら、私はMozillaもシェアを握りすぎるべきではないと考えています。(現実的な)選択肢がFirefoxしかない、という状況もまた自由からはほど遠いからです。また、シェアを握りすぎた場合、昔のNetscapeのような暴走が無いとは言い切れないという懸念も残念ながら存在します。
ただし、最低限のシェア、というものはユーザとしての利便性を考えるとどうしても必要です。例えば、今、Firefoxを使っていて問題のあるサイトが減ってきているというのは、決してプロダクトの進化が主な理由ではありません。シェアが伸びたことにより、Webデザイナ様や、そのクライアント様が配慮してくれているだけに他なりません。ですから、企業としてのMozillaがブラウザ業界でのシェアを広げる、というのは非常に大切なことなのです。
根本的なところで発想の違うAppleやOperaとMozillaの経営方針を比較してしまう、というのは無意味ではないでしょうか。
ついでにPiroさんがOperaのモバイルや家電でのシェア獲得について書いているので少しだけ私見を述べておきます。
日本ではモバイルと言えば携帯電話です。スマートフォンやPDAというのはまだまだごく一部のオタクだけのもので、一般的なライトユーザにもメジャーなデバイスではありません。つまり、前者は商売の土台として有望ですが、後者はそうではありません。
で、今の日本の携帯電話の状況を見てみると、Firefoxが急いで携帯電話でのフルブラウザのシェアを握る必要があるかと考えると絶対にノーでしょう(もちろんその準備や研究等々の必要性は否定しませんが)。携帯電話のハードウェア面でのブレイクスルーがない限りはFirefoxにとってはあの市場というのは、実は頭打ちのおいしくない市場なのではないかと思います。
その理由は現状ではハードウェアの制約が大きすぎるからです。画面の解像度は低すぎて(というかPC環境と差がありすぎて)コンテンツをまともに見れなかったり、テンキー等の最低な入力デバイスで入力にはとことん不便を強いられ、貧弱すぎるメモリがアクセス不可能なページが出てくるといった問題を引き起こしてくれます。また、デスクトップでは軽いと言われるOperaでさえ、かなりのレスポンスの悪さに辟易させられてしまいます。こういった制約からOperaもフルブラウザと自称しながら、デスクトップ環境からアクセスできるウェブコンテンツへのアクセスを完全には実現できていないというのが現状です。
このような状況下でFirefoxをそのまま移植しても便利なブラウザとは呼べないと思います。快適なレスポンス等を確保するために様々な機能を削ったとしましょう。そうして出来上がったものはデスクトップのブラウザ市場で一定の支持を集めているFirefoxと同じものでしょうか? 私はそうはならないと思います。
本当に今の携帯電話でフルブラウザって必要なもので、ユーザは欲しいと思っているのでしょうか? また、現在の携帯電話に載っているOpera等を使い倒している人が居るとしたら、どういう用途で使っておられるのでしょうか? それは本当にフルブラウザじゃなければ実現できないサービスなのでしょうか? そのような用途にFirefoxが予算や人員を本格的に割いてでも入っていく必要性があるのでしょうか?
現状の携帯電話の能力でフルブラウザによる快適なWebを実現しようという発想は、ブラウン管しか無い時代に持ち運び可能なテレビ多分需要があるので作ってみよう、と考えるぐらいに理想と現実がごちゃ混ぜになってしまっている感じがしてしまいますが、これは時代遅れな発想なのでしょうか?
別のバグの検証中に発見したバグで、egbridgeのバグがこのバグのトリガとなっていました。beta5での修正には間に合いました。
ATOKもegbridgeも入力モードを切り替えた時の処理がいい加減で、JIS以外のキーボードレイアウトからATOK/egbridgeに変更しても、キーボードレイアウト自体をJISキーボードレイアウトに戻さない、というバグがあります。(ATOKの方は知り合いを通じてJust Systemさんに報告してあります。)
ほとんどの日本語ユーザはこのバグ自体に出会うことがほとんど無いと思いますが、キーボードレイアウトを無闇に追加してしまうと様々なバグに出くわす可能性があるので注意してください。
まあ、そもそもMacOS XがキーボードレイアウトとIMを同列に扱うからこんな変な話も出てくるのですが。なんでMacOS Xはこんな変な設計を行ったんでしょうか……(今回のegbridgeはキーボードレイアウトが元のままなのに、IM自身が生成している入力イベントはJISキーボードレイアウトが利用されたことを前提にしているのでアプリケーションでは解決不能な矛盾が生じています。)
色々と頑張りすぎです。
下線まわりのデバッグをしようとチェックアウトを行ったら、たまたま直前のチェックインで下線のブラックリストのシステム自体が壊されていたので急いで修正パッチをあげたという、珍しいバグです。他の作業の都合上、大急ぎで作業したため、しょうもないミスをしていましたが。
で、そのBug-org 425249のしょうもないミスのバグです。こちらも修正が終わってますが、パッチを見て分かるようにランダムに発生するバグなので、これだけで完全に修正できているかは不明です。(そもそも私の環境では再現できませんでした。かなり高確率で再現してもよさそうなものですが……)
要約通りのバグです。
interpretKeyEvents経由でIMEにキーイベントを投げたにも関わらず、insertTextが呼ばれなかった場合、keypressイベントを自前で再生成していたため、このように望まれない入力が発生していました。
regressionが恐いので出来る限り制限を付けて、再生成を抑制するようにして回避していますが、まだ何かバグがある可能性は否定できません。
下線等の有無が変わる度にreflowを起こさせて下線等のためのoverflow領域を再計算していたため、パフォーマンスがすごく落ちていた、というバグです。
reflowを起こすとどうしてもパフォーマンスの問題が発生するため、下線や上線をoverflow領域には描画しないようにするしかありませんでした。そこで、フォントの高さよりも外側に下線や上線が描画されるケースではframeの高さ自体を拡張してしまうように仕様を変更しました。このため、例えばMS Pゴシック等では下線の描画領域を確保するため、font-size: 16px;としてあっても、実際には17pxの高さが確保されます。このため、line-height:1em;等と指定して、ものすごくタイトな(CSSにとってはタイトすぎる)レイアウトを行っているサイトではBeta5と次のRC1とではレイアウト結果が変化する可能性があります。
line-height:normal;(デフォルト)の場合はこの変更の影響は全くないのでレイアウト結果が変わることは無いはずです。
trunkでは実際に使われているフォントのみから選択範囲背景を描画する高さを算出していたため、font-family: 欧文フォント, 和文フォント;という指定を行っている場合に、日本語のみのtextframeで選択を行うと、欧文フォントの高さが含まれないため、選択範囲の高さがガタガタになる可能性があったというバグです。<wbr>ハックを行っているような場合にはかなり汚い見た目になっていたので、修正が間に合って良かったです。
下線がoverflow領域に再描画される際に、再描画領域がきちんと無効化されず、再描画対象から外れていた、というのがこのバグの原因です。
Bug 6069の修正で下線がoverflow領域に描画されることがなくなったのでこのバグは再現しなくなっていますが、CSS3のtext-decorationでは下線等の高さを変更できるので、それを実装すると、このバグが再び再現するようになる可能性はあります。
textarea/input要素はonchangeイベントのために、フォーカスを取得時に現在のエディタの値を保存し、フォーカスを失うときにそれと、そのときの値とを比較する、ということを行っています。その、値の取得時になぜかtextarea要素の場合にのみ、IMEを確定させていて、それがこのバグの原因となっていました。
未確定文字列は値に含める必要はないので、何故このようなコードが入っていたのか不明ですが、今のIMEの管理能力では削除しても問題無いので、単純に削除して修正しました。
Bug 6069の修正で修正できてしまったバグです。
Bug 6069がレイアウト結果を変えてしまうため、reftestを繰り返していたのですが、当初はfont-size: 0;の場合のテストがクリアできませんでした。その原因を調べてみると、font-size: 0;の場合、その要素は存在するが、内容が空であるかのようにレイアウトを行うという妥協が入っていることが分かりました。(現状の音声読み上げブラウザ等が@mediaを使わずにスクリーン上でのdisplay: none;を読み上げ時等にも使ってしまうので、コンテンツ側で利用されるハックのためのようです。) つまり、font-size: 0;の場合には下線等の描画場所を確保してはいけないというのがreftestをクリアできない理由だったのですが、WindowsとMacはOSの仕様上、サイズゼロのフォントは作れないのでgfxはコードの単純化の都合上、最低でも1pxのフォントを作るようにしていたため、サイズゼロの場合にgfxから返ってくるメトリクスが信頼できない、ということが分かりました。
そこでgfx上で、フォントサイズがゼロだった場合には各メトリクスをゼロ固定とすることでlayout側に特に変更を加えずにこの問題を解決させてみると、このバグまで修正されてしまった、という訳です。