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

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

もずはっく日記(2012年10月)

2012年10月20日

Bug-org 795785 editor isn't scrolled to the caret position if editor specified overflow: hidden; 初回投稿日時: 2012年10月20日11時39分48秒
カテゴリ: CSS Firefox Google Chrome IE modest Mozilla Core Mozilla18 Opera Safari バグ修正
固定リンク: id=2012102000
リンク元: 0件
SNS: (list)

twitter.comの、ツイートを書き込む<textarea>に、overflow: hidden;が指定されているため、CSS仕様を忠実に守っているFirefoxでのみ、キャレットを移動してもスクロールできず、入力した内容が確認できないことがある、というバグです。

modestに記事を書きましたが、CSS仕様では、overflow: hidden;の要素では、スクロールできるユーザインターフェースを提供してはならない、となっています。勘違いしてる人を時々見かけますが、ユーザインターフェースというのは、GUIのことだけではなく、操作全般を指します。キー入力や、マウスホイール、スワイプ等でもスクロールできてはいけません。

実際、他のブラウザでも、中身が編集可能ではない要素で、overflow: hidden;を指定していると、一切、スクロールできませんが、何故か、<textarea>の場合や、contenteditableな場合にはキャレットの移動によって、スクロール可能でした。

今回の修正で、エディタの内容が変更された場合と、キャレットが移動した場合に、編集可能な要素だと、スクロールが行えるように修正しています。編集不能な要素では引き続き、ユーザによるスクロールは不可能です。

Bug-org 791953 gfxFont.h(2080) : warning C4244: 'return' : conversion from 'double' to 'float', possible loss of data 初回投稿日時: 2012年10月20日11時47分07秒
カテゴリ: Mozilla Core Mozilla18 バグ修正
固定リンク: id=2012102001
リンク元: 0件
SNS: (list)

gfxのヘッダファイルのせいで、warningが大量に出力されていたバグです。

このwarningが出ていたのは、VCのみのようなんですが、そのwarningが、floatを戻り値とするメソッドで、1.0、もしくは-1.0を返していたのがコンパイラの機嫌を損ねていたようです。

レビュアのコメントにもありますが、こういう、ロスが発生しない場合にこのwarningを出すのは、どうなんでしょうね? 仕様があるのか無いのか知りませんが。

Bug-org 795230 Use ASCII capable keyboard layout for computing charCode if current input source is an IME mode and open 初回投稿日時: 2012年10月20日11時55分49秒
カテゴリ: Events Mac Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012102002
リンク元: 0件
SNS: (list)

ことえりで、かな打ち設定にしていた場合、IMEが使えない局面、つまり、エディタがフォーカスを持っていない場合でも、keypressイベントの、charCodeに、IMEがオフの場合に入力される文字ではなく、かな文字がセットされている、というバグです。

他のプラットフォームの挙動にあわせるため、IMEがキーボードレイアウトをオーバーライドしていても、そのキーボードレイアウトがASCII capableではない場合、その時点で割り当てられている、ASCII capableなキーボードレイアウトを利用して、charCode値を算出するように変更しています。

これで、何がうれしいかと言うと、charCodeを利用して、独自のショートカットキーを実装したWebアプリでも、ことえりのかな打ちユーザや、中国語の多くのIMEのユーザ、ハングルIMEのユーザが、そのショートカットキーを利用できるようになったわけです。

ちなみに、ATOKはキーボードレイアウトをオーバーライドしていませんでしたので、かな打ちでも、元々この問題は発生していませんでした。

Bug-org 786956 Rewrite NSFlagsChanged handler 初回投稿日時: 2012年10月20日12時14分21秒
最終更新日時: 2013年01月02日10時22分02秒
カテゴリ: Events Mozilla Core Mozilla20 バグ修正
固定リンク: id=2012102003
リンク元: 0件
SNS: (list)

Cocoaの、NSFlagsChangedイベントのハンドラをまるごと書き直して、まともなものにしよう、というバグです。

