この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
Bug-org 731878の修正時にMacOS X 10.6以降で利用可能なAPIを利用したことにより、10.5のSDKでビルドしようとすると失敗するというバグです。既に修正済みです。
D3EのKeyboardEvent.locationの実装です。ひとまず実装は終わりましたが、いくつか制限があります。
Windows、Mac、Linux以外のデスクトップ版では常にDOM_KEY_LOCATION_STANDARDが返されます。また、モバイル版ではPC用のキーボードを接続しても、常にDOM_KEY_LOCATION_MOBILEが返されます。
フルキーボードを利用している人には不自然ですが、NumLockキーは、DOM_KEY_LOCATION_STANDARDになります。
詳細についてはMDNにも記述していますので、そちらを参考してください。
Bug-org 166240の修正時に、Windowsだけネイティブキーイベントの処理部分の修正が一筋縄でいかなかったので、軽くリファクタリングしたのですが、それが仇となって、Tabキーと、ESCキーのkeypressイベントのkeyCodeが常にゼロになってしまうというバグが出てしまいました。
これにより、ダイアログがESCキーで閉じられない、Tabキーや、Shift+Tabキーでフォーカス移動できないといった分かりやすい症状が出たため、大量に重複バグが報告されました。重複バグを処理してくれた方々には感謝です。
こちらも、Bug-org 166240の修正によるregressionです。
パッチを見れば分かるように、単なるswitch文でのbreakの入れ忘れです。恥ずかしい。
AltキーのイベントがpreventDefault()で消費されてしまっていてもメニューバーが表示される、もしくはメニューバーにフォーカスが移動するというバグです。
この修正により、AltキーのkeydownかkeyupのどちらかでもpreventDefault()で消費されている場合、メニューバーの処理はキャンセルされるようになりました。ちなみに、Geckoではモディファイアキーはkeypressイベントを生成しません。
ネイティブイベントをハンドリング中ではない場合に発行するイベントにモディファイアをセットしなくてはいけない場合に、正しくセットできていないというバグです。
この修正10.6以降では、[NSEvent modifierFlags]を利用するようにし、10.5ではCarbon APIを引き続き利用するものの、その戻り値を正しくCarbonのモディファイアフラグからCocoaのモディファイアフラグに変換するようにしています。
このバグの修正でも引き続き、スクロール等による:hover状態の反映に利用されているsynthesized mousemoveイベントには、モディファイアが引き続き正しく設定されていません。これに関してはbug-org 749553を参照してください。
Keycode ReimplementationのWindows版です。
Gecko(というかほとんどのブラウザ)はキーイベントのkeyCodeの値に、Windowsのキーメッセージで与えられるvirtual keycodeと同じ値で定義しています。おそらくNetscapeあたりが最初に実装した時から、それを見よう見まねで各社が適当にそれっぽく動くようにしたのが原因だと思いますが、とにかく標準的なルールが全く無く、US ANSIキーボード以外での値がブラウザ間で互換がとれていなかったり、Geckoでもプラットフォームごとに値が違うことが多いという状況でした。
これを改善すべく、簡単なルールを決め、GeckoのWindows版、Mac版、Linux(GTK)版ではほぼ同じ挙動をとるように今回改善しています。
そのルールは全プラットフォーム版をMDNにも記述しましたが、こちらではWindowsに絞った内容で紹介しておきます。
Windowsではこれまで+を入力するキーと、-を入力するキー以外では、システムのvirtual keycodeをそのままDOMキーイベントのkeyCodeに設定していました。平たく言うと、何も考えずに垂れ流ししていたわけです。このままでは他のプラットフォームでは手詰まりに陥るのでWindowsでもきちんと対応するDOMキーコードを自身で定義しているか確認し、存在しない場合にはゼロとするようにしています。
Windowsではあまりキーコードが変化するキーはありませんが、Windowsキーには新たに専用のキーコードが割り当てられています。
JISキーボードの;+キーはDOM_VK_PLUSではなく、DOM_VK_SEMICOLONに変化しています。他の記号キーに関してもいくつか変わっている可能性はあります。ただ、元々文字を入力するキーのkeyCode値をkeydownもしくはkeyupイベントでチェックすべきではないので実際のWebアプリへの影響は限定的だと思います。
Keycode ReimplementationのMac版です。
Mac版は以下のルールでkeyCodeの値を決定します。
kTISPropertyInputSourceIsASCIICapableプロパティがtrueの場合)、DOMキーコードは0とするTISCopyCurrentASCIICapableKeyboardLayoutInputSource()で返されるキーボードレイアウト)で、そのキーがASCIIアルファベットか、ASCIIの数字を入力可能な場合、それにあったDOMキーコードを用いるASCIIアルファベットを直接入力できないキーボードレイアウトの場合(例えばアラビア語、ヘブライ語、キリル文字、タイ語等)がWindowsより複雑です。
Macの日本語版キーボードには英数キーが存在していますが、この挙動がことえりをはじめ、MacのIMEはかなキーと対になっています。ですが、かなキーにはDOMキーコードが割り当てられていますが、英数キーには割り当てられていなかったので、新たにDOM_KEY_EISUという値を定義してマッピングしています。ちなみに、動作が違うのでWindowsの英数キーはこのキーコードを返すようには修正していません。
Keycode ReimplemtationのLinux(GTK)版です。
Linux版のキーコードは以下のルールで決定されます。
GDK_aキーでASCIIアルファベットを入力できない場合)、システムにインストールされているキーボードレイアウトの中で、ASCIIアルファベットの入力可能な最も優先順位の高いキーボードレイアウトで、そのキーが単体でASCIIアルファベットかASCIIの数字が入力可能ならそれにあったDOMキーコードを用いる。それ以外の文字の場合にはShiftキーを押した場合についても確認するASCIIの文字や数字以外の場合の他のキーボードレイアウトを参照するタイミングがMacとは異なっていますが、よほど特殊なキーボードレイアウト同士の組み合わせでなければこれによる差はでないと思います(この差はレビュアの考え方の差)。
Xのキーボードに関する仕様が少しアレなので、他のプラットフォームに対して非常にややこしいルールになっているように見えますが、意外と他のプラットフォームと実際には変わりません。変わるとしたら、バリバリとカスタマイズしたキーボードレイアウトをユーザが自作した場合だと思います。
ちなみに、Linux(GTK)には明確にAltGrにあたるキーが存在しているので、DOM_KEY_ALTGRというキーコードが定義されて割り当てられています。
先ほど借りているサーバの業者から連絡があり、新しいサーバへの移転が終わったようです。PHP4からPHP5への移行や、MySQLのアップグレードによって、この日記に何らかのバグが発生してる可能性がありますので、何か見つけられましたらメールで連絡して頂ければ助かります。
Firefoxを12にアップグレードしてから日本語入力中にハングアップするという話がちょこちょこと耳に入ってきますが、bugzillaへのバグ報告は未だにゼロで、再現手順、再現環境は全く分かっていません。
そんな中、Fennecのタッチイベントのハンドラがコンテンツの内容を調査する際に無限ループに陥ってハングアップするバグが見つかり、修正されたことが分かりました。
この内容を調査している部分はIMEの入力中にはキャレット周辺のテキストをIMEに渡したり、変換候補ウインドウの表示位置を決めるために頻繁にアクセスします。また、バグの本当の原因は未だに分かっておらず、iteratorの返してくる値がおかしいので、それで無限ループが発生してしまうのを回避したように修正しただけです。このため、タッチイベントで発生するのがバグの報告にあるように14からであっても、12から隠れていた可能性があります。
このバグは既にAuroraで修正されていますので、どなたか再現する方はAuroraでテストしてみてもらえないでしょうか?
続報へ。
Bug-org 630810の修正によるWindows版のみのregressionです。
タイ語のキーボードレイアウトでは+はShift+1キーで入力できるのですが、このキーはVK_2が割り当てられていて、ANSI USキーボードレイアウトの=/+キーにあたる、ชキーにVK_OEM_PLUSが割り当てられていました。
Windowsのネイティブアプリケーションは仮想キーコードを元にショートカットキーを処理しているようで、IE9ではCtrl+ชでズームインできるようになっているので、これにあわせて、一部のキーコード向けに特殊処理を追加しました。
VK_OEM_PLUS、VK_OEM_COMMA、VK_OEM_MINUS、VK_OEM_PERIODキーはレイアウトに関係無く、+、,、-、.キーにあたるとMSDNで定義されていますので、これらのキーが押された場合、そのキーがショートカットキーとして処理されるべきである文字候補のリストの末尾にこの文字を追加するようにしました。ただし、その文字がそのキーによって入力できる場合は従来までと処理の変更はありません。
これは他のプラットフォームのGeckoとは異なる処理ですが、プラットフォームのネイティブアプリケーションのマナーに従うことを優先しています。
Bug-org 677252の修正によるregressionです。
デッドキーで文字を入力した時に、アクセント記号とベース文字が適当な組み合わせではない場合、アクセント記号とベース文字、二文字として確定されます。
このケースの場合、Cocoaでは、insertTextが一文字ずつ2回呼び出され、二回目のキーのkeyDownで渡されたイベントには二文字とも入っている、という不思議な状態になります。
原因となった修正ではkeypressイベントの初期化を一カ所にまとめた際に、それまでのコードに従ってキーイベントの一文字目をkeypressイベントのcharCodeに設定するようにしたため、'sと入力したい場合に'と'と入力されてしまうことになっていました。
修正方法は悩んだのですが、keypressイベントの初期化時に予めcharCode値が入っていた場合はその文字の入力イベントを初期化しろという指示だと受け取るように書き換えました。
Bug-org 758420の修正によるregressionです。
keypressイベントの初期化を一手に行うメソッドが意図せずcharCodeを上書きしてしまわないようにassertionを埋め込んでいたのですがその条件を間違えていて常に出力されてしまってました。