Bug 1512 MSJで買い物ができない[We can't do shopping in msj.]
マイクロソフトのサイトで買い物ができなかった問題。
買い物かごは現在正常に動作しているように見える。 確認を頼んだものの、誰からも反応がないのでとりあえずFIXEDとした(^-^;
マイクロソフトのサイトで買い物ができなかった問題。
買い物かごは現在正常に動作しているように見える。 確認を頼んだものの、誰からも反応がないのでとりあえずFIXEDとした(^-^;
ブロックレベル要素を縦方向にセンタリングしようとしてできていなかった問題。 修正されたようで、今は縦方向にもセンタリングされている。FIXEDとした。
ところで、この縦方向へのセンタリング、CSSでは真似できないことではないだろうか。 まあ、普通は需要が無いとは思うが。。。
空白類が行高に影響を及ぼしているという問題。 斉藤さんに話を振ったところ、即座にパッチを作成してくれた。スバラシイ。
今のMozillaのmarqueeは非常に問題が多い。 それらをまとめて報告されてしまった。
バグを報告する際は小分けにしてください。
この問題は根が深い。まずはdisplay:inline-block;
のサポートが必要だろう。
inline-blockを昔風に一言であらわしてみると、「前後で改行されないブロックレベル要素」といったところか。
仕様書では置換要素(img要素等)で例えられている。
インライン要素なのにwidthとheightが指定できると考えれば良いだろう。
欧文フォントで○や●等が小さく表示されるという問題。 具体的に名前の挙げられていたArialで○や●を見てみるとx-heightの高さ分でこれらの文字が入っていた。
正常に表示できているわけだからINVAとして解決した。
本家でパッチがcheck inされたため、 私の愛用しているA4techのWOP-35では問題がなくなった。
しかし、IBM製品ではまだ問題が再現するとも報告されている。
パッチを見てもらいたいが、これはMozillaのバグというよりは機能追加のようなものだ。 MozillaのスクロールバーはWindowsのスクロールバーとは異なるのでマウスウェアが同等に扱ってくれていないので、 Mozilla側で騙してしまおうというのがこのパッチだ(たぶん)。 そのため、このバグには絶対的なFIXEDというのはあり得ない。 是非、様々な環境でのテスト結果を私たちに報告して欲しい。
ページ上のURLをD&Dできなくなってしまっていた問題。
大島さんによればLinuxでも同時に修正されたとのこと。 私はLinuxのことを良く知らないが、 パッチを見る限りはクロスプラットフォームなソースでバグっていたということなのだろう。 いやはや、Windows特有のOLE関連のインターフェース処理を他のOSでも同じように動作できるようにカプセル化できるとは。。。 私のような素人プログラマには別世界の話だ。<未だにCOMとかOLEがよくわからない
修正されている。
しかし、hoverで位置がずれるとクラッシュするので新しくBug 2879を開いた。 細かい条件はまだ未調査(^-^;
横スクロール用のメッセージは現在のMozillaではサポートされているようだ。 しかし、そのメッセージ自体をマウスウェアは投げてくれない。 Netscape6から考えても2年経っているのでMozillaのウインドウ上ならWM_MOUSEWHEELを投げておけ、ってな状況なんだと思われる。
ようやく修正された。
810565といい、急にMSの態度が軟化しているように思えるのは気のせい?
報告者の大島さんによればMinimum font sizeの設定のためだったようだ。 結果としてINVAにしている。
Minimum font sizeは便利な機能だ。 これを設定しておくとこれより小さいサイズが指定されているページでも、 それらの文字はこの設定値で表示してくれる。 この機能はデザイン重視が行きすぎているサイトで、メニューの文字が小さすぎて読みにくい場合なんかには威力を発揮する。
ついにこのバグが修正された!!
MAXLENGTH属性は入力可能な最大文字数を指定するものだが、日本語入力の変換前の文字がこの文字数制限を受けてしまい、 また、その文字数のカウントもうまくいっていなかった問題。
発見から実に長い時間がかかったが、今回も神尾さんのおかげで修正された。
このバグの修正で事実上、Webからのデータ入力に問題はなくなったのではないかと思う。 つまり、商用サイト等でMozillaのサポートが増えていくことが期待できるだろう。 是非、次のNetscape7(7.02?)にも組み込んでもらいたいものだ。
大島さんからのご指名なんで調査。 z-indexに負の値が設定されていることが原因。既知のバグなので重複として処理した。
この手の問題での私の調査方法をひとつ紹介。
今回のようにStrictな作りのサイトでの問題の場合は既知の問題である可能性が高い。 なぜなら整然と作られたStrictなサイトで発生する問題は、 プログラムにおいて最も多い特殊な条件の重なりによるバグである可能性は低く、 それに加えて今のMozillaにおいて単純なパターンで再現するバグは少なくなってきているからだ。
それを前提にCSSファイルを見てみるとz-indexに負の値が設定されているのを見つけることができる。
しかしこれだけでは当然他のバグの可能性もあるので実際に値を変更してテストを行うのだが、この時に便利なのがDOM Inspector。 DOM Inspectorに該当のページを読み込ませて左側ツリーをDOM NodesからStyleSheetsに変更して、問題のCSSファイルを選択する。 そうすると右上にセレクタの一覧が表示されるので問題の指定のあるセレクタを選択する。 今度はその下側のリストにプロパティと値の一覧が表示されるので、 z-indexプロパティを選択してコンテキストメニューからEditを選択し、値をゼロに変更。 DOM Inspctorの下半分に表示されているレンダリング結果にこの修正が即反映され、正常に表示された。
わざわざ必要なファイルをダウンロードしてソースを触らなくてもテストできるわけだ。 かなり便利な機能なのでまだ試したことない人は試してみて欲しい。 意外とクリエイター以外の人にも使い道があったり。
報告時の問題は既に解消されている。 Bug-org 93274は別問題ではないだろうか。
話の全体がよく見えないので春永さんに担当を変更。 専門用語で押しつけとも言う(^-^;
この問題はデリケートだ。 物事の発端はBug 2500のFIXによるもの。
基本的にWeb標準化プロダクトでは以下の方針を採っている。
「Mozillaで見ることができれば良い」ではなく、 「Mozillaでも見ることができるように誤ったソースを修正してもらう」というのが基本理念だ。
しかし、今回の問題はMozillaもサイト側も仕様違反は無い。 ただ、サイト側の文字コード無指定は落ち度と言えなくもない(仕様違反ではないが、望ましい作りとは言えない)。
文字コード判定は完璧には原理上できない。それが難しいところである。