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

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

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

2009年8月2日

Bug 6609 Webコンテンツはchromeのフォーカスを奪えるべきではない 初回投稿日時: 2009年08月02日12時54分46秒
最終更新日時: 2009年08月02日23時21分40秒
カテゴリ: Firefox Javascript Mozilla Core バグ修正 バグ再開
固定リンク: id=2009080200
リンク元: 0件
SNS: (list)

Webコンテンツは、element.focus();等で検索バーやロケーションバー等のchromeの要素がフォーカスを持つ場合にフォーカスを奪えるべきではない、というバグです。

ナローバンドな場合等ページの読み込みが遅い場合で、onloadイベントでフォーカスを移動させようとするページの読み込んでいる時に、その空き時間を利用してchromeで何らかの作業を開始しても、ページの読み込みが完了したと同時にフォーカスが勝手に奪われて作業が中断される、という結構鬱陶しいバグでした。

通常のページ読み込み時は、読み込み開始と共にフォーカスが自動的にWebページにセットされるので、onloadイベントでフォーカスを移動させることができなくなった、という修正ではありません。また、実際にフォーカスが移動しなかった場合でも、document.activeElementの更新は従来通り行われます。あくまで、実際のフォーカスの移動が今回の修正で制限されただけです。

修正パッチの原理は単純で、フォーカスを奪おうとしているコードが、現在フォーカスを持っているノードへのアクセス権を持っていなかったら実際のフォーカス移動は発生させない、というだけのものです。こんな単純な話がこんなにも長期間放置されていたことが驚きではありますが……

ひとまずバックアウトされています。バックアウト理由自体は濡れ衣だと思われますが、そう勘違いしてもおかしくない状況をこのパッチが作り上げているのではないかと思います。詳しくはまた後日。

2009年8月8日

Bug-org 508202 Cannot build on Vista x64 with VC9 + MozillaBuild1.4 after bug 505289 初回投稿日時: 2009年08月08日13時26分12秒
最終更新日時: 2009年08月08日13時27分17秒
カテゴリ: Firefox Mozilla Core バグ修正
固定リンク: id=2009080800
リンク元: 0件
SNS: (list)

えむけいさんが修正してくれたBug-org 505289のマニフェストだと、うちの環境ではnsinstall.exeのside-by-sideがおかしくなってビルドできない、というバグです。

以前にもFxのバイナリで同じ目にあったことがあるので、その時と同じワークアラウンドを入れて修正していますが、これ、mt.exeのバグなんでしょうか、やっぱり。

Bug 1908 Windowsのクリップボード関連メッセージのサポート 初回投稿日時: 2009年08月08日13時31分36秒
最終更新日時: 2009年08月08日13時36分44秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009080801
リンク元: 0件
SNS: (list)

Windowsのクリップボード関連メッセージの実装が終わりました。この修正で、WM_CLEARWM_COPYWM_CUTWM_PASTEEM_UNDOEM_REDOEM_CANUNDOEM_CANREDOEM_CANPASTEに対応しています(ただし、EM_CANPASTEwParam0か、CF_TEXTもしくはCF_UNICODETEXTの場合のみ)。

ATOKの単語の辞書登録のダイアログが出るときには、何故かWM_COPYが利用されていたので、この修正でエディタ内であればATOKの単語登録は他のアプリケーションと同様に機能するようになっています。

Bug 4520 [Win] VJE-Delta4.0で再変換できない 初回投稿日時: 2009年08月08日13時33分57秒
最終更新日時: 2009年08月08日13時35分13秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009080802
リンク元: 0件
SNS: (list)

VJE-Delta 4.0では再変換が機能しない、というバグです。一応、Bug 1908の修正WM_COPYがサポートされたことで機能するようになっています。ただ、ひらがな以外を選択して再変換しようとしても他の候補が出てこないので使い物にならない感じですが……

2009年8月9日

2009年8月18日

Bug-org 439815 Keyboard shortcuts with alternate keyboard layouts (including colemak) are missmapped; they are mapped for qwerty. 初回投稿日時: 2009年08月18日16時41分15秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009081801
リンク元: 0件
SNS: (list)

Mac OS X 10.4向けのコードが、古い手法使いすぎてて、一部のキーボードレイアウトではうまく機能していなかったというバグです。久々にkey hellの修正です。

