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

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

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

2012年5月10日

Bug-org 166240 Implement D3E KeyboardEvent.location (except JOYSTICK) 初回投稿日時: 2012年05月10日08時50分03秒
カテゴリ: Mozilla Core Mozilla15 バグ修正
固定リンク: id=2012051001
リンク元: 0件
SNS: (list)

D3EKeyboardEvent.locationの実装です。ひとまず実装は終わりましたが、いくつか制限があります。

Windows、Mac、Linux以外のデスクトップ版では常にDOM_KEY_LOCATION_STANDARDが返されます。また、モバイル版ではPC用のキーボードを接続しても、常にDOM_KEY_LOCATION_MOBILEが返されます。

フルキーボードを利用している人には不自然ですが、NumLockキーは、DOM_KEY_LOCATION_STANDARDになります。

詳細についてはMDNにも記述していますので、そちらを参考してください。

Bug-org 751881 keyCode of keypress event for Tab key and ESC key is broken on Windows 初回投稿日時: 2012年05月10日09時00分29秒
最終更新日時: 2012年05月10日09時02分09秒
カテゴリ: Mozilla Core Mozilla15 バグ修正
固定リンク: id=2012051002
リンク元: 0件
SNS: (list)

Bug-org 166240の修正時に、Windowsだけネイティブキーイベントの処理部分の修正が一筋縄でいかなかったので、軽くリファクタリングしたのですが、それが仇となって、Tabキーと、ESCキーのkeypressイベントのkeyCodeが常にゼロになってしまうというバグが出てしまいました。

これにより、ダイアログがESCキーで閉じられない、Tabキーや、Shift+Tabキーでフォーカス移動できないといった分かりやすい症状が出たため、大量に重複バグが報告されました。重複バグを処理してくれた方々には感謝です。

2012年5月11日

Bug-org 749563 Consumed Alt key (i.e., preventDefault() is called) causes to activate menubar 初回投稿日時: 2012年05月11日09時47分12秒
カテゴリ: Firefox Mozilla Core Mozilla15 SeaMonkey Thunderbird バグ修正
固定リンク: id=2012051100
リンク元: 0件
SNS: (list)

AltキーのイベントがpreventDefault()で消費されてしまっていてもメニューバーが表示される、もしくはメニューバーにフォーカスが移動するというバグです。

この修正により、AltキーのkeydownkeyupのどちらかでもpreventDefault()で消費されている場合、メニューバーの処理はキャンセルされるようになりました。ちなみに、Geckoではモディファイアキーはkeypressイベントを生成しません。

2012年5月24日

Bug-org 753256 Cocoa widget shouldn't use GetCurrentKeyModifiers() directly 初回投稿日時: 2012年05月24日13時05分16秒
カテゴリ: Mozilla Core Mozilla15 バグ修正
固定リンク: id=2012052400
リンク元: 0件
SNS: (list)

ネイティブイベントをハンドリング中ではない場合に発行するイベントにモディファイアをセットしなくてはいけない場合に、正しくセットできていないというバグです。

この修正10.6以降では、[NSEvent modifierFlags]を利用するようにし、10.5ではCarbon APIを引き続き利用するものの、その戻り値を正しくCarbonのモディファイアフラグからCocoaのモディファイアフラグに変換するようにしています。

このバグの修正でも引き続き、スクロール等による:hover状態の反映に利用されているsynthesized mousemoveイベントには、モディファイアが引き続き正しく設定されていません。これに関してはbug-org 749553を参照してください。

Bug-org 630810 Should convert from native keycode to DOM keycode for every keys on Windows 初回投稿日時: 2012年05月24日13時26分39秒
カテゴリ: Mozilla Core Mozilla15 バグ修正
固定リンク: id=2012052401
リンク元: 0件
SNS: (list)

Keycode ReimplementationのWindows版です。

Gecko(というかほとんどのブラウザ)はキーイベントのkeyCodeの値に、Windowsのキーメッセージで与えられるvirtual keycodeと同じ値で定義しています。おそらくNetscapeあたりが最初に実装した時から、それを見よう見まねで各社が適当にそれっぽく動くようにしたのが原因だと思いますが、とにかく標準的なルールが全く無く、US ANSIキーボード以外での値がブラウザ間で互換がとれていなかったり、Geckoでもプラットフォームごとに値が違うことが多いという状況でした。

