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

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

もずはっく日記(2008年8月)

2008年8月11日

Bug 6149 PlacesのTagging UIでサイトをブックマーク登録する際にTagging UIが上になって変換候補が見えない(文字列変換時) #2 初回投稿日時: 2008年08月11日17時51分26秒
最終更新日時: 2008年08月11日17時51分51秒
カテゴリ: Firefox バグ修正
固定リンク: id=2008081100
SNS: (list)

ひとまずtrunkでの修正は終わっています。

Fx3.0に間に合わなかったため、XULの仕様変更は極力避けたかったので、widgetレベルで修正し、最前面表示されたpanel要素の上でもIMEが正常に動作するようにしたかったのですが、現在のGeckoの設計ではWindows版での解決策が結局見つけられませんでした

仕方ないのでXUL側のコードを見ていたら、後からnoautohide属性を修正してもウインドウレベルが変更されないというバグを見つけました。

そこで、抜本的な解決策にはならないのですが、このバグを利用してブックマークダイアログのみ最前面で表示するのを中止させるパッチを投入して修正しました(3.0.xには現在承認申請中)。

Fx3.1ではXULの仕様変更も含めてもう少しきちんと対応したいと考えています。

Bug-org 449012 Remove legacy Reconversion/QueryCaretRect Events 初回投稿日時: 2008年08月11日18時01分58秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008081101
SNS: (list)

コードのクリーンナップバグです。

MacのCocoa化に伴い、より高度なコンテンツアクセスがwidgetから必要になったので、今年はじめに大規模な修正を行いました

そして、この新しい仕組みを利用することでかなり昔から実装されているWindows版の再変換をシンプルにできますし、WM_IME_REQUESTIMR_QUERYCHARPOSITIONも完全な実装が可能になる(以前は、キャレット位置以外のサポートは不完全)ということで一気に修正しています。

なお、このバグのパッチでも一目瞭然ですが、SeamonkeyのFAYTのようなエディタ以外でIMEを利用しようとする実装は今後サポートされません。

2008年8月17日

五山送り火 初回投稿日時: 2008年08月17日02時47分50秒
最終更新日時: 2008年08月17日07時13分19秒
カテゴリ: 雑談
固定リンク: id=2008081700
SNS: (list)

なんでか初めて行ってきました。関西に住んでる期間からすると結構な回数、行くチャンスはあったはずなんですが……

五山送り火(大文字)

いわゆる右の大文字を府道101号線で割と近場から撮ってるのではらいの最後の部分が見えていません。

鴨川なんかは人出が多いようだったので、銀閣寺近くに車を停めて歩いて西へ歩き、電車の駅からは少し遠めのところで1時間ほど前から場所とりして見てきました。京都は18時ぐらいから雨の予報だったのですがイベントの時間帯を含めて京都に着いてからは全く降らず助かりました。

Bug-org 449955 Remove #ifdef of nsCaret.cpp for IME 初回投稿日時: 2008年08月17日16時31分32秒
最終更新日時: 2008年08月17日16時31分48秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2008081701
SNS: (list)

nsCaret.cpp内にあった#ifdefで区切ったXPなコード内でのプラットフォーム固有のコードを削除するというバグです。修正終わってます。

これでXPなIME関連のコードからは完全にこのような汚らしいコードは消えたはずです。

2008年8月19日

Vista SP1ではまった 初回投稿日時: 2008年08月19日01時44分08秒
最終更新日時: 2008年08月21日04時47分01秒
カテゴリ: 雑談
固定リンク: id=2008081900
SNS: (list)

先月組み上げたPCが見事に0x0000C1F5エラーではまりました。リカバリも動かない嫌な罠ですね……

2008年8月20日

Bug-org 263683 Find Bar "Highlight All" should use selection, not manipulate DOM 初回投稿日時: 2008年08月20日20時42分36秒
最終更新日時: 2008年08月21日04時52分38秒
カテゴリ: Firefox バグ修正
固定リンク: id=2008082000
SNS: (list)

Firefoxの検索ツールバーで"Highlight All"を使ったときに黄色い背景色で文字が選択されますが、これはDOMツリーをいじってspan要素を挿入しまくってました。これをDOMのselectionを使うようにしようというバグです。いつの間にやら修正されていたのに気付きました。

span要素によるハックは色々と無理があり、またパフォーマンス上も問題が大きかったので、非常に重要な修正です。この修正により、Bug-org 255941のように修正困難だった問題(背景色が黄色に近いとハイライトされた位置が分かりにくい)も解決されています。

2008年8月22日

