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

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

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

2011年1月8日

Bug-org 545647 Bookmarks Toolbar wrong sort order and missing elements 初回投稿日時: 2011年01月08日23時13分25秒
最終更新日時: 2011年01月20日16時18分43秒
カテゴリ: バグ検証中
固定リンク: id=2011010800
リンク元: 2件
SNS: (list)

Syncでbookmark toolbar内のブックマークの順序が元と違う結果になるというバグです。

私のアカウントだと新しいprofile作って受信するだけでオリジナルとは異なる順序で構築されますが、そんなに再現しないものでしょうか?

確かに、-p <profile name> -no-remoteで真っ新なprofile同士で、新しいアカウントを使って再現させようとしてもうまくいきませんでした。

想像ではクライアントが全て双方向のモード(推奨されているモード)で、お互いで更新されたこと同士のマージに失敗しているんではないかと思うのですが……

重大なバグがあると思いますので引き続き調査してみますが、他の作業もあってあまり時間が割けないので是非ともテストにご協力お願いします。

Bug-org 618403は修正されましたが、サーバ側で壊れたままと思われるデータを新しいプロファイルで同期してみるとやはり壊れたままでした。

この問題で一番イライラさせられるのが、自動的にバックアップされているブックマークから一日前のもの等にリストアしても、そのデータでサーバ側が上書きされず、個別にアイテムを編集しない限り、上書きされないことです。これに関する改善のバグはBug-org 626796に登録されています。

2011年1月24日

Bug-org 610821 IME composition doesn't start by typing a character for searching a tab on Panorama 初回投稿日時: 2011年01月24日15時26分56秒
最終更新日時: 2011年01月24日15時44分34秒
カテゴリ: Firefox Mozilla Core バグ修正
固定リンク: id=2011012400
リンク元: 0件
SNS: (list)

Panoramaで文字を入力すると自動的にタブの検索フォームが出現し、エディタに一文字が入力されますが、IMEがオンの状態でもフォーカスがエディタ外だったためにIMEが無効になっている時のキーイベントがそのままリダイレクトされるので、次の文字の入力から初めてIMEを経由することになり、意図通りに入力できない、というバグです。昔からFAYTが抱えているのと同じ問題です。

FAYTの時にも悩みましたが、Windowsの入力イベントの仕様上(Geckoの実装上?)、どうしようもないと思い、今回もUIのデザイン自体の見直しを提案していました。しかし、昨年知ったSendInput() APIが利用可能かもしれないと気づき、実験してみたところうまく動くことが分かりました。

WindowsではメッセージループにWM_KEYDOWNメッセージのみが送信されてきます。これをTranslateMessage() APIに渡すと、WM_CHARがメッセージキューに挿入されますが、このときにIME (IMM)にも処理が渡っているようです。Geckoでは、GetMessage()の後、直接TranslateMessage()を呼んでいて、WM_KEYDOWNをウインドウが受け取る時には既にIMEで処理が始まっていることになります。つまり、現在の設計ではDOMのkeydownイベントが発生した時点で、Windowsでは既にIMEが処理を開始している、もしくは、エディタ以外のIMEが無効になっている状態ではIMEを通さずにWM_CHARが生成されているという状態になっています。

TranslateMessage()をDOMのkeydownイベントの処理結果を見てから呼べという根本的な意見もあるかとは思いますが、開発サイクルのタイミング上、不可能ですし、色々なキーボードレイアウトでテストするにも時間がかかります。そこで、前述のSendInput() APIによってハックすることにしました。

WM_KEYDOWNの処理時に、DOMのkeydownイベントのハンドラがエディタにフォーカスを移動させてIMEが有効になった場合、WM_KEYDOWNのハンドラがSendInput()で再度、ネイティブの入力イベントを低レベルで発生させるようにしました。そして、WM_KEYDOWNのハンドラは次に来たキー入力が期待通りのものだった場合、DOMのkeydownイベントは再生成しません。そして、エディタ上でkeypressイベントか、compositionstartイベントが発生するようになっています。

そして、Panorama側ではkeydownイベントで検索を開始し、フォーカスを移動させるだけにしました。つまり、今までのkeypressイベントのリダイレクト処理は行わなくなっています。

この変更が具体的にWebアプリからみて、どのような影響があるのかはイベントの発生順序が見えるデモで確認してみてください。

当然のことながらIMEがオフの状態では以前と変わっていません。IMEがオンの場合、エディタ以外でキーを押すと、エディタには今までは来ていたkeypressイベントが来なくなっているのが分かるかと思います。その代わりにcompositionstartイベントやtextイベントが発生するようになっています。

ちなみに、Macではもともとこの修正後の動作でした。今回の修正ではWindowsとLinuxの動作をMacにあわせた形になります。もし、この変更でなんらかの悪い影響を受けるWebアプリケーションがあったとすれば、それはMacユーザには元々そのユーザ体験を提供してしまっていたことになります。

また、プラットフォーム関わらず、keydownイベントのpreventDefault()を呼び出してもIMEの動作を妨げることはできません。DOMのイベントモデル的には良くありませんが、そもそもこれが好ましいことかどうかは分かりません。そのようなロジックに依存したWebアプリを書くと、IMにまっさきにネイティブのKeyPressイベントを食われてしまうLinux (GTK2)上では動かなくなってしまうからです。

Bug-org 593904 Add special chars check for beforeSearchKeyHandler() in the search.js 初回投稿日時: 2011年01月24日15時44分15秒
最終更新日時: 2011年01月24日15時48分55秒
カテゴリ: Firefox バグ修正
固定リンク: id=2011012401
リンク元: 0件
SNS: (list)