なんであんなコード使ってたか、というとググって出てくるMacのキーボード周りの処理ってクラシックな頃のものしか引っかからなかったためなんですが……まあ、どのみち間もなくこのパッチもtrunkでは削除されます。さらば10.4。

2009年8月21日

Bug-org 486735 Verdana.ttf gets a very thick underline with spelling errors 初回投稿日時: 2009年08月21日02時09分24秒
最終更新日時: 2009年08月21日02時13分30秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009082100
リンク元: 0件
SNS: (list)

サマリから分かりにくいのですが、スペルチェッカーの下線の太さはフォントや、その書体に依存すべきではないというバグです。

スペルチェッカーの下線のスタイルを各OSで一般的なものに変更しましたが、その時にCSSのtext-decorationと同様にその太さがフォントにあわせて可変な実装を行いました。ところが、波線では太くなってしまうと非常に見づらくなる、という問題が発生してしまいました。

この修正で、デフォルトフォントサイズの1/20のサイズで下線を常にレンダリングするようになっています(Macはその倍)。ただし、現在問題のある環境等は少ないと思いますが、デフォルトフォントサイズが大きく、実際のレンダリング結果のサイズがそれを下回る場合には、実際のフォントサイズの1/20を採用するようになっています。

1.9.2 branchへの許可を取ることを予定していますが、これでGecko 1.9.2以降の新しいスペルチェッカーの下線の問題はひとまず収束したはずです。

ちなみに、IMEの下線の太さは変わらずフォントに依存します。IMEの下線の色は大抵、文字色が使われている、漢字の口のようにフォントによっては下線が隠れがちな文字が多々存在している、他のアプリでもIMEの下線はフォントサイズに応じて太さを変更している、というあたりがその理由です。

2009年8月24日

Bug-org 481950 Entering caps or special characters using hardware keyboard in password fields is broken 初回投稿日時: 2009年08月24日13時09分54秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009082400
リンク元: 0件
SNS: (list)

私もよく分かってないんですが、MaemoなN810ではIMEをパスワードフィールドでも使えるようにしておかないと、ハードウェアのキーによる、Shiftキーを押してからアルファベットキーを押しても大文字を入力できない、という問題があったようです。

で、パッチ投げられてレビューを頼まれてたので読んでると、私や片貝さんのレビューを通らずに既にtrunkに入っていたMaemo用のコードが思いっきり間違ってるという現状で、何が何やら…… その辺は私一人でコード書いていつもrocにレビューを頼んでいたので、ここのパスを通らない限り破綻しちゃうというのは仕方ないんですが。

GTK2向けのIMEのコードもそれなりに行数あるので、Windows版のように、IMEのコードだけ専用のクラスに分離してレビューをこちらにリクエストするようにした方が良いんでしょうか。

2009年8月25日

Bug-org 36351 Support the jpeg2000 (jp2k) format 初回投稿日時: 2009年08月25日23時21分10秒
最終更新日時: 2009年08月25日23時23分34秒
カテゴリ: Mozilla Core バグ却下
固定リンク: id=2009082500
リンク元: 0件
SNS: (list)

サマリ通り、JPEG2000のサポートに関する要望のバグでしたが、Webでは使われていないので重要じゃないという理由で却下されました。

以降もいくつか見直しを求める書き込みが続いていますが、parity-safariとなっているので、Safariがサポートしていたにもかかわらず、Webでは利用されていないんだから要らないだろう、という判断はなかなか覆らなさそうに見えます。

モジュールってのは作って終わりではなくて、メンテし続けるコストがかけられるかどうか、という重大な問題があります。だから、同じようにWebで使われていないという理由でAPNGを引っ張り出してきても、必要なコストがたぶん低めな上、XULのUI部分では使い勝手が良いという影で大活躍しているフォーマットとは根本的に違うので、それを引き合いに出してもなかなか駄目なんじゃないかなぁと思います。

透過が使えるというのは魅力に聞こえるんですが、JPEGのようなノイズの出方のある画像形式で透過って使い道あるのかなぁというのも疑問ではありますね……

2009年8月26日

システムサウンドの再生と問題と、今後どうしよう 初回投稿日時: 2009年08月26日20時19分49秒
最終更新日時: 2009年08月26日20時50分04秒
カテゴリ: Memo Mozilla Core 雑談
固定リンク: id=2009082600
リンク元: 0件
SNS: (list)

