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

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

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

2012年2月6日

Firefox Inputからいくつかピックアップ 初回投稿日時: 2012年02月06日13時58分35秒
最終更新日時: 2012年02月09日15時55分02秒
カテゴリ: Firefox Mozilla Core 雑談
固定リンク: id=2012020600
SNS: (list)

ユーザコミュニティでサポートしてくれている貢献者の方の参考になれば、と思ったので、いくつか気になったものについて書いておきます。

誤ってBabylonツールバーをインストールしてしまい、新しいタブを開くたびにBabylonの画面が出るようになりました。コントロールパネルで削除してもだめです。ちなみにIE８はきちんと消えました。 Babylonの消し方を教えてください。

英語版のヘルプではTop Issuesに名前を連ねているようです(英語版の記事)。Firefoxではアドオンマネージャから削除しないといけないようですね。

URLに/10.0/が含まれるフィードバックが送れない例:/firefox/10.0/releasenotes/

報告しておきました。ありがとうございます。

半角カナ文字で半濁音、濁音を打った際、顔文字などに使う為に半角カナ部分を消そうとしても文字と記号が１つの文字のような扱いをされる挙動は非常に邪魔です。

Linux/Macではネイティブの動作と同じなので、バグではありません。問題はWindows。こうなったきっかけは、:first-letterの挙動を修正するためだったようなのですが、selectionや、エディタもその部分を共有していたため、編集においても影響が出ています。

今のところ、ぱっと修正できない上に、半角カナをWeb上ではほとんど見かけないので、私のToDoリストでは優先順位は低いです。どなたか修正作業をやってもらえるならサポートしますので、当該バグで名乗りを上げて下さい。

バージョン１０になってから、時々テキストボックスへの文字入力が出来なくなる現象が発生する。

あちらこちらで見かける、regressionですが、OOPPをオフにしている場合にのみ発生するそうです。Javaはデフォルトでオフになっているようなので、これはかなり悩ましいですが、それ以外、特にFlashで発生している場合は、ひとまずOOPPを有効にしてもらえば良いと思います。

全てのリポジトリでバグは修正されました。緊急リリースで修正されるかもしれません。

Mac版のアクセスキーのモディファイヤがCtrlというのはどうかと思います。アドオンと競合しやすいです。個人的にはOpera式にして全プラットフォームで統一するのが理想かとおもいます。

Macの場合、そもそもネイティブにアクセスキーという考え方がありませんので、Controlぐらいしかモディファイアキーが余っていない、というのがあるかと思います。既に馴染んでいるユーザも居るかもしれないので、それなりの理由が無ければ今更変えることは無いと思います(各ブラウザでの比較)。

これはui.key.contentAccessでカスタマイズすることができるので、それぞれカスタマイズしてもらうしかありません。値の意味は、

1
Shift
2
Control
4
Alt (Option)
8
Command

で、組み合わせはOR演算で指定できます(Shift+Controlなら、3)。

2012年2月9日

Firefoxと、Thunderbird向けの、ThinkPadのTrackPointのドライバのベストな設定 初回投稿日時: 2012年02月09日16時29分23秒
最終更新日時: 2012年02月09日16時30分26秒
カテゴリ: Firefox Mozilla Core Thunderbird
固定リンク: id=2012020900
SNS: (list)

TwitterでMakotoさんからThinkpadのTrackPointの設定について情報提供があったので、ここにまとめておきます。

ThinkPadのTrackPointはドライバのインストールフォルダ内にある tp4table.dat というテキストファイルの中身を修正することで、ドライバが知らないアプリケーションに対してもスクロールの指示をアプリ側の期待通りに送信させることができるそうです(私自身は実機を持っていないので伝聞形式になってしまいますが)。

このファイルのFirefox/Thunderbird向けの修正方法として、 

*,*,firefox.exe,*,*,MozillaWindowClass,WheelVkey,0,9

という一行を追加する、というノウハウが広く知られているようですが、Firefox 4以降ではこの設定値はベストではありません。各設定値の意味をまとめているブログを発見しましたが、もし、最新版のドライバでもこれらの値しか選択肢がない場合、残念ながらドライバ側の設定だけではベストの状態になりません。ですが、Firefox側でも設定を行うことで改善できますので紹介しておきます。

まず、TrackPointのドライバをアップデートできるのであれば最新版にアップデートしてください。そうすると、上記の行がデフォルトで設定されているそうです。ので、これを以下のように書き換えます。 

