この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
タブバーにスクロールボタンが付いて、タブをスクロールできるようになったものの、そのボタンが小さすぎて不評な様だが、ホイールでもスクロールできる模様。
ただ、スクロールが速すぎるように思う。
2日ほど私用で昼夜逆転してる普段の生活をさらに逆転させて生活していたため、不調でモチベーションも下がってましたが、ようやく再びいつものペースに戻せて、回復してきました。またがんばらないと。
それと先日、原因不明なのですが、メールボックスの容量がいっぱいということでエラーが返ってたことがあったようです。今のところ来てるメールの数からして正常に戻ってるんではないかと思います。もし、期間中に私にメール出したけど、返事が無かったとか、エラーで送れなかったという場合、再送信お願いします。ご迷惑をおかけしてたらすみませんでした。
gfxPangoFonts、非常に問題が多いように思う。このソースはLinuxとBeOSで共有しているが、gfxWindowsFontsに比べると高級なpangoに頼りすぎていて、pangoとCSSのフォントの選択仕様の違いが色々なバグを生んでしまっている。
特に、アルファベット混じりの日本語テキストではpangoはかなり期待にそぐわない結果を返してくれる。 例えば日本語123日本語abc123という文字列があった場合、pangoは次のセグメントに分割する。
この例で、前者は日本語、後者は英語という判定が下される。
多くの場合、thebesはデフォルトフォントに日本語フォントを、コンテキストにも日本語であることを明示的に設定しているが、pangoは後者に対して、日本語のフォントを(ASCII文字も表示可能にもかかわらず)採用せず、システム設定から英語のフォントを探して採用してしまうようである。そのため、特定の言語に含まれない、数字等のニュートラルな文字は周りの影響を受けてしまい、出力結果が常に同じフォントとは限らないという、バカバカしい問題が発生する。
この問題に対して、pangoの処理単位をニュートラル部分のみ独立して処理させることで、ニュートラル文字の問題に対応しているパッチは出したが、これだけでは、最初の言語毎にフォントを勝手に変更してしまう問題を解決できない。
gfxWindowsFontsの様に、文字列を言語ごとに分割してから、アイテムごとに、コンテキストのフォントと言語の再設定を逐一行い、pangoにレイアウトさせるしか無いのだろうか。
Bugzilla等でリストボックスをホイールでスクロールしていると、そのスクロールが限界になった途端、祖先(例えばページ全体)がスクロールされるのは良くないというバグ。なんとか、これでどうだろうか、という仕様で修正を入れてみた。
こういうバグはユーザの感覚に違和感を与えずに配慮ある挙動をしなければいけないので非常に難しい。実際、作業に入ってから既に二ヶ月ぐらいかかってしまった。
まず、現状の動作に何故違和感があるのかを考えてみた。Matsの言う、hierarchical scrolling
に問題があるのは間違いない。これは、ホイールが回された要素から順に祖先に辿っていき、最初に見つけたスクロール可能な要素でスクロールを行うというもの。つまり、ホイールを回す度にスクロールする要素を探すことになる訳だが、ユーザはスクロールしたい要素を一度だけ決め、連続してホイールを回すわけだから、ここに齟齬があることが分かる。そこで、複数のマウスホイールのイベントを一つのトランザクションとしてまとめてしまい、そのトランザクション内ではひとつの要素でのみスクロールイベントを処理することでこれを解決できるはずである。
では、どのような基準で複数のイベントをひとつのトランザクションとするか、という点が問題になる。まとめすぎるとスクロールしたい要素がスクロールしなかったり、まとめ方が不十分だと、このバグのように不満が出る。
まず最初にトランザクションの切れ目として考えたのは各マウス、キーボードイベントである。マウスやキーボードを操作するということは、スクロール以外のことをユーザが行ったということなので、間違いなくその前後でトランザクションは異なるはずである。しかし、ホイールを回すとき、マウスが移動してしまって、そのイベントで分断されてしまっては元も子もない。そこで、デフォルトでは0.5秒間はマウスの移動を無視するようにしている(マウスの移動イベント自体はそのまま処理される)。これはmousewheel.transaction.ignoremovedelayで調整可能である。かなりテストした結果、この時間で長すぎず、短すぎず、丁度良いと思う。ただし、この時間内であっても、カーソルがスクロールターゲットの要素の外に移動した場合はトランザクションを終了するようにしている。これは、違和感を無くすためである。
そして最後まで悩み続けたのが(今も良かったかどうかは懐疑的)なのが、タイムアップによるトランザクションの終了である。例えば、マウスを動かさないままでホイールを回して特定の要素をスクロールしたとする。そして、一時間放置して、マウスを移動させないままホイールを回したとする。この場合、前回スクロールした要素ではなく、従来通り、カーソルの下にある要素がスクロールされるべきだろう。これはマウスでは非現実的だが、ノートのタッチパッドなんかでは起こりやすいかもしれない。そこでこのタイムアウトを3秒にしてみた。テキストを読みながらカーソル位置を確認せずにホイールを回し続けた場合、この時間では不足かもしれない。そこで最初は120秒に設定してテストしていたのだが、原理を知っている私でも混乱することがしばしばあった。そこで、最終的には3秒にまで縮めて、とにかく違和感、混乱を与えないようにしつつ、できる限りトランザクションを維持するようにしてみた。しかし人によってはまだこれでも長いと感じる人も居るかもしれない。その意見があるようなら、さらに時間の短縮を試みる必要があるだろう。こればっかりはNightlyでより多くの人にテストしてもらわないとどうしようもない。ちなみにこの時間はmousewheel.transaction.timeoutで修正できる。
これらの設定を共にゼロに設定すると従来と同じ動作になるが、新しい挙動になれると、やはり従来の挙動は不便に感じると思う。ただ、新しい挙動がベストである自信はいまだに無い。
Firefox1.0.x時代の悪夢、世界同時リリース不能の原因となったインストーラの問題を今回は未然に防ぐことに成功している。
経緯を見ていると、Kazabanaさんの書き込みに理解を示してPiroさんがオタくさいものはFirefoxのブランド戦略に反する
という結論に基づいて削除されたようなんですが、その行動、決断は尊重できますし、池田さんや他の方の意見にも特に問題は無いと思うのですが、現状、後から見た私にとっては、削除された画像は既に無い、削除された理由もSpread Firefoxとは直接関係のない池田さんのblogのコメント欄を全て読まなくてはいけない、というのはあまりにも説明不足のように思います。
そのため、その是非はともかくとして、第三者がヲタ系の絵をSpread Firefoxで出したいという要望もあったとしても、この状態を中途半端に知っている人はまず出せないと思いますし、また知らずに出したところで、今回の騒動を中途半端に知っている人から、不適切な形で非難される可能性があります。これは非常に良くない状況だと私は思います。せめて公開を広告したLatest topicsでだけでもより詳細に説明すべきだと思いますが、どうでしょうか?
昨日入れたパッチでしばらく使ってみたが、時々混乱させられる。主に、ページ全体をスクロールした後に、リストボックス等、より狭いところをスクロールしようとマウスを移動させた時にも元の祖先がスクロールされてしまうことがある。マウスの移動を無視する0.5秒という初期値は長すぎるのかもしれないが、0.1秒にすると、意に反してリストボックスがスクロールされる時があるし、0.2秒にするとまだ混乱がある場合もある。単純に0.15秒あたりが良いのか??
意見求む。
1.8 branchにもチェックイン。Thunderbird 2.0では修正される。
Bug 5130が1.8 branchにチェックインされたので、こちらも同時に修正されている。
お、いよいよ実装が始まるみたい。
Windowsのcairoビルドでスクロールバーのサムをゆっくりとドラッグすると、スクロールバーの背景が変に描画されていたバグ。
修正されている。
こういうバグが修正されると、見た目で分かるのでなんか完成度が一気に高まったかのような錯覚を覚える。でも実際にはまだまだ仕事は大量にあるので、ひとつひとつみんなで潰していくしか。
Bug 1476でチェックインしたパッチが予想外のregressionを引き起こしていて、Thunderbirdでは欧文のメールを送信すると(format=flowedになる文字コードで)、内容が若干改変されるので注意。具体的には、URLの最中に半角スペースが挿入されるので人間の見た目での文意は変わらないものの、MUAの挙動が変わるので注意。また、欧文メールのコピーも愉快なぐらいにぶっ壊れていて使い物にならない。日本語のメール(ISO-2022-JP使用)でも問題が無い訳でも無いので、Trunkを使っている人は13日以前の物に戻しておく方が吉。最悪の場合、Bug 1476のバックアウトも検討しなければいけなさそうだが、パッチ案は既にあるし、シンプルになりそうなので、なんとかなるかも。
Latin1テキストの折り返し仕様をブラウザ毎に雑に見てみると、こんな感じ。
Operaは極端に折り返し文字が少ない。この辺も高速レイアウトに関係あるのかもしれない。
ちなみに、IEとの完全互換は現状の設計ではパフォーマンスを犠牲にしないと難しいし、IEの折り返しにも欠点はあるので、そこまではやらない。
Linuxユーザにとってたぶん、不愉快度ナンバーワンだったんじゃないかというバグ。
cairoをバージョンアップしたことで修正がようやく取り込まれたようだ。
CtrlもしくはAltとなんらかのキーを押した時のイベントがおかしいというregressionに対するパッチをようやく投入。以下のバグが修正できている。
基本的にはCtrl、もしくはAltとなんらかのキーを押すと、入力された文字で素直にイベントを生成するようにしたが、Text Zoomのための特別措置として、+、もしくは-と共に押された場合、これらの文字が入力されたものとしてイベントが生成されるので注意。よく分からなければテストケースで確認してみて欲しい。
まだ少し時間があるのでできる限り作業は行うが、もう無理かもしれない。
という感じ。特に二番目のが一番きつい。テスト期間が短すぎてリスクが大きすぎるように思えてきた。
正式に断念しました。
本当に必要なのはこれへの対応。もはやJIS X 4051など使い物にならない。(少なくとも、今実装しているコードの時の仕様では。最新は知らない。)
URL折り返しのパッチをバックアウトしました。
ただ無条件にバックアウトするとまた放置される可能性大なので、UAX#14の実装が1.9bまでに間に合わない場合、UAX#14に基づいた、U+100未満限定のシンプルなLineBreakerを今回のようにねじ込むことで1.9finalでの修正を認めてもらう約束はとりつけています。
まずはUAX#14を和訳しなくてはいけませんが、どのみち完全実装は時間的に望み薄だと感じているので、当面はMacのIME制御と、thebesのテキスト描画まわりの改善を優先して作業することにします。
個人的にとても気になっていたバグ。
ようやく修正された。
開発環境 + 雑多なデータ置き場にしていたストライピングのドライブが容量不足になりつつあったので、値段が暴落した500GのHDDに載せ替え。おかげで内蔵ドライブが1台減らせて、省電力化 + 静音化。
でもビルド環境のパスが変更になったので、ビルドでエラーが出るようになってしまった。どうも一部のファイルがビルド環境を絶対パスで保存してしまっている模様。大抵は相対パスなのになぁ。
それからグラボもGeForce6600からGeForce7600GSに。ファンレスになった上に、キャプチャでオーバーレイ表示できなかったバグも消滅。やっぱり噂通りGeForce6600のチップそのもののバグだったのだろうか。VRAMも512MBに増加できたのでVistaのAeroにも対応できるかな。でも相変わらずDual DVIにはできなかったのが心残り。なんで未だにDual DVIよりもD-Sub 15ピン付きのカードの方が多いのだろう。D-Sub 15ピンが必要なら、変換コネクタを使えば良いだけなのに。
明日はDELLに発注した液晶ディスプレイが来る予定。机の上がカオスと化しているのでどうしたものか……
そういえばバイト単価が一番安いHDDがお買い得とは限らない、ということにようやく気づいた。単純に増設する場合ならバイト単価がお買い得なものが「安い」のだが、うちのPCは物理的に限界に来ていたのでより大容量のものに交換するしか手がなかった。この場合、少々高くても容量の大きいHDDを買う方が圧倒的にお買い得。バイト単価だけを見てリプレースし続けると、「買い直し」となる容量でのロスが大きくなってしまうためだ。要するに、100G増やしたい場合、既存の容量 + 50GのHDDのバイト単価が最も安くても、それを二台買うと、既存の容量 × 2の買い直しが足を引っ張り、バイト単価の高い、100G容量の大きいHDDを一台買う方が結果的に安上がりということ。考えてみれば当たり前なのだが。
鎌倉でも聞かれたし、前々から聞かれることが多々あったので一応理由を書いておく。ただし公式情報ではないので注意。
拡張とはなんぞやと考えてみると理由は簡単。Piroさんの言う、野良パッチ
という表現が非常に端的で的を射ている。拡張とは本体に組み込む手続きをとらなかった、もしくは手続きを行ったものの拒否された、開発コミュニティ非公認のパッチである。つまり、これを正式にプロダクトにバンドルさせるということはあり得ない。他のソフトウェアでこのようなことが行われているのだろうか? 私はそういう事例を知らないし、賢明な話とは思えない。もし、拡張の中にスパイウェアが含まれていたら? 考えただけでもぞっとする検証作業が必要ということが分かる。
仮に、開発コミュニティが奴隷のように働き、その結果、いくつかの拡張をバンドルすることになったと仮定してみよう。当然、開発コミュニティはその拡張のメンテナンス義務を持たなくてはいけなくなる。つまり、ツリーにコードを取り込み、ビルドシステムを修正して拡張をビルド時に生成できるようにし、インストーラに取り込まれるように修正し、bugzillaにコンポーネントを新設してバグ報告を受け付け、バグが報告されれば修正をしなくてはいけなくなり、コアやそのベースとなるFirefoxやThunderbirdを修正する際にはそれらの拡張についてもregressionが発生しないようにパッチ作成時にテストが必要となる。これはとても非現実的な話で、開発ペースは間違いなく鈍るし、Mozilla Corporationはもっと多くのフルタイム労働者を雇用する必要が出てくる。拡張の作者がメンテナンスを続けるから良いんじゃないかなんて楽天的な話は当然通用しない。いつまでも拡張に対してボランティア活動を継続してくれるとは限らないし、フルタイムで雇おうにも、なぜ元々、大抵の拡張作者は本体をハックするという行動をとらずに誰の承認も必要の無い開発手法を選択したのだろうか? その理由を想像してみると、雇うからやってくれと言われて、「はい、やります。」と言う人はほとんど居ないと考えるのが普通だと思う。
このバグでFirefoxのアイコンファイルが変更されたためにVC++7.1(VS.net 2003)では--enable-official-brandingでビルドするとrc.exeがエラーを返すようになってしまった。
面倒なので作業してなかったけど、2005に移行するしかないか。オフィシャルブランディングを有効にしないとmigrationまわりが一部テストできない。
1.8 branchにもチェックイン。かなり不評なバグな上にリスクが低いので1.8.0 branchにも申請中。