10万のゴミ 初回投稿日時: 2008年08月22日06時47分11秒
カテゴリ: 雑談
固定リンク: id=2008082200
SNS: (list)

なんかごみ箱開くのに時間がかかると思ったら、えらいことになってました。

結構、Shift+Delでごみ箱経由しないように気をつけてるつもりなのですが。

ごみ箱のスクリーンショット(102275 個の項目)

2008年8月26日

マーケティングとプロダクトの完成度のバランス 初回投稿日時: 2008年08月26日02時50分48秒
最終更新日時: 2008年08月26日03時15分44秒
カテゴリ: 雑談
固定リンク: id=2008082600
SNS: (list)

某所で知ったblog記事、『なぜ「iPhoneキラー」がことごとく失敗するのか』読んでみました。ですが、内容の主旨というか筆者の方の言わんとしてることには納得できるんですが、iPhoneの例がよく分かりませんでした。

Appleってどう贔屓目で見ても消費者のことを第一に考えた商売をしているよう思えませんし(どちらかというと、MSや日本の家電メーカーと同じ囲い込み戦略ですよね)、消費者が満足したのかどうか、その結果はもっと後(例えば今使ってるユーザが次世代機発売時にどの程度乗り換えるのか等)で分かることであって、今の勢いや売り上げ台数等をもって「消費者指向」のもの作りだから成功してるんだ、という結論は違うと思います(その後ろのマーケティングには同意ですが)。商品ってのは買ってから自分の思い込みが裏切られることなんて日常茶飯事ですし。

そんな訳で、今の段階で成功した(本当に成功と言えるほど売れてるのかどうかは知りませんが)理由というのは単純にマーケティングのおかげだと思う訳です。

まあ、他社のことは、これぐらいにして本題へ行きましょう。

私はGeckoの開発で常々感じていることなのですが、マーケティングが上手すぎるというのは、それはそれで恐いこと(リスキーなこと)だと思います。プロダクトの成熟度に対して不相応にシェア拡大が起こってしまうと、開発に対して理解の薄い層の信頼を一気に失ってしまう怖さがあります。一度、製品に対する信頼を失ってしまうと、そのユーザが再び新バージョンを使えるか否かテストしてくれる可能性が非常に下がるんではないかと考えているからです(もし、そうではないのであれば、ただの私の杞憂なのでありがたいことですが)。

例えばGeckoの場合、IME関連の基本的なバグや、URLの改行問題等、一見、修正できて当たり前な大物バグを修正するのにバージョンが1.9まで来てしまいました。もちろん、修正に時間がかかったのにはそれなりに、色々な事情があるからなのですが、ユーザにとってはそんなこと関係ありませんから、『こういう目立つものも修正できないのか』と考えられてしまっても仕方がないと思います。

あまりライトユーザに普及しない間に大きな問題を排除していける、というのは開発者としてはありがたいことだと私は感じていますが、iPhoneのようにマーケティング担当がいきなりライトユーザーにアピールしてしまう製品は大変だなぁと思います。

TSF対応間近 初回投稿日時: 2008年08月26日03時49分56秒
最終更新日時: 2008年08月26日03時55分02秒
カテゴリ: Mozilla Core
固定リンク: id=2008082601
SNS: (list)

私が担当なわけではないため、まだ確定的かどうかは不透明ですが、Gecko1.9.1でTSF対応が間に合うかもしれません。

この作業が終われば、今後のGeckoはIMMとTSFの両方をサポートすることになります(レガシーなIMEをサポートするためにIMMサポートは削除できません)。TSFは非常に柔軟なシステムで、IMMとは比較にならないほど様々な機能を持っています。

ですが、その高機能さが問題でもあります。それはFlash等のプラグインでのIMEの取り扱いをどうやって実現すれば良いんだ、という話です。通常のwindowモードであれば、プラグイン自身がウインドウを持っているため、IMMでもTSFでもどちらでもプラグイン自身が選択可能です。どうぞ、各プラグインで頑張ってください、という話になりますが、windowlessモードだとGeckoが仲介してイベントを伝達していますし、TSFはメッセージによるイベントが発生する訳ではないという問題があります。windowlessモードでのIMEサポートはもはやWontfixが妥当なのではないかな、とすら思えてしまうのですが、どうなんでしょうか。

IMMに対応することができれば、それを利用して、

  • TSFからIMMをGecko内部でエミュレーションする
  • windowlessなcontentがフォーカスを持った場合にTSFサポートを一時的に取りやめる