*,*,firefox.exe,*,*,MozillaWindowClass,WheelStd,0,9

また、Thunderbirdも設定するのであれば、 

*,*,thunderbird.exe,*,*,MozillaWindowClass,WheelStd,0,9

という行も追加してください。次に、Firefoxなら、ロケーションバーにabout:configと入力し、設定のエディタを起動します。Thunderbirdでは、設定画面の詳細の、一般タブにある設定エディタを起動します。

設定エディタ内で、mousewheel.emulate_at_wm_scrollという項目を見つけ、これをダブルクリックして、trueに変更してください。

これでシステムを再起動すれば、TrackPointでも横方向へのホイールの動作をFirefoxとThunderbirdに送信することができるようになっています。

以下、簡単に変更の意味を解説しておきます。

まず、WheelVkeyは、縦方向にはWindows標準の縦のホイールのメッセージを送信しますが、横方向には左右矢印キーが押された、というメッセージを送信するため、テキストエディタを横スクロールしようとすると、キャレット(点滅している縦棒)が左右に動くだけでスクロールできません。WheelStdに変更すると、縦方向はそのままで、横スクロールの操作を、「横スクロールしろ」、というメッセージの送信に変更できます。

この変更で、テキストエディタでも横スクロールできるようになりますし、Webアプリケーションでも、左右矢印キーのキーイベントとして認識されて誤作動するということはなくなります。

続いて、mousewheel.emulate_at_wm_scrollの変更ですが、こちらは、上記の設定で、「横スクロールしろ」、というメッセージを、マウスホイールからの横スクロールの処理だと認識するようにします。

TrackPointから送信される「横スクロールしろ」、というメッセージはマウスホイールのためのメッセージではないため、この設定を変えてない場合は、FirefoxやThunderbirdはマウスカーソルの位置からスクロール対象を決定しません。このため、1回、スクロールしたい領域をクリックしてからスクロールの操作をしなくてはいけません。設定を変えることによって、横方向へのマウスホイールの操作として処理するようになりますので、このイベントを処理するWebアプリケーションが期待通りに機能するようになります。

ただし、このメッセージはウインドウ内をキャプチャするソフトが内容をスクロールするために使うことがありますので、そういったアプリを利用されている場合には、そちらのソフトの動作がうまくいかなくなるかもしれませんので、実害がある場合は元に戻してください(Firefox/Thunderbirdの再起動は必要です)。

2012年2月10日

Bug-org 713628 [IMM] Do nothing if composition string isn't changed even when WM_IME_COMPOSITION is received 初回投稿日時: 2012年02月10日12時38分08秒
カテゴリ: Mozilla Core Mozilla13 バグ修正
固定リンク: id=2012021000
SNS: (list)

古いIMEのコードの整理第一弾です。WM_IME_COMPOSITIONのlParamはMSDNのドキュメントには、Value specifying how the composition string or character changed. と書かれています。つまり、そのWM_IME_COMPOSITIONで何が変化したのかを示すビットマスクなのですが、そのlParamが、「確定」も「未確定文字列の変化」も示さない場合にエディタ上の未確定文字列を削除してしまうという奇妙なコードがありました。

MSDNの仕様からすると、特異なケースにも関わらず、特にコメントも無いので何もしないようにすれば良いかと思いましたが、えむけいさんのレビューに基づいて調査してみると、日本語のIMEは少し奇妙な動作をしていました。

Windows 7では、IMMはOSにエミュレートされていますので、Windows 7自身が昔のIMEの動作を互換性のためにそのまま真似ているのだと思われますが、日本語のIMEでは、未確定文字列が空になった時、例えばBackspaceキーで未確定文字列を全部削除した時に、WM_IME_COMPOSITIONが送信され、lParamにはGCS_COMPATTR、GCS_COMPCLAUSE、GCS_COMPSTR、GCS_CURSORPOSが含まれておらず、未確定文字列の「変化」ではなく、「結果」を元にフラグが設定されている印象です。

別のハックがあるおかげで、単純に何もしないようにしてしまっても問題はないのですが、より好ましい形に修正しています。

lParamに未確定文字列の変化を示すフラグが含まれていなくても、最新の未確定文字列を取得し、その最新情報に基づいた内容をエディタに通知するようにしました。

