この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。

現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。

もずはっく日記(2005年1月)

2005年1月2日

Bug 3892 [ATOK Only] パスワード入力で間違って日本語を途中まで入力した時、正しく入力しなおしても正しく送信されない 初回投稿日時: 2005年01月02日00時59分42秒
カテゴリ: Mozilla Core
固定リンク: id=2005010200
リンク元: 0件
SNS: (list)

ATOK限定のバグの模様。ATOKはメッセージ送信の順番が間違っている。 前にも似た原因のバグがあったわけだが、ATOKはソフトの性能は良いのに、実装がどうにもよろしくない。

他のバグとのパッチの兼ね合いからMozilla 1.9aでの修正になってしまうかもしれない。

2005年1月7日

2005年1月8日

Re: CSS インスペクタ 初回投稿日時: 2005年01月08日01時52分17秒
カテゴリ: CSS Firefox Suite
固定リンク: id=2005010800
リンク元: 1件
SNS: (list)

今選択している要素に、どのスタイルシートの指定が利いているのかわかるようなものがあれば、ぜひ欲しい。カスケード順とかも。

DOM Inspectorで調査できますよ。 DOM Inspectorで要素を選択後(Find a node to inspect by clicking on itを有効にして、MozillaならDOM Inspectorの下半分の、Firefoxなら起動した元のウインドウをクリックすると直感的に選択できます)、右ペインをCSS Style Rulesにして、あとは適用されているスタイルシートを調べるだけです。カスケード順も見ることができますよ。

2005年1月11日

はてなアンテナ 初回投稿日時: 2005年01月11日00時09分02秒
最終更新日時: 2005年01月11日00時10分05秒
カテゴリ: WebStudio
固定リンク: id=2005011100
リンク元: 0件
SNS: (list)

中野さんのところはアンテナでもなぜか更新検知してくれないので(アンテナに指定している URL が良くないのかも知れないけど)。

昔は質問箱に書いてあったと思うのですが、はてなアンテナは内容を独自のアルゴリズムで解析して変化の有無を検出するとのことでした。(うろおぼえ)

このweblogは更新チェッカやアンテナからのアクセスがあった場合、負荷軽減のために通常の内容を送信しません。送信しているのは最後に更新された内容の更新日時と、内容として各トピックの見出しだけが送信されています。ですから、はてなアンテナではhn要素の内容変化は無視する、という形なのかもしれません。そうであれば、更新があたかも無かったかのように見えます。詳しくははてなに問い合わせてもらった方が良いかと思います。

万が一、やる気が出て、If-Modified-Sinceに対応すれば問題無くなるのではないかと思いますが、面倒なので今のところやる気がありません。(やりたいとは思っている)

2005年1月12日

Re: バナー画像の下線を消す 初回投稿日時: 2005年01月12日01時21分35秒
最終更新日時: 2005年01月12日01時25分41秒
カテゴリ: CSS
固定リンク: id=2005011200
リンク元: 2件
SNS: (list)

久々に純粋な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が適用されて、画像の下にも下線が表示される訳です。

2005年1月14日

Bug 4156 text-align:justifyで右端の文字にスペースを追加すべきではない #3 初回投稿日時: 2005年01月14日04時53分13秒
カテゴリ: Mozilla Core
固定リンク: id=2005011400
リンク元: 0件
SNS: (list)

ようやく修正完了。これで、CJKのjustificationはIEに追いつき、追い抜いた形になる(IEはjustifiable文字の定義が仕様書とは違っている。Microsoftはまたしても先行実装による過ちを繰り返したことになる)。

2005年1月15日

Bug 4119 [MS-IME] 詳細なテキストサービスを無効にしてMS-IMEを利用していると、ポップアップウインドウが一瞬で消える 初回投稿日時: 2005年01月15日12時41分06秒
最終更新日時: 2005年01月15日12時43分29秒
カテゴリ: Mozilla Core
固定リンク: id=2005011500
リンク元: 5件
SNS: (list)

修正完了。

原因は、「詳細なテキストサービス」が無効の場合、MS-IMEがフォーカスを移すたびに不要なWM_GETMINMAXINFOメッセージをフォーカスを取得したウインドウに送信していたため。 WM_GETMINMAXINFOはウインドウのサイズが変更される際にトップレベルウインドウが受け取るもので、本来、それ以外のウインドウが受け取ることはない。 そこで、トップレベルウインドウ以外がこのメッセージを受け取った場合には無視するように修正している。

ところで、「詳細なテキストサービス」をオフにしているとMS-IMEのこのバグ(?)のため、フォーカス移動に時間がかかるようになる。顕著なのが、ブラウザのキャンバスがフォーカスを持っている時にメニューを開こうとした時だ。この時、ワンテンポ遅れてメニューは展開される。

