この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
結局、1.8branchへのチェックイン申請は却下された。もう、1.8系に新しい機能は入れないようだ。
人によっては非常に気になっていたのではないかと思われるこのバグ、修正が完了した。
どいういうバグかと言うと、サブメニューが開く瞬間に、そのサブメニューの親のメニューごと閉じられてしまうことがあるというバグ。詳しくはバグ内のコメントを参照。
詳しく、説明してみると、まず、これまであるメニューがハイライトされた時、そのポップアップの他のメニューアイテムがサブメニューを開いているなら、そのサブメニューを閉じるためのタイマーを起動していた。一定時間経過して、そのサブメニューが相変わらずアクティブなメニューではなかった場合にはそのメニューを閉じ、アクティブになっていたらサブメニューを開いたままにしていた。
このメニューがアクティブであるかは閉じようとしているメニューから、子孫メニューの方へ順に下っていき、最後までポップアップ内のどれかのアイテムがハイライトされていたらアクティブ、そうでなければ非アクティブ、という判定方法だった。
この方法は多くの場合に問題が無かったが、以下の場合に最も子孫のメニューがハイライトされていない、という問題を抱えていた。
これらの問題を、現在のアプローチのまま解決することは実に難しい。メニューはマウスでもキーボードでも操作できるという事実が特にこれを困難にしている。そこで、閉じるメカニズムはそのままに、アプローチを完全に変えてみるとこにした。
新方式では、あるメニューアイテムがハイライトした時、その祖先のポップアップのサブメニューを閉じるためのタイマーを全てキャンセルし、サブメニューを開いているアイテムをハイライト状態に戻して行っている。逆に言うなら、タイマーがタイムアウトした場合、メニューの状態は非アクティブのままだったいう判定で、常に閉じるようになった。
もし、微妙にフィードバックに違和感を感じるなら、この祖先メニューのハイライト状態の変更が従来よりも素早くなっていることに対するものだろう。(従来は、タイムアウト時に、そのメニューがアクティブと判定された場合に、サブメニューを開いているメニューをハイライトしなおしていた。)
メニューの動作を大きく変更したパッチなので、どのようなregressionがあるか想像つかないため、1.8branchへの承認申請は行わないことに注意して欲しい。
IEのめちゃくちゃな処理方法が告白されている。
この話によると、IE6まででは、base要素が出現すると、空要素にも関わらず(しかもhead要素内にしか出現できないにも関わらず)、それを開始タグとして、終了タグを"適切に"補完し、そのbase要素の影響すべきリンク全体がbase要素の子孫要素となるようにし、リンクは、自分に最も近い祖先のbase要素を参照していたというのだ。(base要素がhead要素内にあった場合は、body要素の親をbase要素とするらしい。詳しくはCode-Only: BASE tag changes in IE 7 with Examplesを参照。)
こんなことは普通の人なら思いつかない。base要素の処理における使用頻度を考えると、こんな複雑で、奇怪なことをしなくても各documentオブジェクトにbase要素の情報を持たせれば簡単で、高速な処理ができるではないか。(base要素はhead要素内でも一度しか出現が許されていない、つまり複数のbase要素を処理する義理など何処にもない。)
こんな非常識なことをおそらく、様々な処理で行っているのだろう。IEのバグには不可解で、原因を推測できないものも多い。W3Cの仕様などより、IEの仕様に他のブラウザが仕様を合わせるべきだと主張することがいかに荒唐無稽なことであるか分かるというものだ。IEの仕様にあわせるには、IEと同じ処理、ひいてはIEと同じコードを使わなくては同じになどなろうはずがない。
来た台風の規模も洒落になっていない。
ちなみに、早明浦ダムの完全回復には台風三個必要と言われていたのだが、14号だけで40%まで回復する見込みの模様。
とりあえず、車は高台に避難。
見通しが甘かった。nsTextFrameの修正が思っていたよりも大規模になりそうなので、作業を小分けにしていくしかなさそうだ。
Nightlyでテストに協力してくれる場合、ひとつだけ注意が。
差分アップデートは使わないでください。regressionがあった場合、いつのビルドから発生したのか調査する場合、古いビルドに戻してテスト、なんてことが必要になりますので差分アップデートしていると後から苦労することになります。(古いNightlyはサーバからも削除されるので、日々のビルドを自分で保存しておかなくてはテストできなくなります。)
春永さんより指摘が。
古いNightlyビルドはarchiveサーバからダウンロードできる模様。異様に重いですが。
情報ありがとうございます。
パッチを分割して提出して時間をかけている間にパッチの単純化方法を考慮中。
よくよく考えてみればDrawSelectionIterator::GetSelectionColorsと、これで必要としている各種色情報がDrawSelectionIteratorにあること自体がおかしいのではないかと言う感じがしてきた。
nsTextFrame内でDrawSelectionIteratorを利用していない場所でこのクラスの算出する色情報が必要になったのだが、このクラスを色取得のためだけに動的に生成するには無駄が多いし(一回の描画用の処理経路で数個、同じ内容のメンバを持つクラスを複製しなくてはいけなくなる)、数々の不足情報を補うために膨大な修正が必要になる。こういう場合(修正箇所が多岐にわたる場合)、経験上、設計そのものが悪いことがほとんどだ。
という方向で検討してみたところ、色の情報なんだからnsTextFrame::TextPaintStyleに持たせときゃいいんじゃないかという答えが見えてくる。そしてこの構造体を見てみれば、選択色情報を持っているではないか。しかもただ単にDrawSelectionIteratorに色情報を渡すのに使っているだけだ。ということは、最初にDrawSelectionIteratorにも色情報を分散させて保存させだした当たりから大きな間違いが始まっていたのだろう。前回の私の選択色反転のパッチもこの流れにのってしまっていた。反省。
二台以上プリンタがある状態じゃないとテストできないし、ネットワークプリンタが無くて困っていたので奮発してカラーレーザープリンタ購入。金が……
おおっ。S級ライセンスは持ってるようですし、そのうち監督にまでなるのでしょうか。柏も強くなるといいですね。 > 大島さん
徳島の試合は一度も見たことないですけど、カズが来る時は行きたいなー。
ATOK17 ProfessionalからATOK2005 Professionalにアップグレードしたのだが、どうにも変換効率が悪くなっている。文節が思い通りのところで切られないことが多いし、漢字の優先順位もおかしい。ATOK17に戻した方が良いのか?というぐらいに不調だ。
膨大なMozillaのソースコードの中で特定のバグの原因を探し、確証が得られたら修正案を考える。いつもの手順。理解不能で放置していた問題も他のバグを修正したりする内に理解できるようになってくる。でも、いつまで新たな問題を理解し続けられるのか、修正し続けられるのか、年齢、技術、知識……それぞれの面から心配はつきない。
ひとつバグをつぶせば、ひとつの仕事が完了する。しかし、それと同時にひとつ仕事を失う。これが不安のタネである。
しかし、現実的にはいくつかのバグ修正の後、いくつかのパッチがひとつ以上のregressionを引き起こしたり、更に別の問題を浮き彫りしたりする。このように仕事が減ることは幸いにも無いようだ。しかし、自分で修正可能とは限らない。こうなると、私のできる仕事とは呼べなくなる。増えた仕事は全員で共通の仕事であって、私のものとは限らないということだ(regressionの場合、責任はあるが)。
多くのMozillaユーザにとって、私が修正できるバグが存在しなくなって私が職を失うことは(少なくとも現状よりは)良いことなのかもしれない。でも私としては嬉しくない。複雑なものである。
そんなこんなで今日もバグを修正しながら、30万個の仕事になるかもしれないネタを物色し続けている。
見た目のために、理屈と違うことをするとツールが混乱するよ、という良い例。勉強になるなぁ。
Windowsのスクリーンリーダはテキストを出力するAPIをフックして読み上げを行っているようなのだが、Geckoはsmallcaps、wordspacing、letterspacing、justificationの場合には、一文字ずつ(これは1.9で一グラフィームクラスタずつに改善される予定)位置調整してテキスト(というか文字)を出力する。つまり、文字数の分だけ問題のAPIが呼び出されるので期待通りにスクリーンリーダが動かない、ということだ(重くなるだけか? スペルとかは大丈夫なのか? スペースは出力されないぞ?)。
趣味や仕事で不特定多数の人が使う可能性のあるアプリケーションを書いている人は気をつけよう。
Firefox/Suite/Javascriptによる印刷で印刷する際に、常にデフォルトのプリンタが選択されていたというregression。FirefoxとJavascriptによる印刷時のパッチのみ先行でチェックインした。
Linuxでは若干事情が違っているので、このパッチのみで機能するかどうかテストしたいのだが、Fedora Core等でGUIからプリンタを追加しても、Mozillaの印刷ダイアログでは追加したプリンタがリストアップされなかった。Linuxのことはさっぱり分からないのでテストができなくて困っている。早急にテストして(次のFirefoxベータ版までに)、問題があるなら修正しないといけないのだが、誰か協力してもらえないだろうか?
テストに協力してもらえるなら、CVSからTrunkのソースコードを引っ張ってきて、ビルドするか、明日以降のNightlyビルドでテストしてみて欲しい。なお、ビルドする場合は、パッチをあてることでSuiteでもテストできる。
Suiteでも修正完了。
昨日からのregression。西村さんが修正してくれた。西村さんに感謝。
1.8Branchは現在、承認申請中。
こちらも西村さんが修正してくれた。感謝。
IE7ではXML宣言があっても、正しくDOCTYPEスイッチが機能するように修正するようだ。
しかし、XHTMLの厳密な取り扱い(application/xhtml+xmlの処理)は見送られるようだ。理由は、セキュリティ問題への取り組みと、CSSバグへの取り組みで時間が無い、ということと、現在のパーサを使うと、MozillaやOperaのように、InvalidなXHTML文書の場合、エラーを返すのではなく、HTMLとの互換性を重視してエラーを出さずにレンダリングしてしまうことが問題のようだ。
IEのapplication/xhtml+xmlの中途半端なサポートによって、他のブラウザではパースエラーの出るXHTMLの怪文書が世の中に出回る、という最悪な事態は避けられるようである。私はこの決断に大いに賛成だ。
しかし、IE6以降、MSは何をやっていたんだという批判は避けられない話ではある。全く何もやってなかったからこうなった訳で、夏休みの宿題を8月末から大あわてでやり始めた、という光景が目に浮かぶ。
tabbrowser.xmlでエラーが出ているのでbug 4539のregressionかと思ったけど、DocShellの方にも修正が入ってるので、そっちの可能性の方が高そう。
修正パッチが入った模様。DocShell側の問題だったようだ。
修正完了。いつものことだが、全OSのwidgetのコードをいじるパッチの修正は大変すぎる。手間とか、規模とか、提出からチェックインまでの間に他の修正が入ったりとか。
こちらも修正完了。rocが全OS分、OK出してしまったけど、良いのかな。
公開。
仕様は最新のNightlyと同じものです。(1.5はこの仕様で行きます)
Flash等、一部のプラグインにフォーカスが移っても、フォーカスイベントが発生していなかった問題。VYV03354さんが対応してくれた。
これでIME無効化に向けてのブロッカーは無くなった。
昨日、ソースを見ていてたまたま思いついた修正方法が当たりだったバグ。既に修正完了している。
これと同じ問題の、サーバサイドイメージマップの場合の問題も同時に修正できている。
見出しをアンカーにしてゐるサイトでありがちなのが、「他所の『ブログ』の人がURLをコピーし易いやうに設けてあるアンカー」。
私もこれには反対。リンクだけを抽出して、見出しを並べてみたとして、確かにその見出しの記事へのリンクであり、内容は間違ってはいないわけだが、単に、コンテンツを見に来た人がクリックすると、騙されたと思わないだろうか。記事を内容込みの一覧で見ていて、そこから、その記事のみを表示させるリンクを誰が利用するのか、と考えたときにコンテンツを見に来ただけの人は絶対利用しないと思う。
自身(というか、同内容の別URL)へのリンクは基本的に利用者に混乱を与えるものだと思う。だから、うちでは目立たないようにしているつもり。
「ここ」とか、「ここをクリック」並に批判があっても良いように思えるのだが。
regressionやら、取りこぼしやら多すぎ。
大規模修正を入れることができるalpha期間と、リリース間際のregression対応とが重なるのはどうにかならんのか。
Mozillaの1.0以降のプリンタ周りのregressionはこいつが原因だ。やっと見つけた。なんでこんなめちゃくちゃなパッチが通ってるんだ。
これに気づかずに、修正したために、最後に印刷したプリンタとその設定が、再起動後も設定を持ち越すように変更してしまっているが良いんだろうか。もう、知らない。
IEのレンダリングエンジンに密着した、Mozillaのものと同程度のDOM Inspectorが欲しい。CSSのIEによる不可思議な表示結果の原因を調べるには、現在公開されているDOM Inspectorでは物足りない。
ようやく明るい話題が。CSS3 contentプロパティの実装、やる気になったのかもしれない。時間はかかるだろうけど。Operaはもう実装してたんだったかな。思い出せない。眠い。寝る。
パッチが出た。パッチ中に記述があるように、blur radius(ぼかし半径)を無視するようになっている(nsTextFrame.cppの部分を参照)。Cairoに切り替えて、ぼかしをつけれるのなら良いのだが、中途半端な実装なので慎重にやって欲しいなぁ。
User agents MAY only implement only part of this property by ignoring blur effects. Such user agents should consider declarations that specify the blur radius to be parser errors, as described in the Syntax module [link TBD].
一つ前のCSS3テキストモジュールではこのように書かれているので、一応、仕様の範囲内の実装ではあるのか。(ちなみに、最新のテキストモジュールではtext-shadowは更新されていない)
今日、ふと思い出して、この話題をまだ書いたこと無いことに気づいたので簡単に。
CSSハックだとか、SEOだとかで、text-indentに大きなマイナスの値を指定したり、position: absolute;で、leftかtopに大きなマイナスの値を指定して、要するに、ブラウザがスクロールできない場所にテキストを持って行く、という手法を聞いたことがある。
CSSの仕様書を見たことあれば、こんな手法は不自然に感じると思う。そして、その疑念は正しい。CSSのoverflowのauto値の説明を見てみると、
The behavior of the 'auto' value is user agent-dependent, but should cause a scrolling mechanism to be provided for overflowing boxes.
とある。つまり、理想的なブラウザでは、負の座標に追いやられたボックスもスクロールすることで表示可能と考えるべきである。
さらに、ブラウザのルート要素に指定されたoverflow: visible;(初期値)はCSSのauto値に読み替えることになっているので、ブラウザはその内容を全てスクロールで表示可能とするべきであるということになる。
Mozillaでも古くからこの問題はとりあげられており、修正パッチが無いので修正されていないだけで、そのうち改善されることになるかもしれない。その時に、とんでもない表示になるサイトが少ないことを祈るばかりだ。
「h1の文字列をふっとばして背景画像だけ使いたいような場合なら、
h1 { overflow: hidden; text-indent: -100em; }でええんでないの？」と。
確かに。overflow: hidden;を使うと良いかもしれない。(ただし、Mozillaの場合、適切な動作かどうかはさておいて、hiddenでクリッピングされたコンテンツにもマウスでスクロール可能なことに注意)
position: absoulte;の場合、もし、負の方向に配置するボックス以外に、絶対配置のボックスがないのであれば、XHTMLなら次のようにすれば解決できる(かもしれない)。
html{
overflow: hidden;
height: 100%;
border: none;
padding: 0;
}
body{
position: static !important;
overflow: auto;
height: 100%;
border: none;
margin-top: 0; margin-bottom: 0;
padding-top: 0; padding-bottom: 0;
}
修正完了。
大丈夫かいな。
人間にとって違う色に見えるとはどういうことだろうか? RGB色空間の二点間における距離が一定以上ある、ということでは無いと思う。RGB色空間は人間の色覚にあわせて作られた空間とは思えない。RGB各方向への重み付けが必要になるからだ。
では単純に明度を求めるための重み付けを利用して、R:G:B = 289:587:114から、(R / 289, G / 587, B / 114)の点同士の距離を考えれば良いのだろうか??
人間の目は緑に鈍感なので、逆に少ない変化で明るく見えているのか。画像圧縮に書かれている次の言葉が気になるなぁ。
人間の目は、明るさに関しては、微妙な違いに敏感であるが、色の違いには敏感ではない。そのため、色の信号の画素数は、明るさ信号の、さらに半分の大きさの情報で良い。
色覚に障害のあるユーザーにとって適切であることを示すには、グレー スケールに変更して色選択が適切に動作することを確認するだけで十分だと考える人がいるかもしれませんが、全く根拠がありません。
この下に実例もあるが、確かにそうだ。Mozillaの選択色交換ではグレースケール時のコントラストを元にしているので、グレースケール上ではまともに機能するが、色覚に障害のある方には、見分けがついてないことがあるのか。ということは、このバグの優先順位を引き上げないとまずいな。
だが、全ての色覚障害とグレースケールを意識して、常にコントラストを保つにはどうすれば良いのだろう? 単純に現在の明度差による検証と、4つの色空間でそれぞれコントラストがあるか検査するしか無いのか?
Firefoxをビルドするとき、メモリがlink.exeに600MB以上奪われて、めちゃくちゃ重くなるのだが、2GBぐらい積めば軽くなるのだろうか。Windows(32bit)でアプリが使えるメモリ容量は実メモリの半分と聞いたことあるので(半分は強制的にカーネルが予約してしまうらしい)、1GBじゃ足らんわなぁ。
文書ソースの前後関係と、ボックスの位置関係に何の関連性も無いことがあるのがCSSレイアウトの最大の欠点だ。このため、キーボード等で、従来通りの設計のUA上で文書ソース順にフォーカスを移動させると、ユーザにはフォーカスの移動先の予測がつかないこともありうる。
もちろんこれはCSS仕様の欠点ではなく、CSS仕様に本当の意味で適合できていないUAに問題がある。UAの使命はユーザにとって使いやすいものを提供することなのだから。この問題に取り組んでいるのは、Mozillaの空間ナビゲーションしか知らないが、他の家電向けブラウザ等ではどうなのだろうか。
しかし、「現実派」な人には深刻だ。シェア世界一位のIEユーザには不便をかけるのだから。(マウスの無い、PCなんて、と考えるかもしれないが、仕事でノートPCを持ち歩く場合にはマウスが使えないことが多いので、意外とキーボードによるナビゲーションは需要がある。)
これを「改善」できるのはタブ順指定だが、これは文書ソースで行うしか無いため、矛盾がある。CSSを処理しなかった場合、タブ順が無茶苦茶になるからだ。当然、これはお勧めできない。
アクセスキーは論外だろう。誰がいちいち、一時的に訪れたサイトのアクセスキー規則を覚えるだろうか? そんなもの、覚えてもそのサイトでしか使えない。また、ブラウザのアクセスキーとのバッティングの問題もある。
positionやfloatを使うなというのは極論すぎるが、あまりにトリッキーなことをしすぎると、訪問者に混乱を与えることになりうるということを知っておくべきだろう。(これを全く知らずに作ったサイトの良い(?)例は、何も知らずにホームページビルダーのどこでも配置モードでデザインされたサイトだ。)
一番良いのは、文書ソース内で、ユーザが使わなさそうなリンクをできるだけ削減し、訪問者がよく利用しそうなリンクを優先的に配置することかもしれない。当然、CSSが適用されない場合には不自然にならないようにしなければいけないので、文書の構成能力が問われると言える。
こういう意味ではタブレットPCというのは、モバイル端末としてアリかもしれない。
dbaronすげぇ。本気だ。早速、作業中のパッチが公開されている。
そういえばもうひとつ。こちらもdbaronが動き出している。Ianと協議の結果、このCSSに準拠しない挙動をどのように実装すべきかを決めたということだが、果たしてどのようになるのか。
私も早く、Geckoのソースを理解できるようにならねば。
24、25日共に起動しない。profileも消したし、アンインストールもしてみたけど駄目。何故??
ask.jpで検索してみると、この日記の目次がひっかかり、内容も表示されている。この、今見てくれている日記本体は.phpという拡張子のためか、データベースにも入って無さそうだが、静的なapplication/xhtml+xmlには対応しているのかもしれない。Yahoo!とGoogleは相変わらず駄目。
roc、休暇出張中だったのか。うーむ。予定狂うなぁ。
ぼんやりとだがゴールが見えてきた。早ければ10月中に決着できるか。
/でFAYTを開始して、リンクでは無いテキストを発見している状態で、タブキーを押しても、そのテキストの前後のリンクにフォーカスが移らないという問題。これも私自身のregression。
修正は完了した。1.8 branchには承認申請中。
このバグの修正で、FAYT中にでツールバーを閉じても、元の位置にフォーカスが戻らない問題が修正可能になっていると思う。ただし、これはregressionではないので1.8 branchでは修正しない予定。
動的擬似クラスによる再reflow時に再度、折り返し処理をやりなおしていなかったバグ。
斉藤さんにより修正された。感謝。
ちなみに、仕様通りの動作だと言えるはずだが、テストケースの挙動が愉快。position: relative;をリンク等で使ってるサイトでよく見かけるループと原理は同じ。
SuiteにもFind Toolbarを、というリクエスト。
FAYTのUIは明らかにFirefoxの方がわかりやすいし、コードもシンプルなので、なんとかしたいけど、頭が痛い。ちなみに、SuiteのFAYTのソースは全てC++で、フロントエンドとバックエンドをソース上で分離できていないのでなかなかに混沌としている。
いつの間にか再現しなくなったらしい。1.8 branchでは未テスト。
IME無効化のパッチを見直してみると、いくつか拡張性に問題のあるコードがある。何でコードを書いていてもよくある自分の欠点なのだが、最適化というか、ケチって書きすぎなんだろうか。