これまでは、前回のイベント時との、モディファイアフラグの差分から、その差分に応じて、イベントから通知されたkeyCodeを利用して、キーイベントを生成するという、不思議なコードになっていました。ですので、keyCode0の場合には、aキーのイベントが発生してしまったり、フラグの差分から、複数のイベントを同じキーのイベントとして発生させていたり、モディファイアフラグが変わらないモディファイアキーのイベント、例えば、左のshiftキーを押しながら、右のshiftキーを押した時にはイベントが発生しない、といった問題がありました。

今回の修正で、基本的にはkeyCodeを基に、単にキーイベントを生成するようになりました。通常、普通にキーを押した、離した、といった場合にはこれだけで完璧に動きます。

ややこしいのが、keyCode値が0のケースです。この場合、shiftoptioncommandcontrolのフラグの変化は分かるのですが、これだけだと、実際に変化したキーが、左右どちらのものか分かりません。そこで、ドキュメント化されていない、デバイス依存のモディファイアフラグを用いて、ややハッキーな形で修正を行っています。デバイス依存といっても、物理キーボードの種類によって変わる、というほどデリケートなものではないことは確認しているので、通常のキー押下時に、キーコードと、モディファイアフラグの関連づけを行い、それ以降に発生した、keyCode0NSFlagsChangedイベントハンドリング時に利用する形をとっていますので、かなり安全だとは思います。ちなみに、このイベントが発生するパターンとして、command (+ shift) + tabというパターンのみ、確認しています。

ひょっとすると、似たようなイベントを生成してくる、アクセシビリティ改善用の外部アプリがあると、うまく動かないかもしれませんが、このハンドラで動かないレベルだと他のアプリでも動くかどうかかなり怪しいので、無いんじゃないかと思います。もし、問題がありましたら、bugzillaに報告してもらえれれば対応していきます。

ちなみに、修正時にWebKitの動作も見ながら作業してましたが、それよりも期待通りに動くようになってしまってます。

当初、Mozilla 19での修正でしたが、問題が見つかったため、Mozilla 20に持ち越されました。詳細は、Bug-org 815383の修正の記事を参照してください。

Bug-org 705057 Implement composition event manager 初回投稿日時: 2012年10月20日12時27分52秒
カテゴリ: Events Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012102004
リンク元: 0件
SNS: (list)

これまで、Geckoでは、ネイティブのIMEのイベントから、DOMイベントを生成して、その時点でフォーカスのある要素に対して、そのイベントを発行していました。しかし、これでは、意図せず、強制確定前にフォーカスが移動してしまったケースでは、おかしなことになってしまいます。また、現在のXPレベルのコードでは、エディタ以外に未確定文字列を編集中であるかどうかを管理しているクラスがありませんでしたので、色々と不便がありました。

そこで、compositionstartで、インスタンスを作成し、compositionendまでの一連のIME系のイベントを全て、compositionstartを発行したイベントで発行し、compositionend後に破棄されるクラスを作ると色々と便利だよね、というアイデアになったわけです。

TextCompositionというクラスのインスタンスが、ひとつの、未確定文字列編集を表していて、これのプロセス全体でのリストが、nsIMEStateManagerで管理されている、という形をとっています。

この修正によって改善したのは、

  • ワンセットになる、IME関連イベントが全て、同じ要素で確実に発生するようになった
  • 生成されたTextCompositionが自動テストで生成されたものかどうか判別できるので、強制確定を含めた自動テストが書けるようになった

の2点のみです。

Bug-org 645974 Switching focus with uncommitted IME text does not commit or send events, and leaves corrupted text state. 初回投稿日時: 2012年10月20日12時37分01秒
カテゴリ: Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012102005
リンク元: 0件
SNS: (list)

IMEの強制確定が行われる直前にフォーカスが移動してしまい、強制確定に失敗して、エディタの動作がおかしくなるバグの、実例です。

このバグでは、<iframe>designModeのエディタを二つ用意して、片一方で未確定文字列がある場合に、もう一方をクリックすると、最初の方には未確定文字列が残り、新しい方にcompositionendイベント等が発行されていました。

同じドキュメント内でのフォーカス移動だと、ひとつのPresShellに全イベントが集中するので、大丈夫なのですが、このように、複数のドキュメントをまたぐと、それぞれのPresShellがフォーカスを得た時にイベント受け取り、そのドキュメント内のアクティブ要素に対してイベントを発行するため、このようなことが発生していました。