これを改善すべく、簡単なルールを決め、GeckoのWindows版、Mac版、Linux(GTK)版ではほぼ同じ挙動をとるように今回改善しています。

そのルールは全プラットフォーム版をMDNにも記述しましたが、こちらではWindowsに絞った内容で紹介しておきます。

  1. Windowsではvirtual keycodeがAからZか、0から9のキーに対しては、これに対応したDOMキーコード(これに関してはそのままの値)を使用する
  2. それ以外の文字を入力するキーでは、そのキーで入力される文字がASCII文字の場合、それにあったキーコードを利用する
  3. もしその文字がASCII文字ではないものの、Shiftキーを押しながらだとASCII文字を入力できる場合、それにあったキーコードを利用する
  4. それ以外のキーに関してはそのキーにあったキーコードが利用される
  5. 上記ルールで対応するキーコードが求められない場合は0とする

Windowsではこれまで+を入力するキーと、-を入力するキー以外では、システムのvirtual keycodeをそのままDOMキーイベントのkeyCodeに設定していました。平たく言うと、何も考えずに垂れ流ししていたわけです。このままでは他のプラットフォームでは手詰まりに陥るのでWindowsでもきちんと対応するDOMキーコードを自身で定義しているか確認し、存在しない場合にはゼロとするようにしています。

Windowsではあまりキーコードが変化するキーはありませんが、Windowsキーには新たに専用のキーコードが割り当てられています。

JISキーボードの;+キーはDOM_VK_PLUSではなく、DOM_VK_SEMICOLONに変化しています。他の記号キーに関してもいくつか変わっている可能性はあります。ただ、元々文字を入力するキーのkeyCode値をkeydownもしくはkeyupイベントでチェックすべきではないので実際のWebアプリへの影響は限定的だと思います。

Bug-org 677252 Reimplement keycode computation in cocoa widget 初回投稿日時: 2012年05月24日13時47分31秒
最終更新日時: 2012年05月24日13時53分26秒
カテゴリ: Mozilla15 バグ修正
固定リンク: id=2012052402
リンク元: 0件
SNS: (list)

Keycode ReimplementationのMac版です。

Mac版は以下のルールでkeyCodeの値を決定します。

  1. 文字入力のためのキーでは無い場合、Macのネイティブイベントのキーコードから対応するキーのDOMキーコードを用いる
  2. Macのネイティブイベントのキーコードが0から9のキーであることを示す場合、これに対応したDOMキーコードを用いる
  3. それ以外の文字入力可能なキーの場合、shiftキー、optionキー無しで入力される文字がASCII文字ならそれにあったDOMキーコードを用いる
  4. もし、その文字がASCII文字ではなかった場合、shiftキーを押した際に入力される文字がASCII文字ならそれにあったDOMキーコードを用いる
  5. もし、そのキーボードレイアウトがASCIIアルファベットを入力可能なレイアウトだった場合(具体的に言うと、kTISPropertyInputSourceIsASCIICapableプロパティがtrueの場合)、DOMキーコードは0とする
  6. それ以外の場合、その時のASCIIアルファベット入力可能なキーボードレイアウト(具体的に言うとTISCopyCurrentASCIICapableKeyboardLayoutInputSource()で返されるキーボードレイアウト)で、そのキーがASCIIアルファベットか、ASCIIの数字を入力可能な場合、それにあったDOMキーコードを用いる
  7. それ以外の場合は0とする

ASCIIアルファベットを直接入力できないキーボードレイアウトの場合(例えばアラビア語、ヘブライ語、キリル文字、タイ語等)がWindowsより複雑です。

Macの日本語版キーボードには英数キーが存在していますが、この挙動がことえりをはじめ、MacのIMEはかなキーと対になっています。ですが、かなキーにはDOMキーコードが割り当てられていますが、英数キーには割り当てられていなかったので、新たにDOM_KEY_EISUという値を定義してマッピングしています。ちなみに、動作が違うのでWindowsの英数キーはこのキーコードを返すようには修正していません。