ATOK 2012では、Firefox利用時にカナロックの状態がおかしくなるバグを回避できる設定ができたようです 初回投稿日時: 2012年02月10日13時41分58秒
最終更新日時: 2012年03月11日14時39分32秒
カテゴリ: Firefox Google Chrome Memo Software 雑談
固定リンク: id=2012021001
SNS: (list)

FirefoxやGoogle Chromeもそうなんですが、ブラウザ自体のエディタやSkype等、未確定文字列の処理を自前で行っているアプリを利用中にFirefoxやGoogle Chrome上でATOKでかな入力中に未確定文字列を出していると、カナロックが変に外れてしまって、カナロックを再度かけ直すために未確定文字列を一度破棄して、Alt+カタカナ ひながな ローマ字キーを2回押さないといけない、という非常に煩わしいバグがあります。

以前、Firefox側で頻度を軽減できる修正は入れていましたが、それでも再現は続いていたのですが、それをATOK側で回避できる設定がATOK 2012で追加されています。

  1. 言語バーで、メニューを出して、[プロパティ(環境設定)(R)]を選択します。
  2. [入力・変換]タブを選び、[設定項目(Y)]のツリー内の、[入力補助]を選択します。
  3. [詳細設定(N)...]ボタンを押すとダイアログが出てくるので、その中にある[ｼｽﾃﾑ全体のｶﾅﾛｯｸを変更する(S)]と、[ATOK 2011 互換のｶﾅﾛｯｸ制御を行う(R)]にチェックを入れます。

この設定を行うと、ほとんどカナロックは外れなくなるようです。一度だけIMEをオンにすると同時に外れてしまったので、魔の時間はありそうですが。

テストしたい方はテスト用のページを開いてみてください。このページでは5秒おきにFlashがリロードされます。その時に別のタブか、別のアプリで未確定文字列を入れて、そのまま放置しておくと、テストページがリロードされますが、その際に上記設定を行わないとカナロックがおかしくなります。

残念ながら、この設定をオンにしていると、ATOKがオンの状態でAlt+Tabが使えなくなるようです。

色々とテストした感じでは、[ｼｽﾃﾑ全体のｶﾅﾛｯｸを変更する(S)]にチェックを入れただけではバギーで使い物にならない印象です。これだけだと、不安定で、未確定文字列の一文字目でカナロックがまだかかっていなかったり、フォーカスを移動した時に高確率で入力モードが全角英数に変わってしまいます。[ATOK 2011 互換のｶﾅﾛｯｸ制御を行う(R)]にもチェックを入れると、前者は再現しなくなりました。後者はFlashの読み込みと、ATOKのオンオフがかぶると再現するようですが、確率が減るので実用レベルかな、という感じです。

色々と試した結果、これらの新設定を使った場合、副作用がきつすぎて逆に使い物にならない、というのが私の結論です。ATOK 2013では完全に修正されてることを祈ります……

Bug-org 724471 [IMM] two sets of composition events are fired for a composition of Korean IME 初回投稿日時: 2012年02月10日16時32分51秒
カテゴリ: Mozilla Core Mozilla13 バグ修正
固定リンク: id=2012021002
SNS: (list)

古いIMEのコードの整理第二弾も兼ねたバグです。かなり古いバグでハングル文字用のIMEの挙動のために特殊なコードが入っていましたが、そのコードが原因で、ハングルを一文字確定するために2回、compositionstart、compositionupdate、compositionendがセットで発生していました。

ハングルのIMEは一文字、ハングル文字が完成するたびに確定されていく感じなのですが、スペースキーや、Enterキーを押した時に、編集中の文字はそのまま確定し、そのままスペースや改行が入力されるようになっています。

問題のハックは、スペースキーを押したときのハングルIMEの変な挙動に対応するものでした。ハングルIMEは、スペースキーを押した時に次のようにメッセージを送信してきます。

  1. WM_KEYDOWN (VK_PROCESSKEY)
  2. WM_IME_ENDCOMPOSITION
  3. WM_IME_COMPOSITION (GCS_RESULTSTR)
  4. WM_KEYDOWN (VK_SPACE)

普通は、WM_IME_ENDCOMPOSITIONは全てが終わってから送信されるべきなのですが、WM_IME_COMPOSITIONで未確定文字列を確定するイベントが後からやってきます。