現在は、Bug-org 705057の修正により、TextCompositionPresShell非依存でイベントの発行先を管理するようになっているので、問題なくなっています。

2012年10月22日

Logicool(あちらではLogitech)のマウスドライバ、SetPoint 6.50の動作について 初回投稿日時: 2012年10月22日15時30分39秒
最終更新日時: 2012年10月25日16時44分56秒
カテゴリ: Mozilla Core
固定リンク: id=2012102200
リンク元: 2件
SNS: (list)

Logicoolのマウスドライバ・ユーティリティである、SetPoint 6.50がリリースされています。自動アップデートではまだ配布されていないのか、SetPoint 6.32のUIからはアップデートできませんでしたが、サイトから直接ダウンロードして入れることはできました。

SetPoint 6.32までは、Geckoの生成したウインドウに対しては、高解像度スクロールを行うために、適切なメッセージを送信してきていました。標準通り、スクロール量を3行に設定しておくと、だいたい、1/3行分ごとにホイールのメッセージが送信されていました。

これに対して、SetPoint 6.50では、FirefoxにLogitech SetPoint 6.5、というアドオンをインストールしようとするようになりました。どうも、高解像度スクロールをGeckoで利用するには、このアドオンが必須のようで、このアドオンを入れていない状態では、常に3行ごとのホイールイベントを送信してきて、高解像度スクロールが行われなくなりました。たとえば、このアドオンが提供されていないThunderbirdでは高解像度スクロールが行えなくなりました。

そして、Firefoxにこのアドオンを入れた場合も問題なのですが、なんと、デルタ値を1単位で大量のホイールイベントを送信してくるように修正されています(デフォルトの、3行スクロール、という設定は、デルタ値120で3行分という意味)。しかも、手元のマウスで確認したところ、文章を読んでいるときに、ゆっくりと回す感じで、1ノッチ分だけホイールを回してみたところ、SetPointが指定してるスクロール量が従来の1/3になっていることが分かりました。このため、非常にスクロールスピードが遅くなっていると感じられると思います。

このため、とことん細かいスムーズスクロールが可能にはなっていますが、Gecko側のスムーズスクロール等とは相性が悪い感じがありますので、SetPointをアップデートされる場合にはご注意下さい。

当初、Thunderbirdや、SeaMonkey、そのほかのXULRunnerアプリでは6.50にアップグレードすると、高解像度スクロールが無効になると書いていましたが、米Logitechの開発者の方の指摘から、再検証したところ、6.32でもFirefox以外のGeckoベースのアプリでは高解像度スクロールがサポートされていませんでした。ここに訂正しておきます。

スクロールスピードの問題に関しては、引き続き、検証してもらっています。

Firefox上で、Flash Playerが遅い、ハングアップする、日本語入力できない、という方には、保護モードの解除をお勧めします 初回投稿日時: 2012年10月22日20時43分07秒
最終更新日時: 2015年05月27日11時03分38秒
カテゴリ: Firefox Flash Memo plugin Windows
固定リンク: id=2012102201
リンク元: 85件
SNS: (list)

Firefox 36以降では、簡単に変更できるようになっていますので、その解説記事を参照してください

つまり、この記事の複雑な手順での作業は必要なくなっています。

注意: Flash Player 10.3のサポートは終了しましたので、ダウングレードによるトラブル回避は非常に危険です。絶対に、行わないでください。

5月以降、Firefoxに関する苦情を各所で目にすると、半数以上がFlash Playerに絡んでいるもの、という印象があります。Windows Vista以降のFirefoxでFlash Playerの動作が遅い、ハングアップする、といった方や、Flash Playerの提供している入力欄で、Google日本語入力が使えない、かな打ちがIME問わず出来ない、といった方には、保護モードの解除をお勧めします。と言いますか、日本語入力の問題に関してはこれしか解決策はありません。

  • パフォーマンスが異様に悪い
  • クラッシュする
  • ブルースクリーンが出る
  • 他のアプリにまで影響が出る
  • 保護モードの解除では解決しなかった

といった症状の方はグラフィックチップ(GPU)のドライバのバグが原因の可能性が高いので、ドライバの更新を試された方が良いです。

