最近、背景にアニメーションGIFを使っているサイトの表示が軽くなったように思えたので本家を漁ってみたら色々と修正されていたようだ。
helpwantedキーワードを細分化してtestwantedキーワードを追加した。
スタッフのテスト環境で全てのバグの検証ができるわけではないので、 もしこのキーワードを発見したら是非あなたの協力を頂きたい。
外部スタイルシートを優先スタイルシートとして複数のグループにしているため、Mozillaでは全てが適用されないという問題。 仕様は若干グレーな感じだが、次の文がMozillaの解釈が正しく、IE, Operaの解釈がバグであることを物語っている。
著者は、代替スタイルシート群の1つを、優先スタイルシートに指定できる。 ユーザエージェントは、 ユーザが別の代替スタイルシートを選ばない限り、著者による優先スタイルシートを適用しなければならない。
つまり優先スタイルシートとはデフォルトの代替スタイルシートを著者が指定するためのということだ。
著者は、優先スタイルシートも含め、複数の代替スタイルシートを1つのスタイル名でグループ化することができる。 ユーザが、ある命名されたスタイルを選択する場合、ユーザエージェントはその名前を持つすべてのスタイルシートを適用しなければならない。 ユーザエージェントは、別のスタイル名を持つ代替スタイルシートを適用してはならない。 外部スタイルシートの指定の項で、スタイルシートのグループへの命名法を解説する。
そしてここでは同じtitle属性を共有する外部スタイルシートが連動して動作すべきであることを暗示しているが、 優先スタイルシートの扱いにはあまり触れていない。 先に1つを優先スタイルシートに指定できると断っているからだろう。 つまり、問題の複数の優先スタイルシートがある、 という状況は(Validatorには引っかからないものの)Invalidなのではないだろうかとも思わせる。
もし2つ以上のLINK要素が優先スタイルシートを指定している場合は、最初のものが優先する。
しかし最後に補足があり、2つ以上あった場合は最初に出現する優先スタイルシートが優先するとある。 つまり、最初のスタイルシートが代替スタイルシートで選択された状態で表示されるべきであり、 その場合、別の名前を持つ優先スタイルシートは表示されてはいけないことになる。
先方から返信があり、システムリリースの都合ですぐには対応できないが善処したいとのこと。
報告された内容とは再現条件が異なっていたが確かに再現する。 本家に同じバグがあったので担当した。
インラインボックス(平たく言えば「行」)に続いて出現する、 float要素のマージン辺(外上辺)は最後のインラインボックスの上端と一致するのが正しい配置方法だ。
仕様書はこれより上に超えてはいけないと書かれている。 だからMozillaの現在の「最後のインラインボックスの下端に合わせて配置する」という表示はバグではなく (Mozillaの)仕様として、わざと処理しているのかと思いこんでいた。 しかし本家でこのバグを発見したので単なるバグだったことが判明した。
Windowsビルドで起動時にクラッシュしていたこのバグが修正された。
ようやくWindowsのNightlyも使えるモノが戻ってきた。
修正された。実に快適。
多くの(Windows SDK用語での)Windowの基底クラスとなるクラスのコンストラクタを修正したため(たぶん)、 似たようなバグだった次の2つのバグも再現しなくなっている。
こちらはいつの間にやら再現しなくなっているのでWORKSFORMEとして処理した。
修正されている。
新しいウインドウを開いた場合と、新しいタブを開いた場合とで挙動は統一されたわけだが、なんだか違和感があるなぁ。
サポートブラウザの一覧にMozillaが無いだけの状態になったようなので(つまり利用はできる)、 重要度をcriticalからnormalに引き下げた。
UL,OL要素のpadding内にはみ出しているリストマーカーはoverflow:hidden;で切り取られるのは正しい挙動なのでINVAとして処理された。
ちょっと気になったので各ブラウザのリストの表示の仕方を見てみた。 Mozilla,Opera,IEで三者三様の表示だ。
再現率が100%ではない、難しい問題。 C++が読めて座標系の処理に強い人募集中。
新規タブを開いたときの挙動に関する問題。
ユーザとしての私はウインドウを開いた場合とタブを開いた場合との挙動を個別に設定できるべきだと思う。 しかし、プログラマとしては(prefs.jsでの直接設定ではなく)PreferencesダイアログからのUIによる設定を追加することは好ましくないと思う。 設定は大雑把では使いにくいが細かすぎても使いにくいものである(特に入れ込んで使っていないソフトほど)。 ブラウザというのは使用時間が長い割にこだわって使っている人は少ないと思うのだ。あ、OSなんかはもっとか(笑)
修正を確認できた。
この手のバグは勘弁して欲しいなぁ。 妙にストレスがたまるんで。
MIMEタイプに関する問題。 さすがにWebデザイン系の企業なためか、一般的な企業より遙かに迅速な対応をしてくれた。 たぶん最速。
ところでこういったMIMEタイプに厳格なところや、"Should not"な仕様をサポートしないところ等を批判する人は多いが、 現状にあわせてばかりではWebは一向に標準化の道を前進できないと思う。 Webブラウザ間の互換性が高くなること(つまり、どのブラウザを使っても普通にWeb生活に困らないということ)を良いことだと思わない人は少ないと思う。 仕様に厳格であるということはその状況をより早く実現するために必要なことだと思うのだがどうだろうか?
Bug 3039の続き。
floatにwidthを明示していないために各ブラウザの拡大解釈の差で見た目が食い違っている問題。 一応修正版は完成している。
Ctrl+0でText Zoomをリセットできるが、ショートカットキーの一覧に記述が無いというもの。 この機能、知らない人が多そう。
簡単なミスだが、1年以上経った今でも放置されている問題。 このサイト自体、更新されていないようにも見える。
こういうWebサイトの長期にわたる放置状態は、無責任なことであり、あってはならないことだと思う。
修正してもらえた。
しかし、TOPページでも告知しているとおり、「Internet Explorer Ver5.5以上」で、正しく表示される様にと目指して作成しています
という回答が。
この日本独特の悪習はいつまで続くのだろうか。 このような表記が堂々と各サイトに載っている間は日本はWebに関して後進国なのだと思う。
Webは「ブラウザありき」ではなく、「HTML文書があってそれを読みやすくするためにブラウザがある」という当たり前の図式が何故か崩れたままだ。
要素が<A><B></A></B>となっているため、Windows版IEとMozillaとではDOMツリーの解釈に差が出ている問題。
サンプルを用意して再びメールを出した。
今回も無視されるようならWONTFIXとして閉じる予定だ。
早速修正されている。誰も気づいていなかっただけ??(^-^;
右クリックによるコンテキストメニューから画像を盗られないようにするためのスクリプトがMozillaでは動いていないという問題。
Comment 4の理由からINVAとして閉じてよい問題だと思う。
縦書きに関する問題。
CSS3 TextModuleの正式勧告を待って、 IEの先行実装をネタに修正案を再提案することにした。
POST後の文字化けに関する問題。
残念ながら他のスタッフからの意見が出なかったので、暫定対応として要望という形でJPNICに連絡した。 近日中に私の意見をまとめて、新しいバグをたて、 この問題に対してWeb標準化プロダクトがどのように対応すべきかを決定するつもりだ。
担当の方からメールが返ってきた。
対応を検討中とのこと。 ただし、リソース的には厳しいと書かれている。何のリソースが厳しいのだろうか(^-^; 人?それともサーバもしくはネットワーク資源?
対応してもらえた。
それにしてもこの会社は対応が速い。すばらしい。 他の企業も見習ってもらいたいものだ。
かなり大きな修正が入り、ブックマークまわりの挙動が大きく改善されている。
ちなみに2003032611-trunk/WinXPをいつも通り上書きインストールすると非常に不安定だった。 出た症状は次のようなもの。
私の環境ではcomponentsディレクトリを削除してから上書きインストールしなおすと正常に動作するようになった。 ちなみにcompreg.datだけでは治らなかった。
JPで3桁、本家で5桁のバグだ。 ようやく修正された。
personal toolbarの右側の余白部分でコンテキストメニューから新しいフォルダを作っても、 一番右端にフォルダができなかったという(見た目に)不自然な問題。 これも修正されている。
personal toolbarの右側の余白部分が何故かドラッグできていた問題。 ドロップしても何も無いのだが。
この問題も再現しなくなっている。
メインメニューにあるbookmarksもpersonal toolbarのbookmarksと同じようにドラッグを受け入れるためにメニューを開くべきだという問題。
この問題もWin/Linuxでは解消している。 Macでは駄目なようで、REOPENされているが。