Bug-org 447757 Up to half the keyCode assignments in keyup/keydown events are missing or wrong 初回投稿日時: 2012年05月24日14時30分38秒
カテゴリ: Mozilla Core Mozilla15 バグ修正
固定リンク: id=2012052403
リンク元: 0件
SNS: (list)

Keycode ReimplemtationのLinux(GTK)版です。

Linux版のキーコードは以下のルールで決定されます。

  1. GDKキーイベントのキーコードがモディファイアキーの場合、他にモディファイアキーが押されていないか、単体でそのキーを押した場合に別のモディファイアキーには変化しないなら、そのモディファイアキーのDOMキーコードを用いる。もし、単体で押した時に別のモディファイアキーとして動作するのであれば、単体で押した時のモディファイアキーにあわせたDOMキーコードを用いる
  2. 文字入力キーではない場合、そのキーを単体で押した時の機能に対応したDOMキーコードを用いる。もしこの結果が0であれば、現在のGDKキーイベントで与えられたキーコードからDOMキーコードを求める(つまりモディファイアキーで変化した機能からDOMキーコードを求める)
  3. 文字入力キーの場合、そのキー単体で入力される文字がASCIIアルファベットか、ASCIIの数字の場合、それにあったDOMキーコードを用いる
  4. それ以外の場合、そのキーとShiftキーで入力される文字がASCIIアルファベットか、ASCIIの数字の場合、それにあったDOMキーコードを用いる
  5. それ以外の場合かつ、現在のキーボードレイアウトではASCIIアルファベットが入力できない場合(具体的にはGDK_aキーでASCIIアルファベットを入力できない場合)、システムにインストールされているキーボードレイアウトの中で、ASCIIアルファベットの入力可能な最も優先順位の高いキーボードレイアウトで、そのキーが単体でASCIIアルファベットかASCIIの数字が入力可能ならそれにあったDOMキーコードを用いる。それ以外の文字の場合にはShiftキーを押した場合についても確認する
  6. それ以外の場合、現在のキーボードレイアウトで、そのキーが単体でASCII文字を入力できる場合はそれにあったDOMキーコードを用いる
  7. それ以外の場合、現在のキーボードレイアウトで、そのキーがShiftキーが押されている場合にASCII文字を入力できる場合はそれにあったDOMキーコードを用いる
  8. それ以外の場合、0

ASCIIの文字や数字以外の場合の他のキーボードレイアウトを参照するタイミングがMacとは異なっていますが、よほど特殊なキーボードレイアウト同士の組み合わせでなければこれによる差はでないと思います(この差はレビュアの考え方の差)。

Xのキーボードに関する仕様が少しアレなので、他のプラットフォームに対して非常にややこしいルールになっているように見えますが、意外と他のプラットフォームと実際には変わりません。変わるとしたら、バリバリとカスタマイズしたキーボードレイアウトをユーザが自作した場合だと思います。

ちなみに、Linux(GTK)には明確にAltGrにあたるキーが存在しているので、DOM_KEY_ALTGRというキーコードが定義されて割り当てられています。

2012年5月29日

サーバ移行 初回投稿日時: 2012年05月29日14時31分50秒
カテゴリ: 雑談
固定リンク: id=2012052900
リンク元: 0件
SNS: (list)

先ほど借りているサーバの業者から連絡があり、新しいサーバへの移転が終わったようです。PHP4からPHP5への移行や、MySQLのアップグレードによって、この日記に何らかのバグが発生してる可能性がありますので、何か見つけられましたらメールで連絡して頂ければ助かります。

2012年5月30日

Firefox12にアップグレード後に日本語入力中にハングアップする方、テストしてもらえますか? 初回投稿日時: 2012年05月30日11時21分21秒
最終更新日時: 2012年06月07日10時26分11秒
カテゴリ: Firefox Mozilla Core Mozilla12 Windows バグ検証中
固定リンク: id=2012053000
リンク元: 1件
SNS: (list)