保護モードの解除の仕方は簡単です(Adobeのサイトにも手順がありますが、以下のやり方が分かりやすいでしょう)。

  1. [スタートボタン]をクリックし、[アクセサリ]にある、[メモ帳]を右クリックします。
  2. コンテキストメニューの、[管理者として実行...]をクリックします(通常設定ならこのあと、UACの確認ダイアログが出ます)。
  3. そのメモ帳で、Windowsが32ビット版の場合、C:\Windows\System32\Macromed\Flash\mms.cfgを、64ビット版場合、C:\Windows\SysWOW64\Macromed\Flash\mms.cfgを開きます(スクリーンショットは64ビット版)。
  4. そのファイルの最後に、ProtectedMode=0という行を追加します。
  5. ファイルをそのまま上書き保存し、Windowsを再起動します。

これにより、他のWebブラウザで動作している時と同様に、問題の原因となっている保護モードが動いていない状態でFlash Playerが動作するようになります。

ここで、セキュリティを気にする方であれば、Flash Playerの保護モードを切るということに不安を感じられるかもしれません。

確かに、この設定変更を行うと、Flash Playerのセキュリティは弱くなってしまうのは事実です。しかし、保護モードは、セキュリティホールを突かれ、万が一攻撃がPC内に及んだ時に、その影響範囲を最小限に抑えるための、最後の防壁です。ですので、常にセキュリティホールが修正されている最新版を利用し続ける限りはある程度は安全と言えます。

また、そもそもこの機能は、Flash Player 10.3以前には実装されていませんでしたし、最新版であっても、他のブラウザ上で動作している時は動作していません。また、Windows XP上で動作している時にはブラウザを問わず機能しません。ですので、この状態を特に危険と考える必要はありません。

安全であることは大切ですが、誰もがセキュリティのためにインターネットへの接続をやめないのと同様に、機能が使えなくなるレベルのセキュリティであればユーザにとっては不要なものとしか言えませんので、ここのバランスは各利用者の方に判断してもらえれれば良いレベルではないかと思います。

2012年10月23日

Bug-org 771832 File not found error for HTTP URL, can be fixed by a forced reload 初回投稿日時: 2012年10月23日11時17分25秒
最終更新日時: 2012年10月23日15時33分51秒
カテゴリ: Firefox Mozilla Core Mozilla17 Mozilla18 Mozilla19 バグ修正 バグ原因判明
固定リンク: id=2012102300
リンク元: 0件
SNS: (list)

数ヶ月にわたって、多くの環境で再現していた不愉快なバグの筆頭がようやく修正に向かっています。このバグは、キャッシュファイル作成時に、壊れたファイルを作成してしまい、それを読み込みに行く側も壊れたファイルを無視して、ネットワークから再読み込みせずに、"File not found"というエラーを返すだけに留めるというものです。これが、CSSファイルや、JSファイルで発生した場合、ページのレイアウトが壊れたり、ページ内の特定の機能だけが使えなかったり、ページの初期化が行われなかったりと、様々な症状を引き起こします。

現在、壊れたファイルの作成だけはmozilla-central (Firefox 19)で修正されています。しかし、壊れたキャッシュファイルの代わりに、ネットワークから読み直す、という修正は未だに行われていません(Bug-org 802915)。このため、見た目にはまだ修正されていないように見えることが多いですが、現在のNightlyでキャッシュを削除すれば発生しないようになっているはずです。

Firefox 16でも再現するという情報があり、キャッシュの作成時のバグは、Auroraのみならず、Betaでの修正も許可が既におりていますので、まもなく反映されるのではないかと思います。

AuroraとBetaにも修正が入りました。これで、リリース版以外はキャッシュをクリアすることでこのバグを回避できるようになります。

Bug-org 729536 Deadlock by xul!nsHttpConnectionMgr::Shutdown 初回投稿日時: 2012年10月23日15時33分28秒
カテゴリ: Firefox Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012102301
リンク元: 0件
SNS: (list)

Firefoxを起動したままWindowsをシャットダウンしようとすると、応答が無くなって強制終了するしかなくなるバグです。こちらもmozilla-centralに修正が入りました。Firefox 17までノミネートされていますが、これも修正されると、Firefox 17は良い感じに改善点の多いリリースになりますね。