Geckoではシステムサウンドやビープ音の再生をnsISoundを通して行っていますが、MDCのドキュメントにもあるように、

var sound = Components.classes["@mozilla.org/sound;1"]
                      .createInstance(Components.interfaces.nsISound);

このようにインスタンスを生成して呼び出し、ということをしなくてはいけません。そしてSeaMonkeyのコード以外(何のコードかは忘れましたが)は再生の度にnsISoundのインスタンスを作成して呼び出して破棄、ということを実際に繰り返しています。

案の定このやり方のままでナビゲーションに関するシステム音の再生を実装してみると、ページの読み込み速度に関わってしまって、スコアを落としてしまう結果になっています。

Windows版のみ、再生時に別スレッドで再生するAPIを呼び出すことでUIがロックされることを防ぐようにしましたが、同様の問題はLinuxも抱えているようです。また、他のプラットフォームもAPI自体が完全に非同期なものでない限り、少なくともそれは発生してしまいます。

今更nsISound自体を廃止する訳にもいかないので、従来のコードとの互換性を維持したままこれらを解決しようとすると、nsISoundServiceというサービスでも作り、これがnsISoundのインスタンスを一つだけ内部に確保しておき、このインスタンスを使い回すようにすれば一つ目の問題を解決できそうです。

またnsISoundのメソッドを呼び出す時に常に別スレッドで呼び出すようにすれば二番目の問題も解決できそうです。

なんていうことを考えてはいるものの、さていつから取りかかれるやら……

2009年8月27日

Bug 6216 Linux では、CJK の文字でもキャレットが太くならない 初回投稿日時: 2009年08月27日13時54分39秒
カテゴリ: Mozilla Core バグ却下
固定リンク: id=2009082700
リンク元: 1件
SNS: (list)

昨日、大島さんとこの問題についてIRCで喋ったのですが、Linuxではフォントにアンチエイリアシングが効いているし、特に問題となるフォントやサイズには出会っていない、とのことです。さらに、geditではキャレットがGeckoと同じ、黒い縦棒でしか無いようで、反転表示されないそうです。

そうなると、大島さんが解説しているとおり、現在は常にシステムと同じ太さのキャレットがLinux版のみ表示されていますので、これで問題がないはずである、と仮定出来る以上、下手に拡大解釈した動作にすべきでないとも言えますので、一旦、wontfixにして閉じています。

もし、Windowsと同様に、見づらい環境等あるならバグにコメントをください。内容等々によっては対応すべき問題であるとは考えています。何しろアクセシビリティに関わる話ですので。

Bug-org 511534 Poor interaction with the software keyboard 初回投稿日時: 2009年08月27日14時49分46秒
最終更新日時: 2009年08月27日18時14分26秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2009082701
リンク元: 0件
SNS: (list)

Dougから昨日、直接GTK2 widget部分のログが送られてきて、なんか変な動作になるんだが心当たりあるのかと聞かれました。

1073790592[40338110]: IM_commit_cb
1073790592[40338110]: OnContainerFocusInEvent [4038a600]
1073790592[40338110]:   SetFocus [40fb2e00]
1073790592[40338110]: IMESetFocus 40fb2e00 (4357e540)
1073790592[40338110]: IMELoseFocus 40fb2e00 (4357e540)
1073790592[40338110]:   widget now has focus in SetFocus() [40fb2e00]
1073790592[40338110]: IMESetFocus 40fb2e00 (4357e500)
1073790592[40338110]: [40fb2e00] Opening Hildon Keyboard (4357e500)
1073790592[40338110]: Events sent from focus in event [4038a600]
1073790592[40338110]: OnContainerFocusOutEvent [4038a600]
1073790592[40338110]: IMELoseFocus 40fb2e00 (4357e500)
1073790592[40338110]: IMELoseFocus 40fb2e00 (4357e500)
1073790592[40338110]: IMESetFocus 40fb2e00 (4357e540)
1073790592[40338110]: IMELoseFocus 40fb2e00 (4357e540)
1073790592[40338110]: [40fb2e00] Closing Hildon Keyboard (4357e540)
1073790592[40338110]: Done with container focus out [4038a600]
1073790592[40338110]: OnContainerFocusInEvent [4038a600]
1073790592[40338110]:   SetFocus [40fb2e00]
1073790592[40338110]: IMESetFocus 40fb2e00 (4357e540)
1073790592[40338110]: IMELoseFocus 40fb2e00 (4357e540)
1073790592[40338110]:   widget now has focus in SetFocus() [40fb2e00]
1073790592[40338110]: IMESetFocus 40fb2e00 (4357e500)
1073790592[40338110]: [40fb2e00] Opening Hildon Keyboard (4357e500)
1073790592[40338110]: Events sent from focus in event [4038a600]
1073790592[40338110]: OnContainerFocusOutEvent [4038a600]
1073790592[40338110]: IMELoseFocus 40fb2e00 (4357e500)
1073790592[40338110]: IMELoseFocus 40fb2e00 (4357e500)
1073790592[40338110]: IMESetFocus 40fb2e00 (4357e540)
1073790592[40338110]: IMELoseFocus 40fb2e00 (4357e540)
1073790592[40338110]: [40fb2e00] Closing Hildon Keyboard (4357e540)
1073790592[40338110]: Done with container focus out [4038a600]
1073790592[40338110]: IM_commit_cb 