Panoramaのタブの検索は、キー入力とともにフォームが出現して検索が開始されますが、アルファベット以外のキーでは開始できない、というバグです。

Bug-org 610821の修正で同時に修正しています。これによって、ASCII文字を入力しないキーボードレイアウトでも問題なくなっていますし、IMEでかな打ちを利用していても問題なくなっています。

Bug-org 615879 IME composition doesn't start by typing a character for starting FAYT in auto-start mode 初回投稿日時: 2011年01月24日15時58分17秒
カテゴリ: Firefox バグ報告
固定リンク: id=2011012402
リンク元: 0件
SNS: (list)

これはFAYT開始時にIMEがオンでもIMEを経由した入力にならない、というバグです。

Bug-org 610821の修正で修正可能にはなりましたが、Firefox 4では修正しません。既存の/'での検索対象の切り替えをCtrlキーやCmdキーと併用したショートカット形式にしないと、うまく動かないためです。ですが、UIのこのような変更は議論を呼んでしまう可能性があるので次のバージョンに持ち越します。

パッチは既にありますし、内容的に拡張で対応できると思うので、どうしてもという方はその方向でどうぞ(余計な差分が混じっていますが、browser/base/content/tabbrowser.xmlと、toolkit/content/widgets/findbar.xmlの差分だけ適用すれば修正できます)。

Bug-org 574907 [DW] Don't use subpixel positioning for bitmap glyphs #2 初回投稿日時: 2011年01月24日16時24分47秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2011012403
リンク元: 2件
SNS: (list)

DirectWriteだと、MS Pゴシック等で文字がくっつきすぎるというバグです。DirectWriteは最近のバージョンでは東アジアのフォントに対してはビットマップグリフを一定のサイズでは利用するようになっていますが、このビットマップを利用する時にも各文字の幅をアウトラインから計算して返してくるため、フォントサイズ(小数も利用可能)や行頭の位置との関係によっては判読不可能なぐらいにくっついてしまうことがあります。

色々と調べた感じではDirectWriteはどうも内部にビットマップグリフを利用した方が良いフォントのブラックリストを持っているようです。また、このリストでビットマップグリフを利用すべきサイズ指定までやっているのではないかという疑惑すらあります。このへんが全く明文化されていないのでビットマップグリフを持つサイズでは小数は丸めるようにし、GDI互換の幅計算で文字を配置するように修正してもらいました。この結果、以下のようにレンダリング結果が改善しています。

修正前のtrunkビルドのスクリーンショット

上記のスクリーンショットで赤く囲んだところに注目してください。文脈がなければ判読不可能な組み合わせも出てくることが分かります。

修正後のtrunkビルドのスクリーンショット

修正後はこのようになっています。まだ一部くっついているところがありますが……

Firefox 3.6のスクリーンショット

このFirefox 3.6のスクリーンショットを見れば分かるように、もともとGDIのレンダリングでもくっついてることはありますが、これはフォントの問題としか言いようがありません。

FWD: won't fix: Intel Atomの上でのJavaScriptパフォーマンス 初回投稿日時: 2011年01月24日17時02分20秒
カテゴリ: Google Chrome Javascript Mozilla Core
固定リンク: id=2011012404
リンク元: 0件
SNS: (list)

もう一ヶ月ぐらいまえの加藤さんのポストですが、かなり興味深い内容です。見たことない人は是非一度チェックを。

ネットブック等で採用されているCPU、Atomでベンチマークをとると、Google ChromeよりもFirefoxの方が高速になってしまう、というものです。

特定のプラットフォームに対して最適化すると陥りがちな結果なのかもしれませんが、本当に速度を求めてブラウザを選択する場合、自分の環境できちんと速度を計測してみることが大切だと言えるかもしれません。

ただ、速度を求めている人の大半というのは実速度よりも思い込みも含めた体感速度を重視している場合が多いように思えるので、そういう基準だとベンチマーク結果にかかわらず、Google ChromeやOperaというのはFirefoxよりは良い選択肢ではあるかもしれません。例えば、システムのマウスホイールのスクロール速度を増やしてみて、それで高速化した、と感じるのであればそれはこのケースに当てはまります。

Bug-org 628205 Mac addon developers cannot check their UI in Firefox button (Implement Firefox button on Mac) 初回投稿日時: 2011年01月24日17時15分31秒
カテゴリ: Firefox バグ報告
固定リンク: id=2011012405
リンク元: 1件
SNS: (list)

普段、nightlyでも動く拡張をいくつか利用していますが、その中には(ショートカットキーを除けば)メニューからしかアクセスできない拡張があります。例えばDOM Inspectorが有名です。こういったアドオンは未だにFirefoxボタンのメニューからアクセスできません。これは何故かと、ふと疑問に思ったのですが、その時にこの問題が思いつきました。つまり、開発者がMacを常用している場合、Firefoxボタンのこと自体を知らないかもしくは忘れている、最悪なのがデバッグできない、といった理由で対応が遅れているのではないかということです。

#extdevで確認をとってみても、AMOのレビューではこの問題に関してはノータッチのようで、メニューバー側のメニュー項目しかいじってなくてもAMO的には問題ないようです。ドキュメントで呼びかけてはいるようですが、徹底できるとは正直思えません。

また、UIの変更は他の拡張とのバッティング時にも対策等が必要でしょうから、デバッグ用にMacもFirefoxボタンを付けるべきなのではないか、というのがこのバグです(ちなみに、本体のメニュー構造はMXRで確認できます)。

ひとまず、今のところは、自分の使っている拡張がFirefoxボタンに対応していない場合は、各作者に連絡をとるしかないようです。