このため、意図しないWM_IME_ENDCOMPOSITIONが来た場合には空の文字列で確定し、意図しないWM_IME_COMPOSITIONが来たら、それをWM_IME_STARTCOMPOSITIONを送信し忘れていると見なして処理する、という形になっていました。

今回の修正で、WM_IME_ENDCOMPOSITIONを受け取った時に、WM_IME_COMPOSITIONが確認できて、なおかつそれが確定しようとしているのであれば、WM_IME_ENDCOMPOSITIONでは何も処理しないようにしています。

Bug-org 722639 Needs some automated tests for bug 692145 初回投稿日時: 2012年02月10日16時36分36秒
カテゴリ: Mozilla Core Mozilla13 バグ修正 雑談
固定リンク: id=2012021003
SNS: (list)

例のクラッシュバグの修正ですが、ブランチでの修正を申請するにあたり、テストが無いことを理由に却下されると困るので、先に自動テストを作成しておきました。

遅くなりましたが、ブランチでの修正も現在申請しています。

2012年2月11日

イベントリスナの優先順位 初回投稿日時: 2012年02月11日10時44分01秒
最終更新日時: 2012年02月11日10時44分35秒
カテゴリ: Firefox Google Chrome IE Javascript Mozilla Core Opera
固定リンク: id=2012021100
SNS: (list)