XULのメニューの展開が遅いと文句を言う人で「詳細なテキストサービス」を無効にして、MS-IMEを利用している人は、それは文句を言う相手が違う。悪いのはMS-IMEである。

「詳細なテキストサービス」を無効にしたい人はATOK等、他のIMEを利用することをお勧めする。とりあえずATOKではこの問題が発生しないことを確認している。

近況、その他 初回投稿日時: 2005年01月15日19時02分01秒
最終更新日時: 2005年01月15日19時02分54秒
カテゴリ: 雑談
固定リンク: id=2005011501
リンク元: 0件
SNS: (list)

Turbo Linux 10 F..購入

徳島では、JustSystemのお膝元にもかかわらず、ATOK X単品で手に入らないのでバンドルされてるTurbo Linuxを買ってきた。

なぜかFedora Core 3ではWindowsマシンと通信できなかったり、DVDはマウントできるのにCDがマウントできなかった問題が解決されたものの、他にも細かい問題が山積していてなかなか長時間使える環境にはほど遠い状況。

それにしても、一社が強力なリーダーシップで設計したデスクトップに比べ、Linuxでは各開発者がバラバラに仕事をしている印象がある。 RPMというシステムがあってもインストール時にショートカットをメニューに登録してくれないとか、そういった「決めごと」が無いのはWindowsというぬるま湯につかっている私からすれば非常に不便。

MSのインテリマウス購入

長らく愛用してきたA4 TECHのマウスがLinux環境では暴走して使い物にならないのでMSのインテリマウスを買ってきた(でも、まだ正常に動作するのか未確認)。

高いだけあって(といってもバルクで安く仕入れてるけど)、手へのフィット感とかマウスの使い心地は上々。でも、フォーカスのあるウインドウでしかホイールが使えないという仕様はどうにもなじまない。サードパーティの製品に多い、カーソル位置のウインドウのスクロールを制御してくれる方が直感的だと思う。

ちなみに、Mozillaではチルトホイールで横スクロールも対応しているのでA4 TECHのマウスよりも便利。

無線LAN導入

転送速度が有線に比べて遅いのでいままで導入してなかったものの、ノートPCのLANケーブルの断線を機にノートPCだけ無線LANにすることにした。

ところが無線LANのアクセスポイントが徳島中のPCショップをまわっても売っていない。仕方ないので電器屋を周っていると一件だけ売っていたので購入。

つくづく電気街のあるところに住みたいと思わされた。

Weblogからもずはっく日記に

名前が思いつかなくてただのweblogとしていたものの、最近hackingに関する内容が多いのでこの名前に変更。

2005年1月16日

休みを取るのを忘れていた 初回投稿日時: 2005年01月16日01時43分35秒
カテゴリ: 雑談
固定リンク: id=2005011600
リンク元: 0件
SNS: (list)

そういえば正月休みが明けてから休みを取るのを忘れていた。 もっとも、正月休みも帰省していた一日を除けばbugzillaではごにょごにょとやっていたので完全に休んでいた日は少ないのだが。本家に動きがないし少し休もうかな。でもbugzillaはやってるんだろうなぁ。

落書きメモ 初回投稿日時: 2005年01月16日02時11分57秒
最終更新日時: 2005年01月16日02時13分40秒
カテゴリ: Memo Mozilla Core
固定リンク: id=2005011601
リンク元: 0件
SNS: (list)

Borland社のVCLはオブジェクトの基本的な形を定義して、継承により多態化させ、オブジェクト間の通信はできる限り少なくし、オブジェクトをシンプルな完成型としていたのに対し、Mozillaではオブジェクトが複雑に絡み合い、互いに頻繁に通信しあっている。

要するに互いに非常に対照的な設計だが、どちらが優れているのかは視点によって変わりそうだ。VCLは固く、Mozillaは柔らかいが、VCLはさらっとしていて、Mozillaはべっとりしている。

これらの違いは企業の開発プロセスと、オープンソースの開発プロセスの違いが形になったもののようで面白い。

拡張性はMozillaのような設計の方が上だけど、スパゲッティ化のしやすさも顕著。VCLはその逆のイメージがある。これを外側から見てみると、プロプラエタリなソフトとオープンソースのソフトのそれぞれの特徴としてにじみ出ているように思える。

オープンソースのソフトの進化の速さも、なんでこんな簡単そうなバグがとられないんだろう、というのもソースコードの設計の特徴から出た結果なのだろう。

2005年1月18日

Bug 4134 URLバーやFirefoxのオートコンプリートの候補ウインドウがIMEのcandidateウインドウを隠してしまう 初回投稿日時: 2005年01月18日15時21分52秒
カテゴリ: Firefox Suite
固定リンク: id=2005011800
リンク元: 0件
SNS: (list)