時系列は上が古く、下が新しいものです。これを見ると、フォーカスがセットされたり、奪われたりしていることが分かりますが、Doug曰く、Closing Hildon Keyboardは呼ばれるべきではない、とのこと(Hildon KeyboardとあるログはDougがローカルで追加したもので、実際のコードには入っていません)。

コードとログとを照らし合わせてみると、元々の私の設計とは明らかに異なる部分があることが分かりました。それはOpening/Closing Hildon Keyboard直前のIMESetFocus/IMELoseFocusの呼び出し履歴です。

これらはコードを見る限り、明らかにSetIMEEnabledからの呼び出しです(他からの呼び出しならこの直前の行に呼び出しもとのログが残るようになっています)。ですが、Dougのテストはあくまで、ひとつのフィールド上にフォーカスを当ててのものですので、ネイティブなフォーカスイベントが発生していたとしても、Gecko上でのフォーカスの移動は無い(DOMで言うと、activeElementに変化はない)はずです。ですので、SetIMEEnabledが呼び出されること自体がバグです。また、例え呼び出されたとしても、安全策が取り入れられていて、activeElementに対応したIMEの状態を送られているのであればSetIMEEnabledは直ちにその呼び出しを無視して、何も行わないのでバグは抑制されているはずです。

つまり、SetIMEEnabledが間違えたタイミングで、間違えた状態と共に呼び出されていることになります。

ここでさらに、Closing Hildon Keyboard直前の、IMELoseFocusに注目してみると、その間違えた状態というのは、IsIMEEditableState()trueを返す時だと分かります。そう、つまり間違えて送られてきている状態は、nsIWidget::IME_STATUS_DISABLEDであると分かります。

もちろん、実際にはフォーカスが移動していないのですが、nsIWidget::IME_STATUS_DISABLEDが設定される、ということはフォーカスを持った要素が無くなった、という意味ですので、ログから察するに、ウインドウがdeactiveになるときに誤って、これを呼んでいる可能性が高いと言えます。

で、ここ数ヶ月、こんな変化が何で起きたか推測してみると、focus refactoringしか思い当たりません。ここでは、SetIMEEnabledを呼び出す、nsIMEStateManager::OnChangeFocus()の呼び出しコードをnsEventStateManagerからnsFocusManagerに移動し、集中管理するようにしたからです。するとやはり、ウインドウがdeactiveになる時にもnsIMEStateManager::OnChangeFocus()が呼び出されていることが分かったので、リンク先のバグでのレビュー結果となっています。

ちなみにこのバグ、Fennecで発見されましたが、Window ManagerによってはLinuxでも発生しているはずです。片貝さんが以前、これの実装をするときのレビューで教えてくれたのですが、一部のWindow ManagerはIMEの候補ウインドウ等にフォーカスを移してしまって、Fx自体がdeactiveになってしまう可能性があるそうです。もしそうなった場合、trunkでは強制的に確定されるようになってしまっていました。そう、かなり重大なバグであったにも関わらず、ここまでバグ報告が無かったのは、そういったマイナーな環境をテストできるほど、テスタの確保(確認する目を増やす、というもともとの理念)が、IMEに関してはまだまだできていないと言えるでしょう。