この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
ATOK限定のバグの模様。ATOKはメッセージ送信の順番が間違っている。 前にも似た原因のバグがあったわけだが、ATOKはソフトの性能は良いのに、実装がどうにもよろしくない。
他のバグとのパッチの兼ね合いからMozilla 1.9aでの修正になってしまうかもしれない。
fantasaiによると、
Relevant values for text-justify would be auto | inter-word | inter-ideograph | distribute
とのこと。
Bug-org 272964が修正されたのでMacでもBug 2515が再現しなくなったはずである(Suite、Firefoxではもともと再現しない。Caminoのみ修正)。
パッチを提供してくれたwaveriderさんに感謝。
ようやくパッチが完成。nsTextFrameが分割されていた訳ではないことに気づくまで時間がかかったのが敗因。
こちらもパッチがひとまず完成。
今選択している要素に、どのスタイルシートの指定が利いているのかわかるようなものがあれば、ぜひ欲しい。カスケード順とかも。
DOM Inspectorで調査できますよ。 DOM Inspectorで要素を選択後(Find a node to inspect by clicking on itを有効にして、MozillaならDOM Inspectorの下半分の、Firefoxなら起動した元のウインドウをクリックすると直感的に選択できます)、右ペインをCSS Style Rulesにして、あとは適用されているスタイルシートを調べるだけです。カスケード順も見ることができますよ。
中野さんのところはアンテナでもなぜか更新検知してくれないので（アンテナに指定している URL が良くないのかも知れないけど）。
昔は質問箱に書いてあったと思うのですが、はてなアンテナは内容を独自のアルゴリズムで解析して変化の有無を検出するとのことでした。(うろおぼえ)
このweblogは更新チェッカやアンテナからのアクセスがあった場合、負荷軽減のために通常の内容を送信しません。送信しているのは最後に更新された内容の更新日時と、内容として各トピックの見出しだけが送信されています。ですから、はてなアンテナではhn要素の内容変化は無視する、という形なのかもしれません。そうであれば、更新があたかも無かったかのように見えます。詳しくははてなに問い合わせてもらった方が良いかと思います。
万が一、やる気が出て、If-Modified-Sinceに対応すれば問題無くなるのではないかと思いますが、面倒なので今のところやる気がありません。(やりたいとは思っている)
おこめさんお待ちかねのバグ。
1.8a6に滑り込みで修正が間に合った。
久々に純粋なCSSの話題でも。
<a href=""><img>text</a> で、a img { border: 0px; } にすると、img の下線が消えない、<a href=""><img></a>text<a href=""></a> だと消える。
まず、画像の下に表示されている下線はa[href]{ text-decoration: underline; }の下線なので、borderでは消せません。
続いて次の<a href=""><img></a>text<a href=""></a>
は<a href=""><img></a><a href="">text</a>のことだと思いますが、そうであれば、前者と後者は意味が異なります。仕様書を見てみましょう。text-decorationには次のようなことが書かれています。
要素に内容又はHTMLのIMG要素などのテキスト内容がない場合，利用者エージェントはこの特性を 無視しなければならない。
つまり、後者の一つめのimg要素しか内容に持たないa要素ではtext-decorationは無視され、二つめのテキストを内容に持つa要素ではtext-decorationは適用されることになります。それに対して前者では画像とテキストを内容に持つので全体にtext-decorationが適用されて、画像の下にも下線が表示される訳です。
ようやく修正完了。これで、CJKのjustificationはIEに追いつき、追い抜いた形になる(IEはjustifiable文字の定義が仕様書とは違っている。Microsoftはまたしても先行実装による過ちを繰り返したことになる)。
修正完了。
原因は、「詳細なテキストサービス」が無効の場合、MS-IMEがフォーカスを移すたびに不要なWM_GETMINMAXINFOメッセージをフォーカスを取得したウインドウに送信していたため。 WM_GETMINMAXINFOはウインドウのサイズが変更される際にトップレベルウインドウが受け取るもので、本来、それ以外のウインドウが受け取ることはない。 そこで、トップレベルウインドウ以外がこのメッセージを受け取った場合には無視するように修正している。
ところで、「詳細なテキストサービス」をオフにしているとMS-IMEのこのバグ(?)のため、フォーカス移動に時間がかかるようになる。顕著なのが、ブラウザのキャンバスがフォーカスを持っている時にメニューを開こうとした時だ。この時、ワンテンポ遅れてメニューは展開される。
XULのメニューの展開が遅いと文句を言う人で「詳細なテキストサービス」を無効にして、MS-IMEを利用している人は、それは文句を言う相手が違う。悪いのはMS-IMEである。
「詳細なテキストサービス」を無効にしたい人はATOK等、他のIMEを利用することをお勧めする。とりあえずATOKではこの問題が発生しないことを確認している。
徳島では、JustSystemのお膝元にもかかわらず、ATOK X単品で手に入らないのでバンドルされてるTurbo Linuxを買ってきた。
なぜかFedora Core 3ではWindowsマシンと通信できなかったり、DVDはマウントできるのにCDがマウントできなかった問題が解決されたものの、他にも細かい問題が山積していてなかなか長時間使える環境にはほど遠い状況。
それにしても、一社が強力なリーダーシップで設計したデスクトップに比べ、Linuxでは各開発者がバラバラに仕事をしている印象がある。 RPMというシステムがあってもインストール時にショートカットをメニューに登録してくれないとか、そういった「決めごと」が無いのはWindowsというぬるま湯につかっている私からすれば非常に不便。
長らく愛用してきたA4 TECHのマウスがLinux環境では暴走して使い物にならないのでMSのインテリマウスを買ってきた(でも、まだ正常に動作するのか未確認)。
高いだけあって(といってもバルクで安く仕入れてるけど)、手へのフィット感とかマウスの使い心地は上々。でも、フォーカスのあるウインドウでしかホイールが使えないという仕様はどうにもなじまない。サードパーティの製品に多い、カーソル位置のウインドウのスクロールを制御してくれる方が直感的だと思う。
ちなみに、Mozillaではチルトホイールで横スクロールも対応しているのでA4 TECHのマウスよりも便利。
転送速度が有線に比べて遅いのでいままで導入してなかったものの、ノートPCのLANケーブルの断線を機にノートPCだけ無線LANにすることにした。
ところが無線LANのアクセスポイントが徳島中のPCショップをまわっても売っていない。仕方ないので電器屋を周っていると一件だけ売っていたので購入。
つくづく電気街のあるところに住みたいと思わされた。
名前が思いつかなくてただのweblogとしていたものの、最近hackingに関する内容が多いのでこの名前に変更。
そういえば正月休みが明けてから休みを取るのを忘れていた。 もっとも、正月休みも帰省していた一日を除けばbugzillaではごにょごにょとやっていたので完全に休んでいた日は少ないのだが。本家に動きがないし少し休もうかな。でもbugzillaはやってるんだろうなぁ。
Borland社のVCLはオブジェクトの基本的な形を定義して、継承により多態化させ、オブジェクト間の通信はできる限り少なくし、オブジェクトをシンプルな完成型としていたのに対し、Mozillaではオブジェクトが複雑に絡み合い、互いに頻繁に通信しあっている。
要するに互いに非常に対照的な設計だが、どちらが優れているのかは視点によって変わりそうだ。VCLは固く、Mozillaは柔らかいが、VCLはさらっとしていて、Mozillaはべっとりしている。
これらの違いは企業の開発プロセスと、オープンソースの開発プロセスの違いが形になったもののようで面白い。
拡張性はMozillaのような設計の方が上だけど、スパゲッティ化のしやすさも顕著。VCLはその逆のイメージがある。これを外側から見てみると、プロプラエタリなソフトとオープンソースのソフトのそれぞれの特徴としてにじみ出ているように思える。
オープンソースのソフトの進化の速さも、なんでこんな簡単そうなバグがとられないんだろう、というのもソースコードの設計の特徴から出た結果なのだろう。
ウィジットを修正、というか仕様変更するととても長い道のりになってしまうので、Windows版IEの挙動と同じように、IMEで未確定文字が入力されている間はオートコンプリートのウインドウ自体を消してしまうことにした。
今は、とりあえずなパッチで再現しなくなっているこの問題もようやく原因が分かった。 イベントの発生順序がまずいのだ。
Mozillaはエディタがフォーカスを失う際に、未確定文字列があると強制確定する。 つまり、フォーカスを失った後に未確定文字が確定され、入力のイベントが走る。 そのため、フォーカスを失うと同時にファイナライズしたのに、来るはずのない入力イベントがやってきて破綻していたのだ。
とりあえず、呼び出し前にフォーカスを失っていないかどうかのチェックを行うようにしたが、XULからのアクセスでもクラッシュしてしまうので、回避パッチはそのままにしてある。
もっと根本的な解決策として、フォーカス喪失寸前のイベントを作り、そこで強制確定を実行すべきだろう。 やるかどうかは別にして……
Netscape6.0の頃(Mozilla 0.6の頃)から問題として挙げられていた問題だが、ついに修正完了。 言語グループごとにserifかsans-serifかを設定できるようになった。
しかし、懸案が一つ残っている。 現在の設計では、
<p lang="ja">ああああ<span lang="en">aaaaaaa</span></p>
このような場合に、span要素の内容だけがserifになるかというと、そうではない。
よく考えてみて欲しい。CSSの継承という考え方でいくと、jaのsans-serifが継承されて、enの要素もsans-serifとなっているのである。
今、Mozillaはルート要素にsans-serifかserifかを設定に基づいて指定するようになっている。つまり、この設計のままでは要素ごとにこれらを切り替えることはできない。しかし、もし、新しいフォントの一般名、例えば-moz-defaultというものでも作り、ルート要素にこれを指定し、継承させていけば切り替えも可能ではある。
しかし、本音は「面倒だなぁ」ということだ。
鬱陶しかったこのバグがようやく修正された。
最近のNightlyでやたらとクラッシュしていたバグがこれ。修正されている。
エディタ以外でIMEを無効化するためには……
IME有効化/無効化のAPIの実装問題として、使用する隠しAPI(?)がMinGWのライブラリでは宣言されていない。どうしたものか。
SuiteでFAYT開始時にIMEを有効化するのはダメっぽい。
特に問題なし
一文字目はタイプしたキーだが、二文字目はIMEの未確定文字列になる。これは不便
IMEを有効化すると共にIMEをオフにするという手もあるが、Windows以外では将来的にもIMEを無効化できるようになったとしてもON/OFFは制御できないっぽいのでボツ。
結論としてはFAYTをオフにしている場合、もしくは新設する設定項目(例えば、ime.disabled.inNonEditor)が有効な場合にはエディタ以外でIMEをオフにするべきか。
新規設定項目はSuiteではFAYTでIMEを利用できなくする代わりに他のバグを抑制するためのもの。 元々FAYTでIMEが使えないFirefoxやFAYTの無いThunderbirdではこの設定を有効にしておくことで、単なるバグ修正にできる。
ところで、中野さんの Weblog、2004年8月～12月の過去ログが見当たらないようですが、、、
link要素でのみナビゲーションを貼ってるのでデフォルトのFirefoxでは見えないだけです。 改善しようと思いつつ、面倒なので……そのうち対応します。
levelさんのところを見ていて改めて思いましたが、(汚く、荒っぽい言葉で)人を批判するヤツに限って捨てることを前提としたハンドルネームだよなぁと。 最近、特にこういう人間が多いように思います。 こういう匿名なら強気の人間が出現しやすいというのは、2ちゃんねるの悪しき風習なのかな。
固定されたハンドルネームで発言する人というのはそれなりに自分の発言に責任を持っているように思えます。例えば、自分のblog上で発言するというのは、自分がそのハンドルネームで築き上げてきたもの、例えばそのハンドルネームの人の発言に対する信頼度や、そのサイトそのものの存在等を賭けて発言してるわけですが、匿名なら何も捨てるものが無い状態で発言しているわけで、このへんに意識の違いというものが出てくると思います。
そもそも、そういう人は他人を批判する場合であっても、あんな人としてどうかと思うような言葉遣いではなく、それなりに節度を持って発言する訳ですが。
まあ、内容に関わらず、この匿名、捨てハンドルがとても嫌いなので、このもずはっく日記にはコメントをつける機能を追加する気がなかったりします。だって、最近、そういう人の方が多いですから。(メールですらこんなのがたまに来たりするのには閉口。何考えてんねん、と言いたくなる。)
あ、それから、この日記はバグに関するリポートが大半なので、意見があればbugzillaに直接書き込んでもらって、情報の分散を避けたい、というのもありますが、まあ、先の理由の方が大きいです。
Justin Woodから1.8bへのゴーサインが出たものの、改めてテストしているとIEとの差異が少し気になる。 とりあえずさらに論理的で適当なロジックが思いつかないので、そのまま投げてみようかと思案中。
このパッチでは背景色が不明なので前景色から疑似背景色を仮定して処理するのだが、疑似背景色はHSLに一度変換してからSとLの数値だけをいじる方が現実的な解になるのだろうか。 現在のパッチでは単純にRGB空間の反対側にある色を疑似背景色としている。 どちらも結果に差が出にくいとは思うが、あらゆる前景色、背景色、選択文字列前景色、選択文字列背景色の組み合わせをテストすることはできないので理責めだけでロジックを決定しなくてはいけないところが難しい。
考えれば考えるほど難しい。ひとつ、幻想があるとすれば、IEの処理が完成型である、ということだろう。 IEでも問題のあるページはある。例えば、前景色が黄緑の場合、背景が白だとコントラスト不足から目がチカチカするので、背景色は暗くする。黒バックに黄緑の文字、というとイメージが湧くのではないかと思う。この場合、Winのデフォルトの選択色(背景が紺で、前景が白)の場合に選択色をそのまま使ってしまうため、見にくくなる。
WinIEはその挙動から仕様を推測すると、単純にRGB色空間でのみ処理している様だ。つまり、緑に弱い。有名な話だが、人間は緑に対して鈍感なのでRGB色空間での処理には無理がある。もし、それでもやるなら重み付けが必要だが、IEではそれもやっていないようだ。
この問題は、W3Cのドキュメントにあるように、YIQ色空間のYを使うことで解決できる。 Yの算出方法である、
((Red value × 299) + (Green value × 587) + (Blue value × 114)) / 1000
この計算式からもそれは明かである。