2012年10月28日

Bug-org 802896 nsIMEStateManager should use nsPresContext::GetNearestWidget() instead of its GetWidget() 初回投稿日時: 2012年10月28日11時46分58秒
カテゴリ: Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012102800
リンク元: 0件
SNS: (list)

nsPresContextに、ルートフレームを持っているnsIWidgetを返すメソッドを追加したので、nsIMEStateManagerはこれを使えば良いよというバグです。

今後、IME関係のコードがnsIWidgetに直接アクセスする必要があるなら、全てこのメソッドを利用するようにしていく予定です。

Bug-org 801989 TextComposition needs to get identifier of native IME context for managing composition per it 初回投稿日時: 2012年10月28日11時52分34秒
カテゴリ: Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012102801
リンク元: 0件
SNS: (list)

TextComposition実装時には、パッチの複雑化、肥大化を避ける意味で、nsIWidgetごとに独立した未確定文字列を持てるようにしていました。

実際には、各プラットフォームでは、ネイティブのIMEコンテキストがあることが多く、未確定文字列はこれごとに一つ、という形になりますので、それを、nsIWidget::GetInputContext()経由で opaque なポインタとして取得し、未確定文字列をネイティブIMEコンテキスト単位で一つになるように修正しました。

現在、Geckoのエディタはフォーカスが他の要素に移る場合には強制確定を行いますので、このパッチによる挙動の変化はありません(Linuxでは、IMによっては強制確定に失敗するので、何らかの改善はあるかもしれませんが、未確認です)。

Bug-org 805306 Get rid of nsIMEStateManager::OnTextStateBlur() and nsIMEStateManager::OnTextStateFocus() 初回投稿日時: 2012年10月28日12時00分52秒
カテゴリ: Mozilla Core Mozilla19 TSF バグ修正
固定リンク: id=2012102802
リンク元: 0件
SNS: (list)

nsIMEStateManagerは、フォーカス移動の際に、nsFocusManagerから、IMEの有効・無効の管理のために、OnChangeFocus()を呼んでもらい、nsTextStateManagerの生成・破棄のために、OnTextStateFocus()と、OnTextStateBlur()を呼んでもらうという、nsIMEStateManagerの内部を知らないと、非常に意味の分からない設計になっていました。

OnChangeFocus()側を少しいじることで、OnTextStateBlur()が簡単に削除できることが分かったので、まずそれを行っています。

そして、Geckoのエディタがフォーカスイベントを処理後に、nsIMEStateManager::OnFocusInEditor()という新しいメソッドを呼んでもらうことで、本来、OnTextStateFocus()メソッドが設計された時点で想定していた順序で確実に呼び出されるように修正しています(script blockerでフォーカスイベントの生成タイミングがずれた時、呼び出し順序が狂うバグがあったようなのですが、それが修正されています)。

2012年10月31日

Bug-org 805761 FrameMetrics.h(89) : warning C4244: 'argument' : conversion from 'gfxFloat' to 'mozilla::gfx::Float', possible loss of data 初回投稿日時: 2012年10月31日15時08分52秒
カテゴリ: Mozilla Core Mozilla19 Windows バグ修正
固定リンク: id=2012103100
リンク元: 0件
SNS: (list)

例によって、Windowsでビルド中にヘッダ内のwarningが大量に出力されて、肝心のメッセージを探しにくくなってた迷惑なバグです。なぜ、これが他のプラットフォームで出なかったのかが分からないのですが。

Bug-org 806300 Use intptr_t instead of int64_t for the 3rd argument of GetInputContext() of PBrowser 初回投稿日時: 2012年10月31日15時12分34秒
カテゴリ: Mozilla Core Mozilla19 バグ修正
固定リンク: id=2012103101
リンク元: 0件
SNS: (list)

プロセス間通信時に、GUIイベントを処理しているプロセスのネイティブIMEコンテキストのポインタを、もう一方のプロセスでも単なるIDとして使う必要があるのですが、その時の受け渡しに、int64_tを利用していました。しかし、それよりもintptr_tの方が良いんじゃないか? というツッコミが来たので、修正してます。正直、知らなかっただけですけどね、この型。