Firefoxを12にアップグレードしてから日本語入力中にハングアップするという話がちょこちょこと耳に入ってきますが、bugzillaへのバグ報告は未だにゼロで、再現手順、再現環境は全く分かっていません。

そんな中、Fennecのタッチイベントのハンドラがコンテンツの内容を調査する際に無限ループに陥ってハングアップするバグが見つかり、修正されたことが分かりました。

この内容を調査している部分はIMEの入力中にはキャレット周辺のテキストをIMEに渡したり、変換候補ウインドウの表示位置を決めるために頻繁にアクセスします。また、バグの本当の原因は未だに分かっておらず、iteratorの返してくる値がおかしいので、それで無限ループが発生してしまうのを回避したように修正しただけです。このため、タッチイベントで発生するのがバグの報告にあるように14からであっても、12から隠れていた可能性があります。

このバグは既にAuroraで修正されていますので、どなたか再現する方はAuroraでテストしてみてもらえないでしょうか?

続報へ

2012年5月31日

Bug-org 759346 Ctrl+ช (The key is '+/=' key on ANSI keyboard layout) doesn't work as Ctrl++ but work as so on IE 初回投稿日時: 2012年05月31日20時58分45秒
カテゴリ: Events Firefox Mozilla Core Mozilla15 Windows バグ修正
固定リンク: id=2012053100
リンク元: 0件
SNS: (list)

Bug-org 630810の修正によるWindows版のみのregressionです。

タイ語のキーボードレイアウトでは+Shift+1キーで入力できるのですが、このキーはVK_2が割り当てられていて、ANSI USキーボードレイアウトの=/+キーにあたる、キーにVK_OEM_PLUSが割り当てられていました。

Windowsのネイティブアプリケーションは仮想キーコードを元にショートカットキーを処理しているようで、IE9ではCtrl+でズームインできるようになっているので、これにあわせて、一部のキーコード向けに特殊処理を追加しました。

VK_OEM_PLUSVK_OEM_COMMAVK_OEM_MINUSVK_OEM_PERIODキーはレイアウトに関係無く、+,-.キーにあたるとMSDNで定義されていますので、これらのキーが押された場合、そのキーがショートカットキーとして処理されるべきである文字候補のリストの末尾にこの文字を追加するようにしました。ただし、その文字がそのキーによって入力できる場合は従来までと処理の変更はありません。

これは他のプラットフォームのGeckoとは異なる処理ですが、プラットフォームのネイティブアプリケーションのマナーに従うことを優先しています。

Bug-org 758420 Apostrophe followed by a letter creates two apostrophes 初回投稿日時: 2012年05月31日21時12分31秒
カテゴリ: Mac Mozilla Core Mozilla15 バグ修正
固定リンク: id=2012053101
リンク元: 0件
SNS: (list)

Bug-org 677252の修正によるregressionです。

デッドキーで文字を入力した時に、アクセント記号とベース文字が適当な組み合わせではない場合、アクセント記号とベース文字、二文字として確定されます。

このケースの場合、Cocoaでは、insertTextが一文字ずつ2回呼び出され、二回目のキーのkeyDownで渡されたイベントには二文字とも入っている、という不思議な状態になります。

原因となった修正ではkeypressイベントの初期化を一カ所にまとめた際に、それまでのコードに従ってキーイベントの一文字目をkeypressイベントのcharCodeに設定するようにしたため、'sと入力したい場合に''と入力されてしまうことになっていました。

修正方法は悩んだのですが、keypressイベントの初期化時に予めcharCode値が入っていた場合はその文字の入力イベントを初期化しろという指示だと受け取るように書き換えました。

Bug-org 759524 ASSERTION: aKeyEvent.charCode is modified unexpectedly 初回投稿日時: 2012年05月31日21時15分52秒
カテゴリ: Mac Mozilla Core Mozilla15 バグ修正
固定リンク: id=2012053102
リンク元: 0件
SNS: (list)

Bug-org 758420の修正によるregressionです。

keypressイベントの初期化を一手に行うメソッドが意図せずcharCodeを上書きしてしまわないようにassertionを埋め込んでいたのですがその条件を間違えていて常に出力されてしまってました。