この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
まあ、色々と忙しい訳で、bugzilla-jpにNEWのバグが増えてきていていかんなぁ、という感じです。
で、まあ、Firefox1.5も無事リリースされたので、ちょっとだけ休暇を取ります。12月9日から12日まで完全ではないとは思うもののオフラインになりますので、関係各位、よろしくお願いします。
まあ、例によってウインドウにフォントをきちんと設定しとかないとWin9xでは文字化けしてしまう、というバグ。Branchにも入れたいのだが申請体制がいまいち整っていないように思える。Trunkでは修正済み。
なお、MinGWでビルドできなくなっている。もう、MinGWのサポート止めても良いと思うのだが……
修正完了。やっぱり、理解して論理的にバグをなおさないと、こういうregressionを生むなぁ、と改めて実感。
Wontfixとした。
問題は問題なのだが、修正に値しないマイナーな問題という点と、IMEの操作を再開するとスクロールしたり、候補ウインドウの位置が補正されて問題無くなるので実害がないということで閉じた。
もし、何か実害を見つけたら報告して欲しい。
Geckoではtd[nowrap]をwhite-space: nowrap;として扱うのでバグではないということでInvalidとした。
ちなみにQuirksモードではtable要素でwhite-spaceをデフォルト値に強制的に戻すので問題無い。
そもそもCSSレイアウトのためのStandardモードでテーブルレイアウトを中途半端な知識でやるからこんなことになるのだが、報告者の方は納得できないらしい。曰く、Firefox 1.0.7では問題なかった
ということだが、Firefox 1.0.7のバグだったという可能性の方が高い。今まで自分が見てきたものが正しい、と思いたいのは分からないでもないが、論理的ではない。
問題はこの修正が意図的に行われたかどうかという点が重要だが、1.7 branchと1.8 branchは1年3ヶ月ぐらいの期間があるのでとてもじゃないが、候補対象が多すぎて、どのバグでこのように修正されたのか分からない。(色々と検索してみたが、この手の問題は2001年当時のものしか見つからなかった。おそらく、何か関係ないスタイルシート関連リファクタリングの副作用じゃないかというのが個人的な見解。)報告者の方は
と発言しているが、Web標準仕様で見た目の表現に関して厳密に定義が行われているのはCSSの仕様のみ。HTMLをCSSでどのように表現するかはUAの自由なので、そもそもその理屈はおかしい。UA依存なHTMLの表現に関する属性を使うサイトの作者が全面的に悪い。過去との互換性を盾にQuriksモードでの挙動に注文をつけるのは分かるが、Standardモードでこれほど食い下がってきた人は初めてだ。
td[nowrap]をwhite-space: nowrap;として扱う仕様などどこにも無いから、Web標準化にも当たらない
それにしても、Bugzilla-jpでの決定にあまりに食い下がるのは止めて欲しい。当然、Bugzilla-jpでの決定に間違い、または本家との判断の差はあることはあるだろうから、反論するな、と言いたい訳ではない。有益な反論なら大歓迎だ。ただし、反論するなら、本家bugzillaでの取り扱われ方、仕様書での明記、W3Cのメーリングリストのアーカイブなど、何らかの証拠と共に反論して欲しい。スタッフも伊達に長年、本家の様々な意志決定を見てきたわけではない。今回のように持論のみで反論されてもどうしようも無いのだ。
綾川さんが提供してくれた提案パッチを元に、私が修正を加えて本家とのやりとりを代行して修正完了。
理想を言えば、私のサポート無しにパッチのチェックインまで持って行ってもらえれれば、それに越したことはないが、このように重要なバグで、このレベルの修正案を提示してくれるというのは十分にありがたい。綾川さんがいなければ間違いなく修正できなかったバグなので、当然、ソースコードの権利者には綾川さんもエントリされている。(別に私がアイデアだけ奪い取って、私の仕事とした訳ではないので変な誤解は勘弁して欲しい(笑))
パッチ案がこのように具体的に提出されたのは今回が初めてだが、これはとてもありがたい。是非、他の人も腕試しにチャレンジしてみてはどうだろうか? 常用しているアプリケーションの気になるバグを自分で修正できる、というのはとても楽しいことなのでコードが書けるならチャレンジしてみることをお勧めする。ただし、それなりに私、もしくは自身で本家に持ち込んだ場合ならレビュアとのやりとりがあるので楽な仕事ではないことだけは明言しておく。(つまり、パッチ案は出したので、後は知らない、というパターンはご勘弁を。)
で、肝心の修正結果だが、double、solid、groove、ridgeのレンダリングがとても安定した。まず、一ピクセル未満の太さであっても一ピクセルの実線が描画されることは保証されるコードになった(dottedとdashedはまだこの問題を抱えている)。また、二ピクセルのdoubleは二ピクセルの実線として描画されるようになり、それ以上の太さの場合、二本の線は必ず同じ太さで描画されるようになったので違和感の無い描画結果が得られるようになっている。また、groove、ridgeのレンダリングも安定し、常にボーダーの中央で色が変更されるようになっている。(特に奇数ピクセルの場合の表示結果が安定した。)
綾川さん、どうもありがとうございました。今後ともよろしくお願いします。
それにしても、今、日本人でパッチを書いている人は私以外では綾川さんを含め、何人かおられるが、見事に修正しようとする部分が違っているのが素晴らしい。
最初この一文を見たときに「?」と思ってしまった。「日本人でパッチを書く人が、それぞれ違う箇所を担当している」という意味だろうか?ちょっとよく分からない。
その通り。分かりにくくて申し訳ない。
それぞれに得意ジャンルのようなものがある訳だが、それが異なっているおかげで幅広い貢献ができるようになっている。レビュー制度があるので、コードの品質はモジュールオーナーがチェックしてくれるので、パッチの提供者の作業場所は異なっている方が効率的なのだ。
例えば専門分野が同一な貢献者が二人いた場合、最悪なのが、バグを修正できるか調査する作業段階では、まずbugzillaで担当を名乗り出ることはないので、二人で同じ作業をしてしまっていた、という状況。私も何度か本家関係者とこの最悪のバッティングをやってしまったことがあるが、全く持って無駄な話だ。
昨日のこのバグ、Martijnがテストケースを提供してくれた。
次の画像の左半分がパッチ適用前、右半分がパッチ適用後である。
MinGWでFirefox/Thunderbirdがビルドできなくなっていたregression。意外なほどにスムーズにレビュー終了。すでに修正完了している。
前々から気になっているものの、私自身、この設定が嫌いなので使っていないため、今のところ修正予定が無いのだが、もし、不満に思っている人が多いなら真剣に作業してみても良いと考えている。(ただし、ぱっと修正方法を思いつかないので修正できる保障はないが。)
bugzilla-jp側に、このバグを修正して欲しいと思う人はvoteしてみて欲しい。ある程度投票があれば修正の検討に入ってみる。くれぐれも不要なコメントはjp側にも本家側にも付けないように。
Googleでここの日記を検索すると以下のように表示されるようになった。
見ての通り、タイトルとコンテンツが表示されるようになっている。ただ、コンテンツを絞らずに、show.phpを直接検索してみると、以下のように相変わらずURLの表示だけに終わる。
どうなってるんだろうか。よく分からない。
ちなみに、別の検索キーワードで検索してみると、おかしなことになる。
同じshow.phpが検索結果に表示されているのだが、二番目のスクリーンショットではURLだけしか表示されていないのに、このスクリーンショットでは内容が文字化けして表示されているのが分かる。実に不可解。
ところで、Googleが未だにapplication/xhtml+xmlをサポートしない理由はやっぱり、Win IEがこれをサポートしてないから、検索結果に出してしまうとIEユーザに混乱を与えるとか、そういうネガティブな理由だろうか。だとしたら、application/xhtml+xmlが市民権を得るのはまだまだ先のことになりそうだ。
時々、Trident(IE)、Gecko(Firefox)、Presto(Opera)等のレンダリングの速度を比較している人を見かけるが、これはある意味ナンセンス。確かに、これらはアプリケーションとして存在するので結果、一定条件下での速度差を出すことはできるが、スタートラインが同じ位置にあるという前提に比較している人が多いように思う。(別に速度比較を無意味、意義の無いこととは言っていないことに注意して欲しい。)
GeckoとPrestoの比較はちょっと難しいので、話を単純にする為に、TridentとGeckoの内部処理について考えてみる。さらに、もっと単純にするためにCSSの値についてのみ考えてみると、これらのエンジンのサポートしているプロパティ数、さらにその値の数が全然違うのは誰もが知っている常識である。CSSのプロパティは各ボックス(要素ではなく、CSSのボックス単位であることに注意)ごとに、全てのプロパティに値が存在しており、実際、保存されている。これは、初期値や、ブラウザのスタイルシート、ページ作者のスタイルシート、ユーザスタイルシートから決定される。このうち、スタイルシートによる指定は、セレクタが絡んでくるのでさらに速度に差が出る。Tridentのセレクタサポートは非常に貧相だが、GeckoはCSS3レベルに近づきつつある。つまり、Geckoでは複雑なセレクタも処理してプロパティ値が決定されることになる分、やはり不利である。
状況を整理してみよう。 二つのエンジンにおいて処理しなくてはいけないCSSプロパティの数にそもそも差がある。プロパティ値を決めるセレクタの対応状況に差があるので、値を決めるのに必要なコストにも差がある。つまり、高機能なエンジンであればあるほど、速度面、メモリ消費量では不利になっていくということだ。
セレクタの問題は両方のエンジンでしか解釈できないセレクタを用いることである程度無視できるだろう。だが、プロパティ数についてはいかんともしがたい。サポートするプロパティ数が増えればその分、一つのボックスあたりのメモリ容量が増えてしまうし、値を決定しなくてはいけない処理対象の数が増えるのだから明らかに処理時間も長くなる。更に、より多くのCSSプロパティをサポートしているということは、実際のレンダリングにおいて、より複雑な描画に耐えうるレンダリング処理を走らせるということになる。つまり、そもそも比較対象の条件が全然平等ではないところに問題がある。
最も、これはユーザの問題ではない。だから、Tridentの描画がGeckoよりも速いことがあったなら、そのユーザにとってはTridentの方がGeckoよりも高速に動作するエンジンであるということは確かだ。それは否定できない。ただし、もし同じ速度で描画されたとしたら、実際には(そのケースにおいては)Geckoの方が実速度は速かった、ということになることにも注意してもらいたい。
実際のレイアウト、レンダリングにおいては極力複雑なCSS対応のコードを別の関数に追い出すなどしてシンプルなレンダリング結果しか必要ないときはシンプルな処理で済むように作っている。ただ、CSSのこの根幹部分は原理的にケチりようが無いというのは悩ましい問題である。
現在のエンジンがCSSをベースに作られているということは、HTMLのtableレイアウトというのは、CSSレイアウトなら必要の無い無駄なボックス(例えばマージンを確保するために、余計なセルを作ったり、スペーサーとよばれる画像を置いたり)を生成するので、実にユーザにとって迷惑なことだというのが、こういう側面からも分かる。
もう、常識的に考えれば分かることを問題にしてきた、Web関係のシステム開発屋さんによる報告。 最近、何人かコメントをくれる人が増えてくれて嬉しい限りだが、こういうのは勘弁して欲しい。
会社の看板背負って仕事している以上、各所での発言には気をつけてきたが、さすがに今回は我慢の限界。
もずはっく日記 を読んで。
- コメント: 報告日: 2005-12-06 22:23
- cgi programのprint locationでredirectすると「ページのリダイレクト設定が正しくありません」のmsgで実行できません。redirectの回数が２５６以上になるとこのmsgがでます。Firefox 1.0の時にも一度報告しましたが、Firefox 1.5でも同じbugが出ます。MSNのIEではこの問題は出ません。
この要望に対して、「何に使うんですか」という反論があるのですが、商売では（違法ではないことを前提に）お金儲けのために使う。 解かりきった答え。
なんでその回答が解りきった答え
なんだろう?
Bugzilla-jpは雑談の掲示板ではなく、開発現場、技術や仕様に関するディスカッションの場だ。
この状況下で、何に使うんですか
と問いかけて、技術的な用途の回答をせず、そのような回答をするならコミュニケーションをまともにとれない人か、スタッフを挑発しているかのどちらかだ。
それに私の問いかけは明らかに、技術的な用途を問いかけている。最初にえむけいさんがDoS攻撃でもしたいのですか?
と問いかけた事実を前提に、私がえむけいさんも問われてますが何がしたいのですか?
と再度問いかけたわけだ。どうしてこの文脈で、お金儲けのために使う。
と回答することが当然なのだろうか。ついでに、（違法ではないことを前提に）
という補足も解らない。違法な商売であっても金儲けという最終目的は同じではないだろうか?
百歩譲って、その回答が妥当なものだとしても、そのような商売人
とやらにbugzilla-jpに何かを報告されても困る。bugzilla-jpに報告してもらいたいのはバグである。つまり、報告者はある程度PCやWWWに関する技術に精通している人でなければならない。この「ある程度」とは、その現象がバグかどうかを見極める能力、知識が必要ということだ。バグかどうかはっきりしないもの(仕様の曖昧な問題や、ディスカッションを必要とするものを除く)を、気軽に報告されても処理しきれないというのも実情(特にbugzilla-orgの方はかなり深刻)。実際、簡単なバグをひとつ修正するよりも、まともではないバグ報告の相手をしたり、要望を却下した後の事後処理の方が大変なのである。
その「技術的な用途」は、報告者の
文脈では お金儲けのための用途です。
そこがそもそもおかしい。報告者の文脈
とは何なのだろうか?
まず、おかしなポイントの一つ目は、報告者はそもそも商売ネタとして作成したプログラムが動作しない、という趣旨の発言はフォーラムでの発言も含め、まったく存在していないことだ。つまり、三宅さんが商売人が商品の動作を正常化したいがために、このバグを報告したという仮定の根拠が解らない。
もし、報告者が単に企業のメールアドレスをbugzillaのアカウントに使っていることから、企業の業務の一環としてこのバグ報告を行っていると仮定しているのだとしたら、それはbugzillaの常識とは大きく外れる。企業のメールアドレスをアカウントに、ボランティア活動をやってくださっている方は、本家、日本を問わず、bugzillaにはいらっしゃるので、bugzilla-jpという特殊なコミュニティ下においてはこの仮定は根拠が無さすぎる。
次に、報告者は単に、設定に関わらずたったの一万回
リダイレクトできない、ということを問題としてBug 4837を立ち上げているようにしか見えない。
我々からすれば、そのような問題はバグであったとしても、もはや要望の域である。なぜなら現実的に考えられるまともなWebアプリケーションの実行プラットフォームとしての性能をはるかに超えているからだ。
だから、私は再度、問いかけを行った。もし、報告者から画期的で素晴らしいアイデアがあるのであれば、バグをReopenし、UAとして対応する価値が出てくるかもしれない(もちろん、現実的にはユーザを守るというUAのコンセプトからは外れるため、デフォルト設定で許可されるとは考えにくいが)。
もちろん、そのような用途が全く思い浮かばない私によるあの問いかけに嫌味が入っている(というか嫌味そのものである)ことは否定しない。だが、ディスカッションを行える余地を残すための質問ではあるので、やはり技術的な回答を求めていることは明白である。
そのつもりの無い相手に
DoS 攻撃でもしたいのですか？と問えば、普通は呆れて返事はしません。
相手に用途に関する回答の意志がないなら、そもそもなぜbugzillaへ来たのかという話になる。bugzillaとはバグの報告場所である。報告内容がバグであろうが、要望であろうが、その修正の必要性が開発者には理解できない場合、その必要性を説く必要がある。修正の必要性を説くにはまず用途が明確でなければならないだろう。つまり、そのつもりの無い相手
がbugzillaに来た時点で、私たちは呆れるばかりだし、はっきり言って仕事の邪魔でしかない。
修正の必要性が無いと思われるバグをたとえ却下せずに放置しておいたとしても修正の見込みなど全くない。修正すべき理由の明確なバグはより重要なバグと言える。それが絶えず報告されているのだから、そちらの修正が優先され、結果的に開発リソースは全くそのような不明瞭な報告には注がれないという形になるからだ。
そもそも三宅さんは商売と、オープンソースが馴染まないと主張され、それを書きたがっているように見えるが、その話題を書くためのネタとして、今回のバグ報告を持ち出すということが不適切なのである。報告者が企業機密なので言えないと答えた訳ではないし、単に本当にDoS攻撃をしたいだけかもしれない。この素材とされたバグ報告は商売云々とは全く関係していないのだ。三宅さんが勝手に商売とバグ報告をひもづけて、bugzillaにおいてはトンチンカンな回答が当たり前だと言い、それは間接的に質問を行った私に対する批判と受け取れたので問題の箇所に反論しているだけである。
余談ではあるが、商売上、三宅さんの仮定通り、自社ネットワークでのアプリケーションでFirefoxをクライアントに、256回以上のリダイレクトを可能にしたいのであれば、Firefoxをそのようにハックして自前ビルドを作り、クライアント端末にインストールすれば良い。これはオープンソースが商売に馴染まない、という発言とは全く逆に、秘密主義な商売に逆に向いていると言えないだろうか? もちろん、あのレベルの報告者にそれができるのか、という疑問は出てくるが、自社でできないなら外注すれば良いのである。そうすれば一切商品の秘密がバレることなく、商品を発売することができるではないか。
Windowsで、U+FFFDを持つフォントが一つもない環境で文字化けが発生するとしばらくフリーズするというバグ。Thunderbirdで文字化けメールを受け取ったときなどにフリーズしていたら、このバグである。
根本的な解決は無理だと思っていたのだが、えむけいさんが根本的な解決を行うパッチを提供してくれた。えむけいさんが詳しい説明を書いてくれているがTrueTypeフォントの仕様というか、よく解っていないのでまだ理解しきれていないのだが、問題なさそうに見える。
ちなみに私の開発機で7.94277秒フリーズしていたのが、わずか0.487671秒のフリーズ(というか、ここまでくるとフリーズとは呼べない)になるという劇的なパッチ。実に素晴らしい。Cairoを利用するGecko1.9では意味が無くなるパッチだとのことなので、なんとか1.8.1へ投入したい。
bugzilla-jpでのvoteの募集を数日前にかけたものの、まだ3人のみ。言い出しっぺのlevelさんを数に入れても4人。ちょっと大がかりになりそうなパッチの検討段階に入るには、まだこの人数では優先順位を上げることはできない。前回の募集が「最新のもずはっく日記」の表示では埋もれた感じになっているので再度vote募集。一人で何票入れてもらっても結構だが、voteした人数で決める。前回これを記述し忘れていて申し訳ない。とりあえず締切は無いのでどんどんvoteして欲しい。
ただし、voteがたまったからといって確実に修正できるとは限らないことだけは再度明記しておく。まだ、修正方法がぱっと思いつかないためだ。だが、voteがたまれば、日本人ユーザにとって不満が大きい問題であるとして、私の仕事の優先順位をあげたいと思っていることは確かだ。
そのつもりではないのに、DoS 攻撃でもするつもりかと訊かれれば、
商売では（違法ではないことを前提に）お金儲けのために使うと答えると思いますが？。 既に書いたように、社内で何かのために使うケースも考えられるにも関わらず、悪い方に仮定して訊いている。 その流れで、何がしたいのですかと繰り返している。
どうにもこの人の言い分が分からない。あの流れだからこそ、普通の人ならそうは答えないと思う。 自分にその気もないのに、悪意があるかのように言われれば、反論するのが普通ではないだろうか? 反論するためには質問者の意図に沿った回答が必要だが、あなたの回答は質問者の私からすればはぐらかされているとしか思えない。
私に、商売とは書いていないのに何を根拠するのか、と訊かれるけれども、仮定を根拠にして応じたのは Bugzilla の「回答者」です。コミュニケーションなら、仮に技術力の無い相手でも、アイデアを引き出す訊き方をした方が良い。そうではなく技術を検討する場なら、相手の用途を詮索する必要はありません。 技術に二面性があるのは当たり前です。
話題の矛先をすり替えられた。が、まあいいや。
では、理解不能な提示に対して、どうやって何の予想・仮定もたてずに回答すれば良いのだろうか?
Bugzilla の「回答者」
は可能な限り、現実的な解を仮定して問いかけただけである。
bugzillaの回答者の仮定は報告された内容を処理する必要に基づいてのものである。 だが、あなたの仮定は自分のWeblogのネタのためにたてたものある。 これらを同一視しないで欲しい。
それにどうにもbugzillaという特殊な風土を考慮に入れているように思えない。
仮に技術力の無い相手でも、アイデアを引き出す訊き方をした方が良い。
とはまさに部外者の台詞。
そんなことをいちいちやっていては今ある問題も片付かない。
そもそもbugzillaはヒアリングを行うような場ではない。 報告者がbugzillaのルールに従い、バグ報告を行い、その修正について議論、もしくは実作業を行う場だ。 質問を受け付けているような掲示板では話題の中心人物は多くの場合、スレッドを投稿した人だろう。 だがbugzillaはスタッフの方が中心にいる点が異なる(もちろん、報告者が自分でパッチを提案するなど、スタッフより中心になる場合もあるが、それは今回のケースには当てはまらない)。
今回の場合、報告者は公のプロダクトに改善要望を出したわけだが、プロダクト開発側は不要だと考えている。 この状況下で何故、開発側の私たちにとって、用途の詮索は不要なのだろうか? プロダクトにとって必要があるなら、検討に値するし、必要が無いなら却下。 その判断材料として、有用な用途があるか否かは非常に重要だ。 必要だから問いかけた。それを不要と言われても困る。
もう少し正確に言うと、技術に道徳を混ぜてしまっている。 この二つは切り離しておくべきです。
私はそうは思わない。例えばWinnyのような馬鹿げた仕様(意図せず漏洩した情報を削除する手段が無い、ファイルの需要を無視したミラーリングによるネットワーク帯域の浪費等)は、思いついてもモラルがあるなら作って配布などしない。ウイルスだってそうだ。モラルの無い技術者がいるから作成されている。スパムメールのメールアドレスの回収・配信プログラムなんかもそうだろう。
技術というものは使う側にモラルが求められるのは当然だが、開発者もモラルを持つべきである。つまり、人間が関わる技術なら(言い換えるなら、技術に人間が関わる時は)、技術に人間の道徳というものが常につきまとっているというのが私の持論だ。
もし根拠を示せと言うなら比較的近所なので存在確認しますが、その必要があるのでしょうか。
私が問題にしているのはあなたの仮定の事実関係ではない。あなたが仮定のもとにとんちんかんなことを言い、間接的な私への批判に反論しているだけである。
それに会社があったところで事実かどうか、何故分かるというのか。 メールアドレスからして、会社の業務に何らかの形で従事する方からの報告だったというのは自然な推測だと思う。だが、その方が、業務プログラムためにbugzillaを利用したのか、していないのかは確認できないのではないか。
もう、面倒だし、時間が勿体ないので総括。
bugzillaに報告するということは、(一時的に)開発者の一員となるということである。 だから、bugzillaのスタッフからは最初の報告の内容にはクオリティが求められる。 どうすれば確実に、シンプルにバグを再現できるのか、なぜバグと言えるのか、なぜ修正されるべきなのか、修正されればどういったメリットがあるのか等々、スタッフが疑問に思うことがないように報告できることが理想である。
だが、実際にはスタッフによる報告でもお互い、環境に違いがあるのでバグが再現したり、しなかったりする。スタッフ以外の報告者ならなおさら意思の疎通には難しいものがある。そのために、バグの再現方法の確認等、不足している情報について問い合わせが発生する。報告者は当然これに答える義務がある。反応が無いなら、そのバグはすぐに閉じて、次のバグの作業に入ることになる。
報告しました、はいあとはよろしく。というのはbugzillaでは成り立たない。スタッフから要請があればそれに応える義務も発生するのだ。気軽に報告されてもスタッフが余計な後始末をする必要が増えるだけなのである。
これだけ聞くと、bugzillaというのは近寄りがたいものと思えるかもしれない。実際その通りである。bugzillaへの報告の際に事前のテストとして、三日以内にビルドされたNightlyビルドでの再現テストもガイドラインで明記されているように、通常のユーザからすれば、その敷居は確実に高いものなのだ。(検索は敷居を低くしたいものだが、結局ステータスを理解しなくてはいけないなど、下げれない敷居がどうしても存在している。)
また、bugzillaのスタッフは虫がよいと思われるかもしれない。そうかもしれないが、わがままでそう言いたいのではない。bugzillaは日本も本家も既にフル稼働している。未処理のバグを検索してみればその処理が追いついていないことは簡単に分かる。つまり、解決に近いもの、重要度の高いものから順に処理していくことになる。自然と、マンパワーの不足から、報告者という参加者にもクオリティを求めなくてはいけない事態に陥っているというのが実情である。だからクオリティの低い、重要度も低そうなバグは捨てるしか無いのだ。
件の報告者は、質問に応じなかった、また、そもそも普通は用途を疑問に思うような情報を盛り込まずに、報告してきた(そもそも報告した文面から見て、bugzillaのバグ報告ガイドラインから大きく逸脱した質の低い報告である)。機密で用途を公開できないなら、最初からバグとして報告すべきではないし、報告後も、一言その旨の返答があって然るべきである。このような状況下で、「金儲けに使うんやからよろしく。」などと発言したらそれこそただのバカである。
本当に、bugzilla関係のドキュメント整備を行わないといけない。しかし、日々バグの処理、パッチの作成、パッチのテスト、レビュー、そして事務処理に追われているというのが現状である。
相手を責めるばかりで自分たちの非は認めようとしない。
そっくりそのままお返しする。三宅さんの発言には何も非が無いというのか? 少なくとも私は三宅さんのでたらめな思いこみによる仮定を非難したが、認めないどころか、事実関係を確認しようかとのたまう始末。私が批判したのは、あなたが仮定を行った段階において、関連するリソース内に何も三宅さんの仮定を裏付ける証拠がなかったことであり、事実関係を指摘したのではない。三宅さんの返答は常に論点をずらすことに終始している。それとも単に天然で曲解されているだけなのか?
そもそも、バカバカしい言葉遊び的な回答が当然のことだとのたまい、それによってその質問者の私を意味もなく批判した。それに不満があったので抗議の意味を込めて返事と説明を書いた。この話はそれだけである。
これでは Bugzilla jp は受け入れられるはずがない。
対象が不明瞭なので返答に困るが、万人に、ということであれば、それはそうだ。 そもそも万人に受け入れられるような作りではないし、誰かに対して受け入れて欲しいなどと要請などしていない。 bugzillaに来るなら、bugzillaのルールを理解しろ、そういうことだ。 郷にいれば郷に従う、普通のことである。
忙しいを連発しているけれども、仕事をしていれば誰でも忙しい。 どうも自分たちだけが多忙だと思っているらしい。
誰も、自分たちだけが多忙などと言っていない。既に存在する理路整然としたバグ報告を処理するので手一杯であるという状況を説明しただけである。現状を説明したことをネタに、なぜ私は非難されているのだろうか? 誰かを非難するために自分に都合の良い仮定を行うのが好きな方のようである。
普通に考えれば、会社のメールアドレスで報告している者が DoS 用途で要望しているとは考え難い。 会社の信用に傷が付くために、商売人は公開の場所へは要望しない。こういう常識的な判断が通用しないコミュニティは不健全である。
私の常識で考えるなら、今回のような非常識な要望を公の場に、会社のアカウントを使って公開すること自体、非常識であり、会社の信用を傷つけるものである。つまり、このバグ報告自体、常識的なものとは思えない。
ところで、健全なコミュニティとはどういったものを指すのだろうか? コミュニティということは、多くの人が集まる訳である。 つまり、コミュニティに参加するメンバー全員が「健全な」運営をする能力が要求される訳だ。 ということは、コミュニティに不適格者が入ってきた時点で、健全とは言い難いものになる。 不適格者を排除しようとするならなおさらだ。 では、どうすれば健全なコミュニティとやらを維持できるのだろうか? 誰かが、その不適格者を適格者に厚生させるしかないのだろうか?
少なくとも、私たちは健全なコミュニティの運用には成功していないらしい。健全とは何を意味するのかよく分からないが、三宅さんは健全では無いと言い切るので、彼を信用するならそうなのだろう。今後の運用の参考にしたいので健全なコミュニティをご存じの方は是非、紹介して欲しい。
ところで、会員制クラブ？
と見出しを付けて非難する文章を書かれているが、そんなことも理解できずにbugzillaについて語っていたのか? アホか。話にならない。bugzillaはセキュリティバグ以外はアカウント無しでも閲覧できるが、発言にはアカウント登録が必要である。不適切な行動を取るアカウントには停止措置も行う。つまり誰がどう考えても会員制のコミュニティである。そして、ハッカーや運営スタッフが(時には強引に)採決を下す、不平等なコミュニティでもある。
えむけいさんのパッチが採用されて、修正された。残念ながら今公開中のNightlyには間に合っていないので、明日以降のビルドで試してみて欲しい。
Bug 4650を抑制するためにたてたアドホックな提案だったが、その必要が無くなったので閉じた。
もし、他に何らかの理由で外字のサポートをオプション化した方が良いというケースがあるならこのバグに書き込んで欲しい。必要性を検討してパッチの投入を決めることになる。
なお sri-net.com の webmaster5 さんが
このbugはたくさん報告されてますと書いているのは、本家 Bugzilla の検索結果を見てのことだと思う。実際に読んでみると、ほとんど cookie 周りの問題らしい。そのあたりで、また認識のずれが生じているのではないか。
cookieの問題だとすると、私の知識外なので判断はできかねるというのが正直なところ。
件のバグで私の挙げたBug-org 256452で確かにそういう話は出ている。 だが、結局主要開発者の検証が入っていないので真実かどうか分からない。(ちなみに、報告者の提示したCGIではcookieは使われていない。)
この辺のバグを修正可能な人物というとDarin Fisher氏あたりしか思いつかないが、彼の仕事量を調べてもらえれればいかに多忙な人か分かると思う。(バグメールに至っては、全く受け取っていないが、それでも返事は返ってくるのでなんらかの方法で、主要なバグは監視してくれているようだが。) 彼がマーケティング、もしくはセキュリティ上、重要なバグ以外、特に、今回のような非現実的な話題で、彼自身で検証して解決に向かうということはあり得ない。
徹底した検証と、実装レベルでの話にまで言及しないと、この問題の解決は無いと思う。(他のバグ修正で、ひょっとすると、ということも考えられるが。) で、具体的に、誰かそれをやっているかというと、誰もやっていない。ならば、修正を要求する人物、例えば件の報告者の方にでもがんばってもらうしかない。
ちなみに、私はできればネットワーク関係のコードはいじりたくない。知識不足というのもあるが、セキュリティホールに直結しやすいコンポーネントなので、余程の必要性がない限り、リスクを冒したくないというのが正直なところだ。今のところ、私がいじったネットワーク回りのコードはURIの処理と、IDNの処理ぐらいで、核心部分はソースも見たことがない。
ちなみに、このbugはたくさん報告されてます
という発言を本家bugzillaでの調査結果なのだとしたら、私には該当するものは発見できていない。文意からして、dupが大量に発生しているということになるが、件のバグを閉じた後、一応調査してみたのだが、Bug-org 256452にdupされたバグがひとつあるぐらいだった。
ちなみに、bugzillaでは通常、大量にdupがあるというと、数十個十数個以上での話である。dupが一つ、というのは非常にマイナーな問題であることを物語っていると思う。
私は検索という作業がどうにも苦手なので、よく見落とすが、徳保さんは他に見つけられているのだろうか? 文面からはそのように受け取れるのだが。
徳保氏からメールを頂いた。メールなので文章の内容は引用しないが、要するに、徳保氏の張られていた検索結果のリンク(「Redirection limit」検索結果)の結果を見てのことではないか、とのこと。このリンク、完全に見落としていた。申し訳ない。
だが、氏もおっしゃっておられたが、結局、件の報告者が全く何の反応も無いので真実は闇の中、である。
このバグに関しては、修正不要とは考えていない。少なくとも私は。
このバグにいらついている人にとっては、非常に鬱陶しいバグであることは想像に難くない。しかし、オープンソースといえども、資本主義の枠内で開発している私としては、簡単に修正できないバグに関しては、それなりの需要の確認がとれないと、身動きとりにくい、というのが正直なところ。つまり、オープンソースといえども、コスト意識はどうしてもぬぐえない。
私の知り合いでこの設定を利用していたのはわずか一人だけだったので、それほど人気の無い設定なのではないかと考えている。現に、bugzilla-orgの方にもあまりvoteがたまっていない(dupも4止まり)。鬱陶しさからすれば、100人程度のvoteが貯まっていてもおかしくないとは思うのだが。
もし、バグ修正の見通しがたてば、私はすぐにでも修正にとりかかるだろう(大抵のパッチは一日あれば十分作成可能)。だが、このバグの場合、修正のためにXULの実装の仕方の調査がまず必要(どのタイミングをトリガとしてマウスカーソルを移動させれば良いのか)。また、マウスカーソルを移動させるためには一度nsIWidgetを経由する必要があるのでそのAPIを全OSでコーディングする必要がある。(Windows以外では別に未実装としてエラーを返すだけにするつもりだが、面倒なことに変わりはない。)また、設定の取得も難しい問題である。
理解の必要なコードの広さから言えば、IMEの無効化と同じぐらいの調査が必要になる。あれは明らかに国内での不満が大きかったので一年がかりで修正を行ったが、果たしてこのバグにそこまでの価値があるかどうか、よく分かっていない、というのが実情なのである。だからこそ、必要を感じている人はvoteして欲しい。
完全にやってしまった。申し訳ない。
最初にこのバグを報告されたのが2005年10月19日。この時点でもう、他の文字化けバグで手一杯だったので、普通のWeb上ではまず問題無いだろうという判断で(つまり、マイナーな問題と判断し)、このバグはFirefox1.5では切り捨てることを決断したのだが、BBSで報告されたように、Webメールの添付ファイルの保存なんかでは確かに多用されるし、重要な問題だ。
とりあえず、関係者に緊急でコンタクトをとり、Firefox 1.5.0.1、つまり次期セキュリティフィックスでこのバグを修正したい旨は伝えておいて、レビューを急ぐように頼み込んでいる。(Firefox側は終わったのだが、SeaMonkey側と全く同じロジックのパッチを投入しないと、今後のメンテナンスに響くので、SeaMonkey側のレビュー待ち。)
重大なregressionとして交渉すればセキュリティリリースに便乗させてもらえるという算段なのだが、まだ正式な許可はおりていない、最終決定権はMF側にあるので、次のリリースに間に合わなかったらご容赦願いたい(緊急リリース等があるとたぶん間に合わない)。今回は完全に私の判断ミスだった。重ね重ね申し訳ない。
国際化されたURIについてのユーザエージェント側のジレンマを少しだけ紹介。
実際のネットワークへの送信はテストせず、ステータスバーへの表示内容に関してのみテストをしているが、Operaの処理が最もユーザーフレンドリーで、セキュアで、確実で、理にかなっている。Firefoxのステータスバー表示処理はリファクタリング(といっても小規模だが)を考えているので参考にしよう。
以前、CSSのマイナス方向のoverflowについて紹介したが、それを扱っていたのがこのバグ。
David Baronの判断でwontfix(バグですが、修正されません
)という結果になった。
理由は述べられていないが、we should never fix.
というのが彼の意見のようである。(特にディスカッションがあった訳ではなく、完全に独断で裁定が行われた。)もしこのバグを修正すると、弊害の出るサイトが多いことを懸念してのことではないかと思われる。(というかそれ以外に思いつかない。)
ただ、気をつけて欲しいのは、RTL時に、左、マイナス方向にoverflowが発生した場合にはスクロールバーがこれに対応できなくてはいけないのだが、現在のGeckoはこのへん、ボロボロである。このRTLのスクロールバーの問題がどのように修正されるかによっては、まだ流動的な決定であるとも言えるので注意して欲しい。
また、バグではないと判断された訳ではないので、今後もWebコンテンツの作成者は、他のUAの動向にも注意を払って欲しい。(というか、あのような本来の用途から外れる使い方はすべきではない、という意見に変わりはない。)
修正完了。突然、修正方法を思いついたのでパッチを書いてみたら見事に動いたので予定外に修正してしまった。(もっとも、その後のテストでフレームページの場合にも問題があったことが発覚して結局三つのパッチを作成するハメになってしまったが。)
まあ、何をやったかと言うと至って簡単。プリントプレビュー時にマウスホイールによるスクロールイベントが発生した場合は、イベントが発生したフレーム(Gecko内部のnsIFrameのこと。CSSのボックスはこのフレーム複数で構成される。)を無視して、常にそのビュー内のルートのスクロール可能なビューをスクロールするようにしただけ。
若干問題を抱えた(論理的に正しくない)コードをパッチ内に含むが、rocもベターなアイデアが無いということでそのままレビューを通過。これは完全にGeckoの設計ミスなので今後の課題かもしれない。(というか、GetShellAt(0)というコードを多々見かけるが、これって論理的にはバグっていることが今回の一件で判明。)
ちなみにこのパッチの副作用として、プリントプレビュー時にもリストボックス等が、無意味にホイールでスクロールできていた問題も解消している。
草案となるパッチはほぼ完成。
とりあえず、文字化けして表示されるのを最小限に抑えよう、というのが今回の趣旨。そのために、同一ホスト内以外ではUTF-8以外ではアンエスケープしないようにしている。ホスト間をまたぐリンクのためにa[charset]を利用するという案をうけて、a[charset]で間接的にURLのエンコーディングを明示できるようにしている。これを利用したスプーフィングを防ぐため、URIが生で書かれていた場合はa[charset]の値でエスケープするように仕様変更を行っている。これによるregressionは考えられるが、事実上、a[charset]が使われていないことから問題無いのではないかと考えている。
本家提出前にまだまだテストが必要なので、仕様に問題点があれば指摘して欲しい。よろしく。
あたりについて。
アプリケーションの場合、そのOSのデザインのガイドラインに従うのは当然だと思う。ユーザの慣れというのは、ユーザビリティにとってもっとも良い材料となるからだ。
Webアプリケーションの場合、位置はフォームの末尾であればどこでも良いと思う。 もし、送信以外のボタンがキャンセルボタンだとか、戻るボタンだとか、リセットボタンだったらWebアプリケーションにはそんなもの必要無いと思う。 送信ボタンと、他へのナビゲーション用のリンクがあればそれで良いのではないだろうか? (少なくとも、セッション管理を行っている複雑なWebアプリなら基本的には送信ボタン以外いらないはずだ。例えばbugzillaのように。)
そもそも、キャンセルボタンや閉じるボタンのたぐいを置くのは、ユーザの断りもなく新しいウインドウを開いて別ウインドウで入力させたから、必要になった無駄なものだったり、特に使い道のあるリセットボタンを習慣で置いているだけなんじゃないかという感じがする。
それ以外で、こういう問題が発生しそうなのは、入力内容の確認画面でのフォームへと戻るボタンだろうか。しかし、私はこれも必要ないと思う。確認画面と共に、修正フォームをその下へ読み込ませておけば、ユーザの手間を一回分減らすことができるし、送信(確定?)ボタンは、確認内容の下に、(戻るボタンの代わりになる)修正ボタンをフォームの下に置くことで、混乱を減らすことができる。(本来必要ではないかもしれない修正用のフォームを送信するのはネットワーク的には好ましいことではないかもしれないが、所詮テキストデータなので、サイト内の画像のひとつでも削減した方が、よりマシになるというものだろう。つまり、気にすることは無いと思う。)
掲示板等でプレビューと、送信を両方に並べる必要もこれで解消される。ポスト時には一回はプレビューさせる、という方がアプリの性格上、良いと思うので、最初のフォームからは送信ボタンそのものを削除してしまい、あとは前述の確認画面の要領にすれば良いだろう。
ボタンの配置で悩むよりも、ボタンを(一カ所につき)一つにしてしまうことを考える方が、よりスマートだと思う。
「××と云ふファイルを削除しますか?」みたいな單純な選擇の場合、この方式は使へない。
削除するのだけをボタンにしておいて、戻るのをリンクにしておけば良いのではないだろうか?
メッセージの雰囲気からして、高度にセッション管理を行っているWebアプリの問いかけのように見える。
それなら、戻るのはブラウザの「戻る」でも良いだろうし、リンクでも十分なはずだ。
何も、戻る時に追加の情報をポストする必要がない、という前提ではあるが、Cookieでセッション管理していれば大抵、そういう状況だと思う。(そもそもセッション管理をinput[type="hidden"]等で行うべきではない。改竄が容易というのもあるし、もしCSS3のcontentやappearanceが実装されると、簡単にブラウザ上にこの要素をinput[type="text"]のように表示してデータを変更して送信し直せる可能性が高いからだ。Cookieなら改竄できないかというとそういう訳ではないが、CSS3のこれらのプロパティはWebアプリケーションにとっては、驚異的である。また、単純に、リンクをページ間の移動手段として使えなくなるinput要素によるセッション管理は作り手にとって不便といわざるをえない。)
野嵜さんの、ボタンを一カ所に複数配置すべきではないという意見には基本的に賛成だが、実際問題、このようにデザインする、システム屋がいることは現実なので、これを仕様側で改善したい人がいれば、Web Forms 2.0のワーキンググループに投げてみると面白いかもしれない。たとえば次のような要素が思いつく。
confirm要素というのを作って、type属性で、OKとか、OKとキャンセルとか、様々なパターンを用意しておく。 UA側はこれを必要な個数のボタンに置換して、OSのガイドラインに従ったボタンの並び(携帯電話なら縦に並べられるかもしれない)、キャプションを表示可能としておく。このキャプションは変更できても良いが、並び方等の見た目は変更不可とすれば良い。 ついでに、ボタンごとに、送信先のURIを変更可能にすれば、アプリケーションの作成も楽になるかもしれない。
ちなみに余談だが、IMEの制御用の属性が欲しいということをワーキンググループに昔投げてみたが、需要が理解してもらえなかった。そこで、とりあえず今、Gecko1.9では-moz-ime-modeプロパティの実装を急いでいる。CSSで対応する、というのはちょっと自分でも納得いかない部分はあるのだが、ユーザスタイルシートで上書きできるというメリットが捨てがたいのと、Web Formsでゴーサインが出ても、ブラウザのデフォルトスタイルシートを書き換えるだけで実装できてしまうというのは大きい。私はWeb Formsのワーキンググループに国際化に関する専門家がいるように思えないので、興味のある人は論争してみると面白いと思う。
まあ、なんやかんやとあるわけで、結局年末年始など関係無く仕事を進めるのみ。
一月四日と、一月五日は私用で完全にオフラインになるので、関係各位、よろしくお願いします。
例の文字コード間の齟齬によるXSS関連問題、結局のところ、UAの開発サイドとしては、改善案の決定打を出せずにいる。もともとWebアプリケーション側の脆弱性と、ユーザ本人の行動に脆弱性がある訳で、UAのセキュリティ問題ではないので、当然のことなのかもしれないが、歯がゆいものがある。
とりあえず、私は、<>&のみをサニタイジングするだけではWebアプリケーションとしては失格、という結論に至っている。結局被害を被るのはXSS攻撃を受けたサーバのユーザ、つまり、そのWebアプリケーションの(間接的かもしれないが)顧客である。顧客を守るために、Webアプリケーションの制作サイドにがんばってもらうために、Mozilla Japanからになるか、もじら組からになるかは分からないが、何らかのまとまった資料を提供予定。
そのための案を募集しているのがこのバグなので、何か情報があればよろしく。 ただし、Mozilla Japanやもじら組がその情報を利用して情報を公開することになるので、この体制に納得できないなら、書き込まないで頂きたい。ここに書き込まれた情報は一般的な情報として、利用させてもらうので、予めご了承いただきたい。