この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
どうやら、bfcacheに大きなバグがある模様。bfcacheが非表示になったページのオブジェクトを参照したままになっているのはバグのようだ。どうも、フレームのようなサブドキュメントが解放できていないらしい。(親ドキュメントのみが解放されている。)デバッグ実行でもそれが確認できている。Borisは1.8リリース前に修正しないとヤバイと言っているが、どうなることやら。
リリース日を優先するか、クオリティを優先するか、Mozilla Foundationの判断はどちらになるやら。
Trunkではとりあえず修正完了。
bfcacheのバグは、bug-org 314549へ分離された。
パッチがfindBar.js全行に絡むため、直接交渉の結果、即決で修正完了。(途中で、別のパッチが混入すると一から作業やり直しになるため。)
あまり十分にテストできたとは言えないので、明日のNightlyビルドでブラウザの機能が途中でキャンセルされているような症状を見つけたらバグ報告して欲しい。多分、このバグのregressionだ。(レビュー完了前のパッチでは、タブの切り替え処理が途中でエラーとなり、全て走らなかったバグがあった。)
ちなみに、この修正で早くも1.8 BranchとTrunkの検索周りのコードに互換性は無くなった。
Operaは未だにvertical-alignという基本的なCSSプロパティの解釈が実にバギー。
CSSマニアックスという感じのタイトルが似合う、非常に非現実的なコンテンツの表示テストに合格するよりも、一般的に使用頻度の高いCSSのバグ修正を優先すべきだ。(Acid2テストではvertical-alignはbottom値しかテストされない。)
こんな指標があるなら、各社がマーケティング上のアピールの為にこれに絡むバグを優先的に修正するのは当然、想定できたはずだ。結果としてそれは良い方向に進んでいるのだろうか? 私はそうは思えない。
WaSPが業界全体の限られたリソースをこんなテストの修正に向かわせた責任は大きいと思う。どうせなら、もっと現実に則したテストを作るべきだったはずだ。どんな文書でも絶対にと言って良いほど使われているtext-decorationすら、全くテストされていないというのは納得できない。
FAYTの時に、Find Toolbarを非表示のままで検索できるようにしてほしいという要望。 当初、FAYTを無効にするオプション追加の要望かと思って請け負ったのだが、コメントを見ていておかしいことに気づいた。
Find Toolbarのエディタが無いと、当然IMEは動かない。また、キーボードレイアウトによってはキー入力から文字を合成しなくてはいけなくなる(アクセント記号が絡んだ場合や、タイ語もかな?)。こんなことはJavascript上では不可能だ。(こんなもの、OSレベルでやるべき話である。)
結果、wontfixとしたが、やっぱりASCIIな人から、なんでやねん、というコメントが付いていた。一応、他言語の処理についても簡単に説明を書いておいたし、Mike Connorがverifiedとしてくれたので一応決着。
やっぱり、猛烈に反論が出てきてる。でも、現在のコードすら見たこと無い、建設的ではない一方的な要望ばかり。SeaMonkeyから移植した当時はちゃんと動いてたじゃないか
なんて言う始末。SeaMonkeyのFAYTのIME処理なんていい加減きわまりない。幸せだったのは、一部のロケールの人だけだったという自覚も無いようで。
開発者のコミュニティに要望を書くときは、技術的に筋の通った詳細な案も共に出さなくてはいけないと思うのだが、世間ではそうではないらしい(笑)
えむけいさん(VYV03354さん)が修正してくれた。素晴らしい。ただしTrunkのみで1.5では修正されていないので注意。
ローゼンメイデン・トロイメントの第一話(BS-i)に字幕スーパーで多々、地震速報が混入。しかも嫌がらせのように、更新間隔が短く同じ情報を何度も流すし、Bパートに入っても流し直すし。勘弁してくれ。前作をDVDで買ってないので、今回も買う気は無いのでキャプチャしてたのに。
ちなみに、TMPGEncによるMPEG2エンコード時間が最短1時間40分だったのが、同じ条件で50分に短縮できている。素晴らしい。
スラドのコメントからリンク張られてた文書ですが、あまりにアレで、数時間かけて読んでしまいました。
中国・韓国・北朝鮮関係の一連の問題って、向こう側の戦略として文句言ってるんだから、言わせときゃええやんって感じだったんですが、このリンク先の三つ目のドキュメントは本当の話なら恐ろしいことです。ってか、在日って税金納めなくても、生活保障されてるってどういうことよ。私なんて去年は所得はゼロ円でしたけど、何か?
そういやスラドと言えば、アニメータの平均給与の話がありましたが、少ないですねぇ。私も同じように好きなことを仕事にしててこれよりは年収が上になりそうなので、幸せといえば幸せなのかなぁ。まあ、この手の話が出てくると、なんでも趣味でやってる内が丁度良いもんだと思います、本当に。
愚痴ついでに、バグ(要望含む)をinvalidやwontfixにするという作業はバグを修正するより大変なことなんだと改めて認識させられました。無責任に要望書くのはやめてください、本当に。
今日だけで、四つのパッチを提出してる。なんでだろう。とりあえず疲れたので寝る。
新設計のパッチが概ね完成。しかし、またしてもSeaMonkeyのFAYTが障害に。とりあえず、フレームじゃないページなら、概ねFAYTも動くようにはなってきてるものの、フレームをまたいで検索する時の処理が元々おかしいようで、選択色がシステム標準のものに戻ってしまう(このタイミングでFAYTの入力受付終了とするしかないので、非常に辛い状況)。細かいバグは無視して行って、後でリファクタリングする方が良いかもしんない。
修正完了。
昨日未明から、突然あるアカウントがスタッフ(私)の警告を無視して、適切に変更していたステータス等の情報を勝手に(しかも多くの場合、変更理由も書かずに)書き換えるという荒らし行為が多発した。現在、該当のアカウントは利用停止措置の対象となったが、どうも同一人物が新たにアカウントを取り直して活動を継続しているように見える(本人は気づいていないようだが、文章の癖が非常に似ている)。ちなみに、どちらのアカウントにもメールを出したが、何の返事も無い。特に、同一人物では無いですか?とストレートに問い合わせた、後者へのメールにまで返事が無いというのはおかしい。違うなら反論するだろう。
ちなみに荒らしのあったバグはBug 4731である。バグの動きを見てもらえれればいかに、ひどいか分かる。私は当時、IME無効化のパッチの作成とテストを繰り返していたが、02時37分51秒からはじまった、荒らしにより、少なくとも03時10分46秒まで、この荒らしのために仕事にならなかった。(実際にはその後も対応策を検討したりして、もっと時間が奪われている。これはMozilla Japanの仕事として活動している身からすると実際に損害が出てしまっていることを意味する。)
また、該当の報告者は、comment 6で次のように臆面もなく言い放っている。
Safeモードに切替える方法と Nightlyビルド方法を記述した 日本語説明のＵＲＬを示して下さい
これが開発現場で発言する内容だろうか?
ちなみに、バグ報告ガイドラインには次のように書いてある。
次に、必ずそのバグを三日以内にビルドリリースされた物を使って再現してください。私達の開発プロセスはものすごく速く進んでいるため、あなたが見つけたバグはすでに修正されているかもしれないからです。（ナイトリービルドは mozilla.org バイナリページからダウンロードすることができます。）
バグを報告するにあたって、Nightlyビルドでのテストは必須となっているし、ダウンロード先も明記されている。つまり、バグ報告をする人間にとっては常識でなければいけない部分がまず欠落している。
で、結局私も感情的になってきて以下のようにコメントを追加した。
ステータスを勝手に変更するな、と言っているでしょう? これ以上、「荒らし」行為を続けないでください。
この発言(03時02分)の後、まだそれでもステータスを一度修正しに来たが、それも再度修正しなおすと、反応が無くなった。
当然、ピンと来る。こんな奇妙な行動をとる人が次にやりそうなこと、2ちゃんねるかどこかのBBSで自分の正当性をアピールしようとするのではないだろうかと。実際、すぐ(03時06分16秒)にそうなった。
- 663 ：名無しさん＠お腹いっぱい。：2005/11/12(土) 03:06:16 ID:I62aI0DJ0
- こんな報告が出ています
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=4731- 664 ：名無しさん＠お腹いっぱい。：2005/11/12(土) 03:19:50 ID:I62aI0DJ0
- そのREMINDって何だろう
http://bugzilla.mozilla.gr.jp/bug_status.html- 665 ：名無しさん＠お腹いっぱい。：2005/11/12(土) 03:24:46 ID:I62aI0DJ0
- 以前はターゲットマイルストーン項目に
Firefox 1.0 があったのに消去されている
- 666 ：名無しさん＠お腹いっぱい。：2005/11/12(土) 03:30:06 ID:I62aI0DJ0
- 添付のスクリーンショット画像では
実際にそうなる場合があるらしい- 667 ：名無しさん＠お腹いっぱい。：2005/11/12(土) 03:32:42 ID:I62aI0DJ0
- いづれ Firefox 1.0.7 は使われなくなるでしょう
Firefox 1.5 のリリースが始まりそうだからね- 671 ：名無しさん＠お腹いっぱい。：2005/11/12(土) 03:49:53 ID:15sA9V3l0
- 独り言はよそでやってろ＞ID:I62aI0DJ0
もはや、憐れだ。(ちなみにこれ以降もIDを変えているが、この人のみがageている上に文面も似たようなもので、他の住人から突っ込みを受けている。どうやら、どこを利用するにもいきなり手を出して失敗するタイプの人のようだ。)
しかし、私たちにも反省すべき点がある。ドキュメントの散在、現在の運用にそぐわないドキュメントの放置。だが、これまでの普通の協力者の方々は、bugzilla-jpのスタッフの行動を見て、あわせていてくれていたから問題なかった。(これはすごく運の良かったことなのかもしれないし、その人達の協力のおかげで現在の製品のクオリティは確実に上がっているのだから感謝してもしきれないものがある。)
今回の荒らしも私たちに運用の厳格化、ドキュメント整備の加速を促した点では貢献したと言えるかもしれない。だが、今後も継続して別アカウントで似たようなことを繰り返すのであれば次のGecko 1.9(Firefox 3.0?)のクオリティは確実に本来のものより下がるだろう。これは誰にとっても不幸なことだ。
ところで、この人(達?)に共通する点は何かと考えてみると、開発者を便利な駒として考えているのではないだろうかという点だ。もじら組BBSでもBugzilla-jpで軽く聞いてみた
という発言があったことからそう思う。(本家bugzillaも含め)Mozilla界隈でこれほど無礼な人は今まで見たことがない。
SeaMonkeyのFAYTは見捨てる?
という話も出てきた。Find Toolbarを移植できれば問題は全て解決できるのだが、まだ、FirefoxのFind Toolbarも非常にバギーなので私は現時点では移植したくない(同じ修正を二重にレビューして、チェックインするなんてやってらんない。ちなみに、ブランチの修正はこれに近い、結構な重労働)。
SeaMonkeyをtoolkitベースで作り直してくれれば誰もが幸せになるのだが、そういう話は見ないからなぁ。
ついに修正完了!!(現時点では、まだ全環境でのビルドに成功してないけど)
結局、SeaMonkeyではFAYTでIMEが使えなくなった。その理由は、
ということ。ただし、FirefoxのFAYTもまだ大量に細かいバグを持っているため、これの修正が終わってから作業に入ることになる。申し訳ないが、SeaMonkeyのTrunkユーザはしばらく我慢して欲しい(どうしても我慢できなければ、コードを書いて欲しい。Firefoxに原型があるのだから、一から作るわけではない。その場合は最大限、サポートさせてもらうつもりだ。私のFAYT向けの仕事は確実に増えることになるが、それを理由に断ることは無い。)
IME APIがこれで完全にフリーズしたので、Mac/Camino/Photon/Xlib/GTK/GTK2/BeOSでこれに対応するためにIME制御のコードを書くだけで、他のOSも問題が修正される。是非、力を貸して欲しい。
ひとつだけテストして欲しいことがある。Geckoを使ったコンポーネントブラウザのIME制御をこのバグの修正で駄目にしてしまっている可能性がある。(例えばURLバーでIMEが有効にできない等)
今現在、テストする手段が分からないので誰かテスト、もしくは情報をフィードバックして欲しい。よろしく。
VC6でビルドに失敗したので一時的にバックアウトした。現在、再チェックインの準備中。
パッチを少し手直しして、VMWare上のVC6で確認してから再チェックイン。
完全に終了!
予想通り、色々とregressionが報告されている。報告してくれている上に、修正案の提示や、パッチのテストまでやってくれているえむけいさんに感謝。とりあえず、イージーミスだったこのバグは修正完了。
えむけいさんが確認、修正してくれた。さんくす!!
私は無効化にはWINNLSEnableIMEを使っていたのだが、これはWin3.x時代に使われていた廃止されたAPI。MSDNからも削除されていたのだが(つまり今となっては隠しAPI)、私が他にIMEを無効化するAPIを知らなかったことと、DelphiのVCLがこれを利用していたことが、このAPIを使う理由になっていた。
えむけいさんによると、ImmAssociateContextで代用できるとのこと。このAPIそのものの存在は知っていたが、MSDNの説明を見てもその使い道を理解できていなかった。コンテキストの関連づけを解除するということが、IMEを利用できなくなる、ということだったわけだ。
VCLがこの廃止されたAPIを使い続けている理由はなんだろうか? ImmAssociateContextだと、Windowsの特定のバージョンでは問題がある、とかいうのでなければ良いのだが。
ちなみに、WINNLSEnableIMEは引数にウインドウハンドルを持っているが、えむけいさんの情報によると、ウインドウ単位ではなく、プロセス単位でIMEをコントロールしているらしい。どおりで、デバッグ中に、私の意図通りに動いていなかった訳だ。(今思えば、コモンダイアログで期待通りの挙動にならなかった時点で気づくべきだった。)まだまだ勉強と洞察力が足りないなぁと反省させられた。
IME無効化コード内のメソッドのスコープの修正。祖先ではなく、親クラスを参照するように修正した。
IME無効化のコードのバグ。NS_ENSURE_TRUEはコーディング時に想定できない失敗時に利用するものだが、GTK2等の特定のツールキット/OS上では、失敗することが正常なのにこれを使っていたため、デバッグメッセージがすごいことになっていたバグ。こちらも修正完了。
IME無効化に関する問題はこれで一通り解決かな?
SeaMonkeyの件は本家でもめている。 とりあえず、SeaMonkey関係者はFirefoxのFind Toolbarが嫌いらしい。 代替案でなおかつシンプルなものを検討中。 しかし、英語での喧嘩は疲れる。
Bug 4681のregression。修正完了。
どう見ても同一人物だよなぁ。
WinCE上のMinimoで文字を選択すると表示がおかしくなるんで、レビューを頼まれたバグ。 結局、WinCE固有のレイヤーがあったようで、そこのバグの模様。WinCEの場合、
という階層構造になってるんですな。初めて知った。
IMEのもう一つの大きなバグだった、描画色の問題がようやく修正できた。結果、準備にかかったコーディング量から考えると、IME無効化よりもよほど巨大な修正になってしまった。
Windowsの場合、下線のスタイルが実線なぐらいで、他はIEの仕様に概ねあわせてある。 Macは特殊な配色なので、固有の指定を行っているが、他のOS/ツールキット上ではWinと同様の表示になるようにしている。とりあえず、他のOSの文化というか、配色をどうすべきかが分からなかったのでそうしているだけなので、違和感を感じたらバグ報告して欲しい。
一応、特殊色(前景色と同じものを使うとか、40%の色を使うとか、透明にするとか)以外ならprefで変更可能。詳しくはnsXPLookAndFeelのコードを参考にして欲しい。あえて説明しない。
質問やら苦情やら来そうなのであらかじめ書いておくことにする。なお、Windows以外のプラットフォームに関しては先日書いたとおり、Windowsにとりあえずあわせているだけである。
さて、Windows上で赤線を止めた理由は二つある。
一つ目の理由。IMEの未確定文字列を独自描画するアプリケーション(通常は、IME自身に未確定文字列の描画を任せる)と言えば、大抵、Microsoft製のもので、代表的なものにワードパッド、IE、Office製品等がある。これらの製品、それぞれで未確定文字列の表現方法がまたバラバラだ。これは一社の製品としてどうかとは思うが、MS社員ではないのでそれは置いておこう。で、この中でMozilla Japanのプロダクト最大の対抗馬、つまり乗り換えてもらいたい元の製品といえば当然、IEである。IEユーザが移行する時に違和感が無い、というのはプロダクトのひとつの戦略として有効なのでIEの表示にあわせたというのが一つ目の理由である。
二つめの理由。もし、テキスト色と関係ない色を前景の一部である下線に利用すると、背景色とのコントラストが保たれる保証が無い、という点である。たとえば、赤い背景色のエディタの上で未確定文字列を表示した場合、赤い下線が明確には見えなくなる。背景色は推測できているので、背景色が赤い場合には下線の色を別の色で置き換えるというアイデアもあるだろうが、それは難しい。代替色として素直に思いつくのは色空間の中で、中心点を挟んで反対の位置にある色である。Invertと同じ理屈だ。だが、このバグの当初指摘された問題を見ると分かるように、色空間の中心点に近い色の反対色は、元の色に似ているという問題がある。(この説明が分かりにくいなら、直線を思い浮かべて見ると良い。直線の両端を白と黒とすると、この直線はグレースケールを表現できる。中心が50%のグレーということだ。ここで、49%のグレーについて考えてみると、これの反対色は中心、50%から1%逆方向にずれた色になる。つまり、49%グレーの反対色は51%グレーだ。これは人間の目にはほぼ同じ色に見えることが分かるだろう。)これはどのような色空間を用いても解決できない。反対の色を使おう、というアイデアそのものに問題があるからである。
ちなみにIEでは下線を破線で表現している。これは現状でも太さの制限を考えなければ破線で行えるのだが、WindowsのGDIの昔からある問題で、太い破線を描画するには自前で描画しなくてはいけない。そこで、これはtext-decorationのCSS3対応が終わってから改善することにした。つまり先送りしているだけで構想はあることに注意して欲しい。
Regression出してしまった。1.8branchでも再現するので注意。 パッチは既に提出しているが重大な問題ではないため1.8finalには入らない予定。(1.8.1?)
iframeを選択、またはifram内の文字列を選択して、選択した部分のみを印刷しようとしても進捗ダイアログは出るものの、進行しない(フリーズするわけではない)。
対応策は、iframeをShow Only This Frameで単体表示して希望の操作をすることのみ。
珍しくこんなマイナーなバグが修正されていた。
MS (P) ゴシック/明朝フォントのバグだったのだが、斉藤さんがsuperscriptやsubscriptの設定値が異常な場合は補正するように修正してくれた。
ちなみに、その疑惑のFOX氏がさわってる回りのバグがgogogood氏から報告されてます(笑)
Thunderbirdのメールのコンポーザもそうだが、HTMLエディタ上のノードの末尾(行末とか)でIMEを使って未確定文字列を入力できるところまでは良いんだが、変換するとNS_ASSERTIONにひっかかる。HTMLエディタのクラッシュバグとかにつながってないのかな。Thunderbirdでメール作成中にクラッシュしたら、talkbackを送信して、そのIDと共にバグ報告してみて欲しい。
日本語のサイトでもtext-align: justify;を使うサイトが増えて欲しい。自分で修正しておいてなんだが、この修正が一番のお気に入り。
Thunderbirdのコンポーザのメール本文の部分が(Plaintextモードでも)HTMLエディタなのだが、そこで文字列を選択せずに再変換を行うと、Deleteキーを押したのと同じことが発生していたというバグ。
もともと、bug 4436の原因をMiharaさんが再変換処理にあることを突き止めてくれたことで発覚した。
このバグを修正したことで、bug 4436も発生しなくなったようなので良い感じだ。Miharaさんの協力に感謝。
アラートのウインドウがにょきっと出てくる時にCPUパワーをすごく使っているというバグ。本家を探しても同様のバグが見つからなかった。とりあえず、wontfixとした。
ソースコードを見てみると、アニメーションの設定を細かく指定できるようになっているので、アニメーションが重い場合は次の設定を変更してみて欲しい。
alerts.slideIncrement一フレームで何ピクセル、ウインドウを大きくするか。初期値は1(ピクセル)。
alerts.slideIncrementTime一フレームを何ミリ秒とするか。初期値は10(ミリ秒)。
フレーム数を半減させて、一フレームで元と同じだけウインドウを大きくすれば、アニメーションのなめらかさと引き替えにパフォーマンスを向上させることができる。例えば、alerts.slideIncrementを2、alerts.slideIncrementTimeを20とすると、20ミリ秒に一回、2ピクセルずつウインドウが大きくなるので、コストを半減できる。