Gecko1.8.1を利用した製品は、Firefox2やThunderbird2です。
この文書は、Mozilla Japanの公式文書ではありません。 また、内容はエンドユーザ向けではなく、開発者向けのものとなっていますのでご注意ください。
ここではGecko 1.8以降、Gecko 1.8.1までに私が修正したバグの紹介を行います。
私はMozilla Japanのメンバーとして(Mozilla Japanの仕事として)修正作業を行っていますので、 このリストはMozilla JapanがMozilla Foundationのプロダクトに対してどのような貢献を行ったのか、 というリストの一部と考えてもらってもかまいません。
ですが、どのバグをどのように修正するのか、その仕様は私の裁量や、そのパッチのレビュアに依ります。 そのため、ここで紹介する内容の詳細はMozilla Japanの会社としての方針と一致するとは限りません。 ですので、修正内容等に対してご意見、ご不満がある場合、 Bugzilla-jp からバグとして報告をしていただいて、より良い改善案を提案していただければ柔軟に対応できるかと思います。
HTMLエディタ(Fxのデザインモードや、Tbのメール作成画面)で一文字も選択せずに再変換を行うと、 キャレットの次の文字が削除されるというバグ。
原因は、再変換を行った時には文字列が選択されているという前提でDeleteキーを押したのと同じ様な処理をしていたため。
文字列が選択されていない場合、削除処理を走らないようにして修正。
この修正は1.8.0.2で行われた。
MacでEGBRIDGEを選択し、日本語の文字の間にキャレットがある状態でスペース(U+20)を入力しようとすると、 次の文字が削除され、そのままスペースキーを連打してもスペースが入力できない、というバグ。
EGBRIDGEがスペースキーを押した時に再変換のメッセージを送っていたのが原因。 そのため、Bug-org 317782の修正でこのバグも再現しなくなっている。
この修正は1.8.0.2で行われた。
Windowsの Unispim IME(紫光华宇拼音输入法) で数字を入力しようとすると、一回キーを押す毎に二文字入力されてしまうというバグ。
Unispim IMEは一回の入力でWM_KEYDOWNを二回送信してくるというバグがあるようで、
更に、GeckoはWM_CHARが無くても、WM_KEYDOWNを受信した時点で文字の入力があったと仮定して処理していたため、
Gecko内部ではあたかもWM_CHARが二回受信されたかのような挙動をしていたことが原因。
欧米のキーボードレイアウトへの影響が怖いので、CtrlもAltも押されていない状態で、
なおかつWM_CHARがWM_KEYDOWNの直後に無い場合はそれを文字入力とは見なさないように修正した。
この修正は1.8.0.5で行われた。
GTK2の(おそらく一部の)中国語のIMでover-the-spotが機能しないというバグ。
原因は中国語のIMは自前で生成したウインドウに未確定文字列を表示し、 実際には未確定文字列があるにも関わらず、 Geckoには未確定文字列がゼロ文字であると通知するという、型破りな動作にあった。
他のプラットフォームも含め、このような状況が他に確認されていなかったため、 Geckoのエディタは未確定文字列がゼロ文字の状態で未確定文字列が変更されたというイベントが発生した場合に、 何も処理していなかったため、結果的に初期化されていない変数が位置情報としてIMに返され、正しい場所に表示できていなかった模様。
未確定文字列がゼロ文字の場合でも座標を正しく返すように修正を行った。
このバグは1.8.0.7で行われた。
Find Toolbarの実装はC++で実装されている部分と、Javascriptで実装されている部分の二つに分かれるのだが、 Javascriptで実装しているほうでは、グローバルスコープに特殊なプリフィックスも無い関数や変数が多々あるため、 Find Toolbarを利用する側のソースコードとバッティングが発生したり、 Find Toolbar側の修正で他のソースコードがうまく動作しなくなるという問題があった。
そのリスクを激減させるため、
gFindBarというグローバルスコープのオブジェクト内に大半の機能をカプセリングし、
タイマのコールバック等、グローバルスコープの関数でなくてはならないものには、
findBar_というプリフィクスを義務づけるように修正した。
この修正は1.8.1で行われた。(私はtrunk用のみの作業で、1.8 branchへの移植はPhil Ringnaldaが作業してくれた。)
検索対象となるDocShellが変更された時、不要になるオブジェクトがリリースされていなかったバグ。
検索対象のDocShellが変更されたら、前回の検索結果をキャッシュしていたオブジェクトが不要になるのだが、 それをリリースしていなかったため、一時的にリークしていた。(参照カウンタの問題なので、解放のタイミングが遅れていただけ。)
単純にDocShellの変更時にはそれらもリリースするように修正。
この修正は1.8.1で行われた。
添付ファイル名がヘッダ上で複数行に分割される際に、その区切り目にセミコロンを挿入できていないため、 Becky2!等で受信した添付ファイル名が化けていることがあるというバグ。
大本のRFC 2231の例示が間違っていたことから発生したと思われるバグだが、 Blameで履歴を遡っても、Netscape Communicator時代のバージョンでも問題のコードがあるというかなり古いバグ。 ただ、そのコードがTb1.5で初めて使われたためにこんなにブランクが空いてから発見されることになった。
この修正は1.8.0.2で行われた。
Netscape4.xからメールをインポートする時に、フォルダ名に0x5C(\)が含まれているとそのフォルダのインポートに失敗していたというバグ。
もう、説明するまでもない、基本的なパス処理の問題。
単純にstrrchrを_mbsrchrに変更。
この修正は1.8.0.2で行われた。
MacOS XではUTF-8以外の文字コードで署名ファイルを作ると、文字化けするというバグ。
署名ファイルを読み込む際、システム標準の文字コードを読み込んで、 それを元にデコードしていたのだが、その取得していた文字コードが、 ファイルシステムで使われている文字コードだったいうのが原因。 (MacOS Xでは常にUTF-8が返される。)
何故ファイルシステムの文字コードを使っていたかというと、 テキストファイルで通常用いられる文字コードの取得方法が無かったため。 そこで、ファイルシステムの文字コードで代用していたが、 MacOS Xで初めて、それが食い違ってしまったためにバグとして露見した。
新たにテキストファイル用に、システム標準の文字コードを返すようにパラメータを拡張し、 また、regressionになってしまわないように、UTF-8の署名ファイルを読み込んだ場合には、 そのままUTF-8として処理するようにした。
そのため、どのプラットフォームでもシステム標準の文字コードと、 UTF-8の二種類が署名ファイルで使えるようになっている。 (もちろん、システムの文字コードがUTF-8なら一種類のみだが。)
この修正は1.8.1で行われた。
これもRFC 2231違反。0x2B(+)と0x2F(/)がエスケープされないというバグ。
根本的な原因はRFC 2231のために作られたのではないnsEscapeの流用が問題なのだが、
branch上であまり根本から書き換える処理はできないので、
ASCII文字が2バイト目に出現する文字コード(Shift_JIS等)の場合のみ、
全ての文字をエスケープするようにして対応。
この修正は1.8.0.5で行われた。
WindowsではUTF-8よりもUTF-16を利用する機会の方が一般的なのだが、 UTF-16で作成した署名ファイルを読み込むと文字化けしてしまうというバグ。
これはあくまでもWindowsで一般的なメモ帳で作成しても大丈夫なように、という話で進められたので、 UTF-16(BOM付きのもので、UTF-16BE/UTF-16LEではない)のみが対象となっている。
読み込んだファイルにUTF-16のBOMらしきものを発見すると、それをUTF-16として扱うように修正した。
また同時に、BOM付きのUTF-8を読み込んだ場合に、BOMを削除していないバグがあったので、 それも修正している。
この修正は1.8.1で行われた。
ノーマライズされていないIDN(例えば、日本語。ＪＰ)をロケーションバーに直接入力すると、 国際化ドメインのホワイトリストチェックに失敗するというバグ。
ノーマライズされていないIDNを入力されると、それがそのままチェックされていたため、 ノーマライズされた形でしかチェックできないホワイトリストを素通りしてしまい、 どのドメインであってもpunycodeで表示するようになってしまっていた。 (つまり、幸いなことに危険性は無かった。)
ノーマライズを行ってからチェックを行うようにして、修正している。
この修正は1.8.0.2で行われた。
IFRAME内のテキストを選択し、選択部分だけ印刷しようとするとハングアップするというバグ。
1.8の前に、IFRAME等の子ドキュメントの印刷処理が二度走らないように修正したが、 その際に条件が足りていなかったため、印刷されるべき場所が印刷されないまま処理が終わるのだが、 そのために永遠に全ての印刷作業が完了しない、という状況になっていた。
通常の印刷では問題の場所よりも先に子ドキュメントの印刷が終わっているはずなので、 もし、子ドキュメントの印刷が終了していなかった場合は、そこで印刷を行うように変更した。
この修正は1.8.0.1で行われた。
背景画像がno-repeat、repeat-x、repeat-yのいずれかだった場合、
その画像が非常に小さく印刷されてしまうというバグ。
プレビューでは問題なく、印刷時のみの問題なので、ピクセル値の解釈の仕方に問題があることが分かる。
実際に、背景画像をレンダリングする際に、そのサイズをピクセル値そのものとして扱っていて、 CSSの特例措置である、極端に解像度が異なるデバイスへの出力時にピクセル値を適当に変換する、 ということが行われていなかったのが原因。
この修正は1.8.1で行われた。
印刷のセットアップダイアログで、マージンに一部の値を指定した場合、正しく記憶されないというバグ。
内部ではインチで処理していることは有名な話なので、それによる誤差が出てしまっているものと思われたが、 実際には小数点以下、8桁で計算されているので、ミリメートルに変換したところでその誤差が出ることは無い精度だった。
本当の理由はもっと単純で、保存していた値を表示する際に、四捨五入せずに、 切り捨てていたのが原因だった。
この修正は1.8.1で行われた。
印刷プレビュー時に、フレームの上や、 ページのマージンの上にカーソルを置いた状態でマウスのホイールでスクロールしようとしても、 何もスクロールしなかったバグ。
単純に考えると、印刷プレビュー時にサブフレームがスクロールすることはあり得ないので、 ホイールのスクロールイベントをルートに伝達するように修正した。
ただ、フレームに関する問題は微妙で、
印刷プレビュー時に親ドキュメントのPresShellを取得する論理的に正しいコードが今のところ存在しないと思われる。
この修正前のコードでは印刷プレビュー時にもかかわらず、
フレームの親PresShellは通常表示用のPresShellを取得してしまっていた。
今のところ、Geckoを採用しているプロダクトの仕様上、この問題が表面化することは無いが、 将来的にUIの仕様が変わって、ひとつのドキュメントを多岐に渡る形式で、 しかも同じ形式を複数のインスタンスで表示させようとすると、 今のGeckoでは破綻してしまう(表示そのものは可能だが、イベントハンドリングでは大問題)。
この修正は1.8.1で行われた。
Firefoxで名前を付けてリンク先を保存しようとしたときに、そのリンク先のファイル名がUTF-8以外でエンコードされていると、 文字化けしたファイル名がデフォルトの名前になってしまっていたバグ。
URIのオブジェクトを生成する際に使う、予備の文字コードがnullになってしまっていたため、 UTF-8で常にデコードされたのが原因。
また、名前を付けてリンク先を保存する場合、documentオブジェクトはnullなので、それも原因の一端となっている。
documentオブジェクトがnullの場合、リファラの文字コードを利用するよう修正した。 名前を付けてリンク先を保存する場合、リファラが、そのリンクのあったdocumentの文字コードと一致するためである。
この修正は1.8.0.1で行われた。
bug-org 314222のSeamonkey版。
パッチの内容自体は若干異なるが、原理はbug-org 314222と全く同じ。
この修正は1.8.0.1で行われた。
自動アップデート中に表示されるウインドウに日本語を表示しようとすると文字化けするというバグ。 ただし、Win9xでのみ。
1.8で修正した、インストーラの文字化けと全く同じバグ。
ダイアログの初期化時にシステムフォントを取得して、
それを問題のウインドウにWM_SETFONTで通知した。
この修正は1.8.0.2で行われた。
bug-org 316663の修正でMinGWでビルドできなくなってしまったというバグ。
CreateFontIndirectAとDeleteObjectを利用するために、
gdi32を読み込む必要があった様なので、makeファイルをそのように修正。
この修正は1.8.0.2で行われた。
RSSがUTF-8以外でエンコードされていると、ライブブックマークが文字化けするというバグ。
ライブブックマークのコードが使っていたRDFのパーサの仕様が変更されたのが原因。
RDFパーサの別のAPIを使い、バグが発生する前と同じコードをライブブックマーク側に追加して修正。
この修正は1.8.1で行われた。
メッセージボックスでは各ボタンにアクセスキーが設定されていないが、それはこのバグが原因。
キャプション内の文字にアンパサンドを付けて、アクセスキーを設定する方式なのだが、 メニュー等で利用されている、自動的にアクセスキーをキャプションの最後に追記するオプションが有効になっていると、 アクセスキーが二重に表示されてしまうというバグ。
単純に言うと、最後が括弧でくくられたアクセスキーか、もしくはそれにコロンが付いた状態なら、 アクセスキーを新たに追加しないように修正している。
この修正は1.8.1で行われた。
border-style: double;で二本の線が異なる太さになったり、描画が綺麗ではないというバグ。
独自ビルドで有名な綾川さんがパッチを原案を提案してくれ、それを私が手直しして、 レビュー依頼等を代行したバグ。
Gecko内部ではtwipというピクセルよりも細かい単位で算出を行っているため、 ピクセル値を求める際に四捨五入により、同じ指定値でも、場所によって誤差が出てくるのが原因。
まず、borderの太さを算出する際に、ゼロでは無い場合、最低限1pxは確保するようにした。 これは、いかに細くても、ページの作者には線を引くという意図があったということなので、 それを尊重した形である。
次に、そのborderが3pxに満たない場合、二重線として描画することは不可能なので、
solidとして描画するようにした。
また、ridgeやgrooveの場合も2pxは必要なので、1pxしか無い場合は同様にsolidと読み替えるようになっている。
そして更にborderの外側から、内側に向かって実際の太さの算出を行うことで、
doubleの二本の線は常に同じ太さになるようになっている。
だが、border-style: dashed;とborder-style: dotted;に関しては、
また別の関数で描画されているため、残念ながら、修正できていない。
この修正は1.8.1で行われた。
画面内に納まりきっていないリンクをクリックした時にそのリンクを表示しきれるようにスクロールしてしまい、 肝心のクリックイベントが無視されてしまうというバグ。
イメージマップではとくに発生しやすく、意図しない場所(リンク)をクリックしてしまう原因になっていたため、非常に不人気なバグだった。
もともと、任意の期間、自動スクロールをオフにする機能は用意されていたので、 リンクに関するクリック関連イベントの最中は、要素のフォーカス取得時の自動スクロールを行わないように修正した。
この修正は1.8.0.1で行われた。
画面内に納まりきっていないリンクを右クリックしてコンテキストメニューを出すと、相変わらずスクロールしてしまうというバグ。
上記バグでクリックイベント中の無効化には成功していたが、 ポップアップしたコンテキストメニューを管理しているコンポーネントが それ以外のタイミングで右クリックされた要素にフォーカスをあわせていたため、自動スクロールがまだ発生するままになっていた。
このフォーカスを設定する間、自動スクロールを一時的に無効化するように修正。
この修正は1.8.0.1で行われた。
オフィシャルブランディングのビルドで、初回起動時にIEから設定をインポートしようとしても、 言語設定(accept languages)がインポートされなかったというバグ。 また、同様の問題で、プロキシ設定もインポートされていなかった。
PrefServiceを使ってMozilla/Seamonkeyからのホームページ設定を読み込むのだが、
それをリセットする時にインポート済みの設定ごとリセットしてしまっていたのが原因。
ホームページ設定を読み込んだ段階で先にリセットしてしまうようにリセットのタイミングをずらすことで修正。
この修正は1.8.0.2で行われた。
上記修正で発生したregression。 オフィシャルブランディングのビルドでのみ、Mozilla/Seamonkeyからのホームページの移行に失敗していた。
前回の修正で、PrefServiceが保存先を再設定していたコードまで削除してしまっていたのが原因。
問題のコードを復活させて終了。
この修正は1.8.1で行われた。(1.8.0系での修正は未定だが、そのうちに申請予定。)
インポートしようとするお気に入りのフォルダが、'\'か、'/'で終わっているとそのフォルダのインポートに失敗するというバグ。 これらの文字はWindowsではパスには使えない文字なので、日本語の2バイト目にこれらの文字と同じコードがあると、バグが発生する。 たとえば、「表」等。
NSPRのバグで、マルチバイトを全く意識しないパス処理を行っていたのが原因。
この修正は1.8.0.2で行われた。
オートコンプリートのリストがポップアップした状態でマウスホイールでページをスクロールすると、 ポップアップが閉じずに、スクロールにも追尾しない、というバグ。
ドロップダウンリストではページをスクロールするとポップアップが即座に閉じるようになっている。
そこで、オートコンプリートのコントローラで、
ホイールスクロールを検知できるようにnsIRollupListenerを追加し、
ホイールスクロールが発生した時にポップアップを閉じるように修正した。
この修正は1.8.1で行われた。
ロケーションバーのドロップダウンを表示した状態で、右端のドロップダウンマーカーをクリックすると一瞬、 ドロップダウンリストが消えるが、その後すぐに再表示されるというバグ。 上記、bug-org 187772のregression。
上記バグの修正で、マウスのイベントでポップアップが閉じられた場合、 そのイベントを破棄せずに処理されるようにしていたため、 マーカー上でクリックしたことによってリストが閉じられた後、そのイベントが通常通り処理され、 即座に開き直していたというのが原因。
ポップアップの主体となるnsIAutoCompleteInputからイベントを破棄するか、
ディスパッチするかの選択を行えるように修正して、
ロケーションバーのケースを特殊なケースとして処理できるようにして対応している。
この修正は1.8.1で行われた。
ロケーションバーのドロップダウンリストが表示されている状態で、 URLを貼り付け、Goボタンをクリックして移動しようとしても、そのイベントが破棄されるので、 もう一回クリックしないといけない、というバグ。
Bug-org 339661の修正により、 ドロップダウンリストが閉じられる時のマウスのイベントを破棄するようにしたのが原因。
まともな修正方法が思いつかなかったが、重大な問題なので、 マウスでマーカーをクリックして開いた場合はそのままとし、 貼り付けを含めた、入力もしくは、キーボード操作によって自動でポップアップが開いた場合はイベントの破棄をやめることにした。
当然、Bug-org 339661と同じ問題が、条件限定で発生するが、 普通ではありえない手順なため、これが妥協点だと考えている。 根本的に修正可能な人が居たら、修正してみて欲しい。
この修正は1.8.1で行われた。
ロケーションバー以外のエディタがフォーカスを持っている時にロケーションバーのマーカーをクリックすると、 リストが表示された直後にそのリストが閉じられるというバグ。
エディタがフォーカスを持つと、オートコンプリートのコントローラが、そのエディタとリンクされる。 その状態のままマウスの操作でロケーションバーのドロップダウンリストを表示しようとすると、 マーカーのマウスダウンイベントでリストがポップアップするのだが、 その後、そのクリックによってフォーカスがロケーションバーに移るとオートコンプリートコントローラが再リンクされるので、 その際に古いポップアップが破棄され、閉じられてしまうというのがこの現象の理屈。
マウスダウン時にリストを表示させる前にフォーカスを強制的にロケーションバーに移すようにすることで修正。
この修正は1.8.1で行われた。
感謝の意を込めて、Gecko1.8の開発サイクルにおいて、お世話になった日本の方々の名前を挙げておきたいと思います。 (貢献したのに、名前出てないよ、という方が居たらごめんなさい。連絡をください。) これらの方々の協力が無かった場合、Gecko1.8.1及び、Firefox2、Thunderbird2の品質は実際のものよりも大きく低下していたでしょう。 皆様、本当にありがとうございました。そして、Gecko1.9でもご協力、よろしくお願いいたします。
パッチ提供
Bugzilla-jpでのテスト、検証
他にも、
敬称略(Bugzilla-jp、もしくはBugzilla-orgでのユーザ名で表記しています)