久々にCSSのバグ発見。 なんでこんなバグか発生するのだろう。。。
こちらは上のBug 2890からの派生。 hidden時にはマーカーが要素からはみ出しているわけでもないのに切りとられている雰囲気だ。
再現しなくなっている。WFMとして解決。
Bug 2016で小池さんが本家から見つけ出してきたバグはまだ再現するので、 別バグとして切り分けた。
内容の高さとは、一番上の要素の上マージン辺から、一番下の要素の下マージン辺までだが、 Mozillaは一番上の要素の上マージン辺から、一番下の要素の下ボーダー辺までで高さとしてしまっている。
つまり、一番下の要素のマージンにはアクセスできない、という問題が発生している。
これもいつの間にやら再現しなくなっている。
問題のページは更新されていて、DHTMLも修正されたようだ。
問題ないのでFIXEDとして解決した。
これもいつの間にやら再現しなくなっているが、最近環境をいじったのでそのためかもしれない。 他の方のテスト待ち。
最近、このバグを見た記憶がないのだがどうだろう?
バグの内容を勘違いしていた(^-^;
エンコード結果の文字列は前と違って綺麗にはなっているが。
Windowsでは再現しない、できるだけ多くの人のテストをお願いします。
本家でBorisから仕様通りだと指摘を受けた。 内容についての日本語訳はBugzilla-jpにコメントしてある。
しかし、誤解を受けやすい仕様だと思うので、改善案を出してみた。
Bug 1350の重複として処理。
いい加減、不便なので本家で検索したらやはりあったのでBugzilla-jpにも登録。
テキストのURLをドラッグして新しいタブで開く、というのをよくやるのだが、 blockquote要素のcite属性値を:after等で生成した場合にはこれができない。
ちなみにOpera7では大丈夫なようだ。
昨日このサイトのスタイルシートを変更していて発見。 昨日の雑談にある、ポケモン、BBGという略語の後ろに生成された、略無しの文字で現象を確認できる。
本家にも一応挙げられているバグ。
CSS3では縦書きもサポートされるが、これの実装は容易ではない。 キーワードにhelpwantedがいきなりついている。
これは日本人hackerがどうにかしなければ実装されない可能性が高いのかもしれない。
Windows版IEとの互換性を高めるために作られたと思われるbox-sizingと似た設定を可能にするプロパティ。
個人的にはbox-sizingプロパティは好きになれない。 こちらのみの仕様定着が望ましいと思う。
もしbox-sizingのinheritedがyesになろうものなら人の手では追いにくい規格になってしまうだろう。 一応、今はinheritedはnoになっているが。
「n番目の要素」を表す疑似クラス。 CSS3が一般化すると、最も多くの人が恩恵を受けられる機能だと思う。
これが加われば、大抵の要素をCSSのセレクタで特定可能になってくることだろう。
改善案も敗戦濃厚?
詳しくは私のコメントを見てもらいたいのだが、IEとMozillaでサーバに渡すURIが異なっているのが原因。
個人的には元々のパラメータを削除するMozillaの方が正しい挙動には思えるが根拠はない。
デフォルトのパラメータを渡したい場合はinput[type="hidden"]と、 input[type="image"]の併用でやるべきじゃないのかと思うのだが。
とりあえず詳しい方のコメント募集中。
Bug-org 69114 Opening Internet Shortcuts (.url files) doesn't work (using File | Open or file protocol)だ。
一見、違うバグのようにも見えるが、このバグに重複処理されているBug-org 139937が全く同じことを報告している。
ちなみに余談だが、Windowsにおいて(EXEへの)ショートカットやEXEファイルに対して、あるファイルをドラッグすると、 内部ではコマンドラインからfoo.exe "%1"が実行されたのと同じことになる。 つまり、もう一つアプリケーションが実行されるのでパフォーマンスは悪い。
スタイルシート切り替え時にGenerate Contentが再生成されなかった問題が修正された。 Opera7でもこの機能はうまく動作しない(置換要素との絡みがうまく動作しない?)ので完全にMozillaのアドバンテージ。
でも、スタイルシート切り換えのインターフェイスはOpera7の方が実用的だよなぁ。
ところでGenerate ContentはCSS3では重要なファクターになりそうなので是非完全な実装を急いでもらいたいものだ。
MacのIEに変わるデフォルトブラウザ、Safariがpublic betaとして公開されたようですね。
Open source For its Web page rendering engine, Safari draws on software from the Konqueror open source project.
とあり、Linux(KDE)のKonquerorがベースのようです。
Webページを作る人でMac環境が無い場合、やはりLinux版との互換性が気になるところです。 Mozilla(Gecko)のようにバグも性能もほぼ同じならプラットフォームを気にせずにテスト可能ということになるのですが。。。
そういうわけで、Geckoベースのブラウザ(例えばChimera)がMac標準になってくれるとWindowsユーザとしては非常にありがたかったんですけど。
Bug 2916 Comment 5、kazunaさんのコメント。
------- Additional Comment #5 From kazuna 2003-01-12 15:53 -------
ご指摘の通り、bug 2497と重複していました。
お手数お掛けしてしまい、申し訳ありません。
しかし、バグが重複していないか調べるのは難しいのですね。
同じ問題でも、言い方のニュアンスは様々ですから…。
これは1.0リリース前から想定していた内容で、一応対応策は打たれている。次の検索方法を試してみて欲しい。
Safariが"like Gecko"と名乗ってきたため、 先日公開したIsGecko関数がSafariもGeckoブラウザとして認識してしまう問題。
実際にブラウザ判別を厳密に行う場合はMozilla/Netscapeを中心に行うのが基本だ。 他のブラウザはMozilla/Netscapeのユーザーエージェント名を偽装しているのだから、 何の偽装も行っていないMozilla/Netscapeは一番情報量が少ない。 情報の多いものから切り分けていって残ったものがMozillaと判断する方が単純だ。
例えば、IEとSafariとGeckoブラウザを判別したければ、まずは"Safari"を調べ、 違うなら"MSIE"を調べ、 それでも違うなら"Gecko"を調べる。 この手順ならトリッキーなことを行わなくてもよいことが分かるだろう。
しかし、公開しているIsGecko関数は前置き無しにGeckoブラウザであることを判別できるようにしているため、 若干正攻法では無いロジックになってしまった。
以下は春永さんが調べてくれたSafariの偽装状況である。かなり非道い。 ここまで偽装するなら、それなりに高性能なレンダリングエンジンであって欲しいが、 どうもそうではないらしいので頭が痛い。。。
- navigator.product = Gecko
- navigator.userAgent = Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/51 (like Gecko) Safari/51
- navigator.appCodeName = Mozilla
- navigator.appName = Netscape
- navigator.appVersion = 5.0 (Macintosh; U; PPC Mac OS X; ja-jp) AppleWebKit/51 (like Gecko) Safari/51
Bug 670がborder-collapse:collapse;の場合でも再現するかテストしようとしたら、
それ以前の問題だった(^-^;
要約、長っ。
Mozillaのバグかどうか判断しかねています。 個人的にはOpera7(Beta2)のほうが正しいレンダリング結果だと思うのですが。
全く再現しなくなっている。
石川さんのサイトで問題が発覚。 どうもtbodyを疑似フレーム化するとテーブルのセルの幅調整が正しく全行で連動しないようだ。
やはり他のOSでも発生するのだろうか。
対応してもらえない、というより無反応。 企業のWebブラウザの多様化に対する取り組みはかなり低いレベルにあるという話。
というか、私の現在の顧客はWindows版IEと昔のNetscape Navigatorしか知らない模様。 企業内でWeb関係の話に口出せる人って、こういう人が意外と多いのではないだろうか。
そうでなければ、少なくともNetscape7やMozillaはもっとサイト作者の期待通りに表示され、 Web標準普及プロジェクトにCriticalもしくはMajorなバグが登録されないと思うのだが。
Javascriptの速度を比較するのに円周率計算はどうなのかな。 確かにJavascriptそのものの速度としては良いと思うけど、ブラウザとしての速度を比較するなら、 いわゆるDHTMLという奴で比較するべきだと思う。
piroさんのコンテキストメニュー拡張を入れてみようかと思ったら、散々な目にあったので、本家で探してみたら発見。
原因はIMEのON/OFFではないようだ。 AltキーのKEYDOWNでキャレットが消えてしまう。
22日のビルドはかなり良い。 こんなにも一夜での変化が大きいビルドは0.9.4+の時以来ではないだろうか。 そのかわりに不安定極まりないが。
[Advanced] -> [Keyboard Navigation]はかなり便利になる人もいるのではないかと。 私はマウスでの操作のほうが圧倒的に多いのであまり関係ありませんが。
実害はないものの、非常に鬱陶しかったこのバグが修正された。
22日版のビルドで発生していたフォント周りのバグは23日版のビルドで一掃されているようだ。
WindowsではInstallerが変更されている。 Bug-org 186703の修正によるもののようだ。 ただし、この弊害としてBug-org 189462が出ていたようだ。 だから22日版のビルドはインストールに失敗していたのか。。。(3つの時間帯のビルドをダウンロードして、起動に成功したのは1つのビルドのみ。。。)
しかし、この変更のおかげで標準でGRE環境が構築されるようになった。 GREはバージョンごとにフォルダを分けてインストールされるようなので、 IEのように異なるバージョンの共存ができない、という事態は避けられそうだ。
GREを利用するなら、今までのMozillaは一度アンインストールしておくべきだ。 (今までのMozillaに)上書きインストールしてみても特に異常は出なかったが、 ディスクスペースを無駄に使用することになるのでアンインストールすることをお勧めする。
一応、GREを使わないようにもインストーラで選択できるようだ(動作未確認)。
GRE付きでインストールしても、「プログラムの追加と削除」にはGREのアンインストールは見えない。 GRE\uninstallにはGRE用のアンインストーラが存在しているが、こちらも動作未確認。 ちなみに、Mozilla(1.3b)を「プログラムの追加と削除」から消すと、GREも同時にアンインストールされていた。
24日のビルドまではファイルのダウンロードができないという問題(Bug-org 190465)があったが、 25日のビルドでは再現しなくなっている。
ようやく使えるビルドが帰ってきた。
検索キーワード無しで検索したらどうなるのか。
何故か突然気になったので試してみました。
Charlotteは推測ですが、TINAMIと同じ管理会社なのでたぶん間違っていないと思います。 何故か、infoseekは無反応です。
個人的には未入力エラーが出るのが望ましいと思うのですが、どうでしょう?。
frameキーワードを追加した。 このキーワードはHTMLのframe関連の問題と、iframeの問題に付加されているので活用してほしい。
あまりに長い間、regressionが続いているので本家で探して登録した。 また、もうひとつのケースが登録されていたので、そちらも登録している(Bug 2937)。
これも前々から気になっていたので登録。
1.3bのブロッカーバグとなっている。 だいたいの原因と思われるバグは発見(Bug-org 132489)。
これが修正されないと1.3bのリリースは遅れていく。 hackできる人は是非協力して欲しい。
ところで、どうでも良い話だが、私はこのバグで初めてAsaと同じバグに(同時期に)コメントをつけている。