といった方法が考えられるでしょうか。後者が可能なのかどうかも私自身はよく知りませんが、できるならこちらが現実的なように思えます。アクセシビリティ的には前者の方が好ましいように思えますが、ちょっと現実的では無いように思えます。もっとも、まずはIMMからの入力に対応しろ、という話ですね、はい。

現在のプラグインのような前時代的な仕様のものは、とっとと無くなって欲しいです。いや、ほんと。

2008年8月29日

Bug 6149 PlacesのTagging UIでサイトをブックマーク登録する際にTagging UIが上になって変換候補が見えない(文字列変換時) #3 初回投稿日時: 2008年08月29日15時17分05秒
カテゴリ: Firefox バグ再開
固定リンク: id=2008082900
SNS: (list)

Bug 6305が発見されたため、Fx3.0.2からはバックアウトされました。

Bug 6305を先にFx3.0.xでも修正し、それから再度バックアウトされたパッチを入れることになるので、Branchでの修正は早くてもFx3.0.3になります。

Bug 6305 [Win] ブックマークダイアログに-moz-border-radiusを指定していると、ダイアログを閉じる時にハングアップする 初回投稿日時: 2008年08月29日15時24分31秒
カテゴリ: Mozilla Core バグ原因判明 バグ報告
固定リンク: id=2008082901
SNS: (list)

ブックマークダイアログがBug 6149の修正で最前面表示ではなくなりましたが、WindowsではブックマークダイアログをWS_EX_LAYEREDにしようとした時に、ダイアログの親のウインドウにこのスタイルを設定してしまい、閉じる時の挙動がおかしくなってしまったようです。あさんが原因を発見してくれたので非常に早くパッチが作れました。毎度、ありがとうございます。

これはBug 6149の直接的なregressionではないので、おそらくツールバーのカスタマイズダイアログ等に同じ事をすると再現するんではないかと思います。

2008年8月30日

Bug 6149 PlacesのTagging UIでサイトをブックマーク登録する際にTagging UIが上になって変換候補が見えない(文字列変換時) #4 初回投稿日時: 2008年08月30日07時47分23秒
カテゴリ: Firefox
固定リンク: id=2008083000
SNS: (list)

なぜFx3.0.2からこの修正をバックアウトしたのか、関係者からも質問が来たのでここに明記しておきます。

まず、Fx3.0.xというバージョンは全てMozillaの正式なリリースです。Fx3.0.1以降は、基本的にセキュリティ修正のためのものであり、機能追加等は行われません。なぜなら、これらのバージョン間では互換性が最も重要視されるためです。しかし、例外的に一部のユーザが製品を利用する際に困る、重大な問題は副作用がほとんどないことを前提に修正が許可されます。

このような前提があるため、基本的にFx3.0.xでの修正では、regressionは許されません。regressionがあっても、まず発生させることがないようなレアなものだったり、発生しても実害が無いもので、なおかつ修正による効果が大きい場合は無視されるかもしれませんが、このへんはリリースドライバの判断が基準となるので、明確な線引きはできません。また、セキュリティ上、仕方のない仕様変更もregressionではありますが、こちらは基本的にセキュリティの改善が優先されることになるでしょう。

今回のケースでは、特定のテーマを利用していた場合はブックマークダイアログという、メジャーな機能の利用により、ハングアップ、またはクラッシュという最悪の状態が発生します。つまり、発生する可能性が非常に高く、また、実害が大きすぎます。このような状況下ではアクセシビリティ上の大問題であるこのバグの修正であっても、許されるレベルのものでは無いと私は考えます。

次のように考えてみてください。Fx3.0.xはFx用のテーマのプラットフォームなのです。この、クライアントが動作しなくなると分かっている修正をプラットフォームに入れることがいかに間違った判断であるかは明白です。

また、セキュリティ問題の修正が主眼であるFx3.0.xが特定のバグを修正するために、このような問題を一時的にでも持つことはナンセンスです。これらのユーザがセキュリティ的に問題のあるバージョンを使い続けることを促してしまうからです。セキュリティフィックスバージョンはユーザに互換性を気にせずに安心してアップグレードしてもらえることが大前提となります。

Fxの普及を考えた場合、安心してセキュリティアップデートができないプロダクトであってはいけないのです。

ちなみに、投入していたパッチが非常にアレなアプローチだったのは、XULの仕様変更をしなくて済むという大きな理由があったためです。もし、現在レビュー中のXULの仕様変更を行うパッチを投入した場合、一部の拡張機能がうまく動作しなくなる危険性があります(しかもそれなりに高いと思います)。そのようなリスクは出来る限り回避しなくてはいけないのがBranchでの修正の難しさです。