ウィジットを修正、というか仕様変更するととても長い道のりになってしまうので、Windows版IEの挙動と同じように、IMEで未確定文字が入力されている間はオートコンプリートのウインドウ自体を消してしまうことにした。

Bug 3128 IMEでサーチバーへ入力中に確定前のフォーカス移動でクラッシュ 初回投稿日時: 2005年01月18日15時29分00秒
カテゴリ: Firefox
固定リンク: id=2005011801
リンク元: 0件
SNS: (list)

今は、とりあえずなパッチで再現しなくなっているこの問題もようやく原因が分かった。 イベントの発生順序がまずいのだ。

Mozillaはエディタがフォーカスを失う際に、未確定文字列があると強制確定する。 つまり、フォーカスを失った後に未確定文字が確定され、入力のイベントが走る。 そのため、フォーカスを失うと同時にファイナライズしたのに、来るはずのない入力イベントがやってきて破綻していたのだ。

とりあえず、呼び出し前にフォーカスを失っていないかどうかのチェックを行うようにしたが、XULからのアクセスでもクラッシュしてしまうので、回避パッチはそのままにしてある。

もっと根本的な解決策として、フォーカス喪失寸前のイベントを作り、そこで強制確定を実行すべきだろう。 やるかどうかは別にして……

2005年1月24日

Bug 4005 日本語のデフォルトフォントはsans-serifの方が可読性が良い #2 初回投稿日時: 2005年01月24日13時11分23秒
カテゴリ: Firefox Mozilla Core Suite Thunderbird
固定リンク: id=2005012400
リンク元: 0件
SNS: (list)

Netscape6.0の頃(Mozilla 0.6の頃)から問題として挙げられていた問題だが、ついに修正完了。 言語グループごとにserifかsans-serifかを設定できるようになった。

しかし、懸案が一つ残っている。 現在の設計では、

<p lang="ja">ああああ<span lang="en">aaaaaaa</span></p>

このような場合に、span要素の内容だけがserifになるかというと、そうではない

よく考えてみて欲しい。CSSの継承という考え方でいくと、jasans-serifが継承されて、enの要素もsans-serifとなっているのである。

今、Mozillaはルート要素にsans-serifserifかを設定に基づいて指定するようになっている。つまり、この設計のままでは要素ごとにこれらを切り替えることはできない。しかし、もし、新しいフォントの一般名、例えば-moz-defaultというものでも作り、ルート要素にこれを指定し、継承させていけば切り替えも可能ではある。

しかし、本音は「面倒だなぁ」ということだ。

2005年1月27日

IME無効化メモ 初回投稿日時: 2005年01月27日03時01分41秒
カテゴリ: Firefox Memo Mozilla Core Suite Thunderbird
固定リンク: id=2005012702
リンク元: 0件
SNS: (list)

エディタ以外でIMEを無効化するためには……

  • エディタがフォーカス取得時にウインドウのIMEを有効化する(nsEditor)
  • エディタがフォーカス喪失時にウインドウのIMEを無効化する(nsEditor)
  • ウインドウのクリエイト時にIMEを無効化する(nsWindowで?)
  • SuiteではFAYT開始時にIMEを有効化する
    • つまりIMEでFAYTを開始することはできなくなる(regressionだが仕様)
    • nsTypeAheadFind.cpp内でnsIWidgetを取得可能か??

IME有効化/無効化のAPIの実装問題として、使用する隠しAPI(?)がMinGWのライブラリでは宣言されていない。どうしたものか。

IME無効化メモ2 初回投稿日時: 2005年01月27日20時07分42秒
カテゴリ: Firefox Memo Mozilla Core Suite Thunderbird
固定リンク: id=2005012703
リンク元: 2件
SNS: (list)

SuiteでFAYT開始時にIMEを有効化するのはダメっぽい。

エディタでIMEをONにしてからFAYTをショートカットで開始した場合

特に問題なし

エディタでIMEをONにしてからFAYTを文字入力によって開始した場合

一文字目はタイプしたキーだが、二文字目はIMEの未確定文字列になる。これは不便

IMEを有効化すると共にIMEをオフにするという手もあるが、Windows以外では将来的にもIMEを無効化できるようになったとしてもON/OFFは制御できないっぽいのでボツ。

結論としてはFAYTをオフにしている場合、もしくは新設する設定項目(例えば、ime.disabled.inNonEditor)が有効な場合にはエディタ以外でIMEをオフにするべきか。

新規設定項目はSuiteではFAYTでIMEを利用できなくする代わりに他のバグを抑制するためのもの。 元々FAYTでIMEが使えないFirefoxやFAYTの無いThunderbirdではこの設定を有効にしておくことで、単なるバグ修正にできる。