ふと、イベントリスナを同じ要素に同じ条件で追加するとどういった優先順位になるのか気になったのでテストしてみました。

    このテストケースでは、エディタ上でのkeydownイベントを各ハンドラが呼び出された順序でリストに追記していきます。その結果はFirefox、IE、Chrome、Operaで以下のようになりました。

    1. 親要素のcaptureフェイズに最初に登録されたハンドラ
    2. 親要素のcaptureフェイズに二番目に登録されたハンドラ
    3. イベントターゲットのbubbleフェイズに最初に登録されたハンドラ (captureへの登録よりも前)
    4. イベントターゲットのbubbleフェイズに二番目に登録されたハンドラ (captureへの登録よりも前)
    5. イベントターゲットのcaptureフェイズに最初に登録されたハンドラ
    6. イベントターゲットのcaptureフェイズに二番目に登録されたハンドラ
    7. イベントターゲットのbubbleフェイズに三番目に登録されたハンドラ (captureへの登録より後)
    8. イベントターゲットのbubbleフェイズに四番目に登録されたハンドラ (captureへの登録より後)
    9. 親要素のbubbleフェイズに最初に登録されたハンドラ
    10. 親要素のbubbleフェイズに二番目に登録されたハンドラ

    親要素に仕掛けたハンドラでは、captureフェイズと、bubbleフェイズが順番逆でも大丈夫なのは当たり前として、イベントのターゲットではフェイズの指定は無視されています。そして、ハンドラは先に登録したものに優先権があるようです(これに関して明言している仕様がどこにあるのか知りません)。Webアプリ作る上では複数のハンドラでひとつのイベントを聞くようなことをすると、スパゲッティになるでしょうからやらない方が良いと思いますが、まあ、ちょっとした豆知識として。

    2012年2月15日

    Bug-org 625151 Alt key sometimes fails to open Menu bar 初回投稿日時: 2012年02月15日17時31分28秒
    カテゴリ: Mozilla Core Mozilla13 バグ修正
    固定リンク: id=2012021500
    SNS: (list)

    Windowsで、Altキーを押しても、メニューバーが表示されないことがある、というバグです。MozillaZine.jpのフォーラムにあがってた報告からバグを探して修正しました。

    再現条件を挙動から絞り込むのは難しかったのですが、コードを見ると分かりやすかったです。まず、Alt+Tabでウインドウがフォーカスを失う時にAltキーが押されているのかどうかを保存しているフラグがクリアされないケースがありました(というか、現状のUIだと基本的にはクリアされない)。ウインドウがフォーカスを失う時にはAltキーの状態を引き継ぐ必要が全くないはずなので、常にフラグをクリアするようにしました。もし、この部分の修正で問題があったとしても別のフラグを用意してどうにか対応すべき問題のように思えます。

    さらに、IMMがインストールされている環境ではもうひとつ、未だに残っているハックがこのバグをメジャーなものにしていました。現在、GeckoはWM_IME_NOTIFYをAltキーを押している間に受け取ると、`キー(半角/全角キー)のkeypressイベントを生成します。メニューバーはこのキーイベントを受け取ると、Altキーを押している間に別のキー入力があったため、Altキーのkeyupイベントでメニューバーをアクティブにする必要がないと判断するからです。ですので、この余計なイベントがAltキーによるメニューバーの表示操作はキャンセルされた、というフラグを無条件に立てていたため、次にウインドウがアクティブになった後、最初のAltキーのイベントをキャンセル済みであるとして処理しなくなっていました。

    後者のもうひとつの原因は、Altキーのkeydown時にはそもそもフラグを初期化すべきなはずですが、それをearly returnではないコードで書いたため、メンテナンスでフラグが増加したときにエンバグした感じです。正常ケースを、if文をネストして深い位置に書こうとすると条件判定が複雑になりすぎてこういうことになるので、成功したかどうかではなく、失敗したかどうか判定して、とっとと処理から抜ける方がやはり合理的ですね。

    2012年2月16日

    Bug-org 622247 Remove the hack for bug 23558 初回投稿日時: 2012年02月16日17時59分38秒
    カテゴリ: Mozilla Core Mozilla13 バグ修正
    固定リンク: id=2012021600
    SNS: (list)

    昔、bug-org 23558で、何故かnsPlaintextEditor側に入れられたハックの削除バグです。

    本来ならこういうのはnsWindow側でプラットフォーム側でつぶさないといけないんですが。

    現在のエディタではすでに、問題となったようなイベントの発生があったとしても問題がなくなっているのでハック自体を削除し、空文字列のcompositionが発生したとしても、正しくハンドリングできることを自動テストで確認しています。

    このバグの修正により、bug-org 725233のような、ハックが生んでしまったハックを取り除くことができます。

    2012年2月22日

    Bug-org 725233 [TSF] Remove text event hack for the nsEditor's hack which will be removed by bug 622247 初回投稿日時: 2012年02月22日10時37分34秒
    カテゴリ: Mozilla Core Mozilla13 TSF Windows バグ修正
    固定リンク: id=2012022200
    SNS: (list)

    TSFのコードが、compositionstart直後に、空の文字列を未確定文字として送信したい場合に、nsEditor側の実装の問題から、一度空では無い文字列(スペース一文字)を送信してから、空の文字列をあらため送信して、選択済みの文字列を削除するというハックを行っていたのですが、それを削除するバグです。

    このバグの修正で、Win、Mac、GTKの、widget vs. editorのハックは全て取り除いたはずです。

    今後の予定としては、XP部分でcompositionstartからcompositionendまでをひとつのトランザクションとして扱い、まずは一連のイベントが確実にcompositionstartを受け取ったエディタをターゲットとするように修正します。その後、GTKで色々と問題のある強制確定まわりの修正を行っていこうと考えています。

    2012年2月23日

    Bug-org 630813 Store the native modifier mask information in GdkKeymap's wrapper class and use it instead of GDK_MOD*_MASK 初回投稿日時: 2012年02月23日11時04分14秒
    最終更新日時: 2012年02月23日11時06分06秒
    カテゴリ: Mozilla Core Mozilla13 バグ修正
    固定リンク: id=2012022300
    SNS: (list)

    1年もかかってしまいましたが、ようやく大物がひとつ片付きました。Linuxのキーイベントの処理のうちのややこしい部分をnsWindowから分離しました。GtkKeymapのラッパーで、名前もそのままに、mozilla::widget::KeymapWrapperです。

    GDKでは、正体がよく分かってませんが、GdkDisplay単位でGdkKeymapを管理することができます。一応設計としては、そのような複数のGdkDisplayが存在する環境が当たり前になった場合にも対応できるようにはしていますが、今回の修正では簡略化のためにデフォルトのGdkDisplayのGdkKeymapに常にアクセスするようにしています(これは既存の動作のまま)。ですので、もし、この挙動で困る環境があって、修正すべきだと考えられるのであれば、バグを報告してもらって、利用シーンについて説明してもらえれれば対応可能だと思います。

    話がそれてしまいましたので戻します。今回の修正では主に、モディファイアキーの処理の改善を目的においていました。Xにおいて、モディファイアの定義というのは抽象化されすぎていて、GDKでは以下のような定数で定義されています。 

    typedef enum {
  GDK_SHIFT_MASK    = 1 << 0,
  GDK_LOCK_MASK	    = 1 << 1,
  GDK_CONTROL_MASK  = 1 << 2,
  GDK_MOD1_MASK	    = 1 << 3,
  GDK_MOD2_MASK	    = 1 << 4,
  GDK_MOD3_MASK	    = 1 << 5,
  GDK_MOD4_MASK	    = 1 << 6,
  GDK_MOD5_MASK	    = 1 << 7,
  GDK_BUTTON1_MASK  = 1 << 8,
  GDK_BUTTON2_MASK  = 1 << 9,
  GDK_BUTTON3_MASK  = 1 << 10,
  GDK_BUTTON4_MASK  = 1 << 11,
  GDK_BUTTON5_MASK  = 1 << 12,

  /* The next few modifiers are used by XKB, so we skip to the end.
   * Bits 15 - 25 are currently unused. Bit 29 is used internally.
   */
  
  GDK_SUPER_MASK    = 1 << 26,
  GDK_HYPER_MASK    = 1 << 27,
  GDK_META_MASK     = 1 << 28,
  
  GDK_RELEASE_MASK  = 1 << 30,

  GDK_MODIFIER_MASK = 0x5c001fff
} GdkModifierType;

    GDK_MOD1_MASKが慣例的にAltとなっていますが、NumLockに関しては定義されていません。

    さらに悩ましいことに、他のプラットフォームと違って、モディファイアとモディファイアキーが1対1の関係にはなく、ひとつの物理キーが複数のモディファイアの意味を持つことがあります。例えば、一般的なディストリビューションをインストールして、特にキーボードレイアウトを変更しないまま利用していると、Altキーは、Altにあたるモディファイアの状態を変更しますが、Alt+Shiftだと、モディファイアの状態変更はそのままに、Metaキーが押されたというイベントに変わってしまいます。このままでは他のプラットフォームでの挙動と整合性がとれません。

    今回の修正の一点目は、各物理キーが、どのモディファイアのビットを含んでいるのかを予め取得しておき、これをDOMキーイベントの挙動補正に利用するようになりました。以前説明したように、Linuxではアプリケーションがキーイベントを処理している段階では、モディファイアの状態はまだ変更されていませんので、モディファイアキーのkeydownイベントを送信する際には、その押されたキーのもつモディファイアも含めて反映するようになりました。keyupイベント時のモディファイア情報は今まで変わらず補正無しで、他のプラットフォームとは異なり、モディファイアの状態は実際には押されてなくても、DOMキーイベントでは押されたままとなっています。

    二点目は、モディファイアキーのDOMキーイベントのkeyCodeは他のモディファイアキーが押されていない状態でのキーを基に、算出されるようになりました。上記のように、Shift+Altで、DOM_VK_METAキーとなっていた環境でも、Altキーのみを押した場合と同様にDOM_VK_ALTキーがkeyCodeに設定されるようになりました。ただし、他のモディファイアキーとの組み合わせで初めてモディファイアキーになるような場合、例えば、JISキーボードレイアウトでは、標準設定のままだと、Shift+英数でCapsLockキーになります。このような場合に、keyCodeを英数キーのものにしてしまうと問題がありますので、CapsLockキーのkeyCodeをそのまま送信します。

    三点目は、全てのモディファイアキーを調べられるDOMイベントではこの新しいクラスでisShift、isControl、isAlt、isMetaを設定されるようになりました。これに伴い、isMetaの値がイベントの種類によってまちまちだった状況が改善され、常にfalseになっています。Metaという名前が悪いと思うのですが、これはMacではショートカットキーのコンビネーションで主に利用されるCommandキーが押された場合にtrueになりますので、Mac版でのみテストされたWebアプリケーションでは誤動作する可能性がありました。また、Macのこのキーは明らかにLinuxでのMetaキーとは異なっています。他のプラットフォームには存在せず、また重要ではないモディファイアがWebアプリから簡単に利用できても有害なのでこの情報はDOMイベントには反映されなくなりました。

    今回の修正で最も大きな成果は、アクティブなキーボードレイアウトの生存期間のみ生存しているインスタンスができたことです。これにより、今まではパフォーマンスを気にして細かく調べられなかったことを調べ、その結果をキャッシュしておくことが可能になりました。また、単純にnsWindowからの独立は機能を拡張しやすくなったことを意味しています。来週以降、このバグ待ちで止まっていたWindows、Mac、LinuxでのkeyCode算出ルールの統一化の作業を行っていきます。Webコンテンツ的には本来なら必要の無い話なのですが、keyCodeはchrome内のスクリプトにとっては変わらず重要な情報ですのでここを避けて通ることはできません。ですが、これが終わればいよいよこれらのプラットフォームで同時にD3EのKeyboardEventの各属性を順番に実装していく予定です。順調にいけば、来年リリースされる分ぐらいからは、FirefoxのキーボードイベントはD3E仕様をほぼ満たしたものになるのではないかと思います。

    2012年2月25日

    Bug-org 707859 sometimes fires mousemove event after dragstart 初回投稿日時: 2012年02月25日09時55分20秒
    カテゴリ: Mozilla Core Mozilla13 バグ修正
    固定リンク: id=2012022500
    SNS: (list)

    主にLinuxで、dragstartイベント後にmousemoveイベントが時々発生していたというバグです。安全策のパッチを入れるまでは、これが原因でツールチップがドラッグ中に表示されたりしていました。

    原因は、レイアウトに変更があった際に:hover状態の変更を行うため等にmousemoveイベントを内部で生成し、非同期で発火しています。この非同期というのがくせ者で、この間にdragstartが割り込むとmousemoveイベントがドラッグ中に発生していたわけです。

    実際にイベントを発火する際にドラッグが始まっているかどうか確認し、始まっていた場合はそのイベント自体を発火しないようにする、という形で修正しています。

    ただ、なぜWindowsでは一度も確認できず、Macでも一度しか確認できなかったのか、この頻度の差がよく分かっていません。タイマの実装の差とかによるものなのでしょうか?

    2012年2月28日

    Bug-org 730760 laying out and rendering shouldn't halt by <script> accessing another server for src attribute 初回投稿日時: 2012年02月28日12時44分26秒
    最終更新日時: 2012年02月28日15時37分26秒
    カテゴリ: Javascript Mozilla Core バグ原因判明 バグ報告
    固定リンク: id=2012022800
    SNS: (list)

    一部のページにアクセスした時に、別のサーバへの接続を開始すると、レイアウトやレンダリングが一時的に中断する、というバグです。前々からFlashの挙動を確認するのに使っていたページで発生していたのですが、一向に修正される気配がないので、どういうことか調べてもらうために報告しました。

    原因は、<body>の先頭付近にある、<script>で、応答な無いサーバにあるスクリプトを読み込もうとしていることにありました。

    WebKitでも現状では同様のようですが、その理由として、もし、そのスクリプトファイルの読み込み中に変数の宣言や初期化があり、次以降の<script>内でそれらを参照すると動作が壊れる、document.write("<!--");のようなことをされると、それ以降の意味が大きく変わってしまう、という問題があるため、そこで一度止めるしか今のところアイデアが無いそうです。

    Webアプリの開発者の方は、こういったことにならないように<script>要素での読み込みを非同期にすることで解決できます。非同期にするには、<script>要素に、async属性か、defer属性を記述してください。ただし、以下のようなことを行っている場合には、バグってしまいますので、そのようなスクリプトを非同期で読み込んではいけません。

    • scriptファイルの読み込み中にグローバルな変数を初期化し、それをそのscriptファイル以外の場所から参照している
    • document.write("foo");をスクリプトが読み込まれた時に実行している

    是非、Webページを作る方は、できる限り非同期で読み込むようにし、また、自身で設計する場合には、非同期読み込みにできなくなるような設計にならないように注意しておいてください。

    2012年2月29日

    Bug-org 728132 test_bug583533.html uses wrong const values 初回投稿日時: 2012年02月29日17時52分29秒
    カテゴリ: Mozilla Core Mozilla13 バグ修正
    固定リンク: id=2012022900
    SNS: (list)

    test_bug583533.htmlがui.key.contentAccessの値の意味を調べるときに、nsIDOMNSEvent.ALT_MASK、nsIDOMNSEvent.CONTROL_MASK、nsIDOMNSEvent.SHIFT_MASK、nsIDOMNSEvent.META_MASKを利用していたものの、Shiftキーと、Altキーのフラグは、この設定では逆になっていた、というバグです。

    もともと設定値はこれらの定数を意識したものではなかったので、思い込みでバグった例ですね。本来ならこのテストでは全組み合わせもテストしなくてはいけなかったのに、それを行っていないという点にも問題があります。

    このバグは、bug-org 728103のパッチを作成中に発見しました。Mac版のアクセスキーの仕様変更を行おうとしている重要なバグですので、意見のある方はお早めに。