2005年1月30日

過去ログ 初回投稿日時: 2005年01月30日12時43分42秒
カテゴリ: WebStudio
固定リンク: id=2005013000
リンク元: 0件
SNS: (list)

ところで、中野さんの Weblog、2004年8月~12月の過去ログが見当たらないようですが、、、

link要素でのみナビゲーションを貼ってるのでデフォルトのFirefoxでは見えないだけです。 改善しようと思いつつ、面倒なので……そのうち対応します。

捨てることを前提としたハンドルネーム 初回投稿日時: 2005年01月30日13時08分52秒
最終更新日時: 2005年01月31日13時16分48秒
カテゴリ: 雑談
固定リンク: id=2005013001
リンク元: 0件
SNS: (list)

levelさんのところを見ていて改めて思いましたが、(汚く、荒っぽい言葉で)人を批判するヤツに限って捨てることを前提としたハンドルネームだよなぁと。 最近、特にこういう人間が多いように思います。 こういう匿名なら強気の人間が出現しやすいというのは、2ちゃんねるの悪しき風習なのかな。

固定されたハンドルネームで発言する人というのはそれなりに自分の発言に責任を持っているように思えます。例えば、自分のblog上で発言するというのは、自分がそのハンドルネームで築き上げてきたもの、例えばそのハンドルネームの人の発言に対する信頼度や、そのサイトそのものの存在等を賭けて発言してるわけですが、匿名なら何も捨てるものが無い状態で発言しているわけで、このへんに意識の違いというものが出てくると思います。

そもそも、そういう人は他人を批判する場合であっても、あんな人としてどうかと思うような言葉遣いではなく、それなりに節度を持って発言する訳ですが。

まあ、内容に関わらず、この匿名、捨てハンドルがとても嫌いなので、このもずはっく日記にはコメントをつける機能を追加する気がなかったりします。だって、最近、そういう人の方が多いですから。(メールですらこんなのがたまに来たりするのには閉口。何考えてんねん、と言いたくなる。)

あ、それから、この日記はバグに関するリポートが大半なので、意見があればbugzillaに直接書き込んでもらって、情報の分散を避けたい、というのもありますが、まあ、先の理由の方が大きいです。

2005年1月31日

Bug 2909 [CSS3]背景が暗いページでWEBページ中の文字列を選択すると見にくい(::selection 無指定時への要望) #4 初回投稿日時: 2005年01月31日03時42分57秒
最終更新日時: 2005年01月31日04時30分03秒
カテゴリ: Mozilla Core
固定リンク: id=2005013100
リンク元: 0件
SNS: (list)

Justin Woodから1.8bへのゴーサインが出たものの、改めてテストしているとIEとの差異が少し気になる。 とりあえずさらに論理的で適当なロジックが思いつかないので、そのまま投げてみようかと思案中。

このパッチでは背景色が不明なので前景色から疑似背景色を仮定して処理するのだが、疑似背景色はHSLに一度変換してからSとLの数値だけをいじる方が現実的な解になるのだろうか。 現在のパッチでは単純にRGB空間の反対側にある色を疑似背景色としている。 どちらも結果に差が出にくいとは思うが、あらゆる前景色、背景色、選択文字列前景色、選択文字列背景色の組み合わせをテストすることはできないので理責めだけでロジックを決定しなくてはいけないところが難しい。

Bug 2909 [CSS3]背景が暗いページでWEBページ中の文字列を選択すると見にくい(::selection 無指定時への要望) #5 初回投稿日時: 2005年01月31日13時51分07秒
最終更新日時: 2005年01月31日14時12分27秒
カテゴリ: Mozilla Core
固定リンク: id=2005013101
リンク元: 0件
SNS: (list)

考えれば考えるほど難しい。ひとつ、幻想があるとすれば、IEの処理が完成型である、ということだろう。 IEでも問題のあるページはある。例えば、前景色が黄緑の場合、背景が白だとコントラスト不足から目がチカチカするので、背景色は暗くする。黒バックに黄緑の文字、というとイメージが湧くのではないかと思う。この場合、Winのデフォルトの選択色(背景が紺で、前景が白)の場合に選択色をそのまま使ってしまうため、見にくくなる。

WinIEはその挙動から仕様を推測すると、単純にRGB色空間でのみ処理している様だ。つまり、緑に弱い。有名な話だが、人間は緑に対して鈍感なのでRGB色空間での処理には無理がある。もし、それでもやるなら重み付けが必要だが、IEではそれもやっていないようだ。

この問題は、W3Cのドキュメントにあるように、YIQ色空間のYを使うことで解決できる。 Yの算出方法である、

((Red value × 299) + (Green value × 587) + (Blue value × 114)) / 1000

この計算式からもそれは明かである。