もずはっく日記(2010年12月)

Bug-org 261715 Alt+click sometimes focuses menubar (keyrepeated Alt shouldn't trigger menubar focusing behavior) 初回投稿日時: 2010年12月04日15時34分48秒
最終更新日時: 2010年12月05日01時06分37秒
カテゴリ: Firefox Mozilla Core バグ修正
固定リンク: id=2010120400
SNS: Tweet (list)

Altキーを押しながらドラッグすると、Altキーを離した時にメニューバーにフォーカスが移る、もしくは非表示だったメニューバーが表示されてしまうというバグです。

あまり知られていないようですが、GeckoはAltキーを押しながらだと、リンクの中のテキストから文字列の選択を開始することができます(Firefox側にバグがあって、リンク内でマウスのボタンを離すと保存ダイアログが出てしまいますが)。これを行おうとすると、Fx4からはデフォルトで非表示になったメニューバーが表示されてしまって表示がばたついてしまうので、修正を入れました。

レビュー中に分かったのですが、どうもWindowsではAltキーを押している時に自動リピートがあるかどうかは、キーボードのドライバに依存するようです。私のPCではリピートするので、このバグが再現していましたが、そうではないPCの場合はもともと再現していなかったはずです。

今まではbooleanの変数一つで管理していたAltキーの押下状態を、マウスクリック時にキャンセルするのではなく、キャンセルされたという別のフラグを立てることで、リピートでやってきたkeydownイベントで、キャンセルされたことがキャンセルされないように修正しています。

Bug-org 616797 Menu bar does not appear by Alt key 初回投稿日時: 2010年12月10日04時21分36秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010121000
SNS: Tweet (list)

例によって、Aliceさんによる迅速なregression報告。ニーモニックを利用してメニューを開いた後(例えば、Alt+F)、マウスを使ってメニューを閉じると、Altキーでメニューバーにフォーカスが移動しない、というバグです。

それにしても、よくこんなケース見つけましたね、すごいです。

DOMのkeydownとkeyupイベントのkeyCodeの値 初回投稿日時: 2010年12月10日05時03分17秒
カテゴリ: Javascript Mozilla Core 雑談
固定リンク: id=2010121001
SNS: Tweet (list)

DevConでも質問が出ていたこの問題、あれから調べ続けてますが、とりあえず同じGeckoでもOSごとにかなり処理がバラバラで、駄目なことが分かりました。Fx4に向けてあまりいじる訳にもいかないと思うので、betaの遅れ具合と他に抱えてるブロッカーバグの進捗との相談になってきますが、徐々に修正していこうかと計画しています。

まず必要だと思われるのは、ASCII文字は全て固有のkeyCode値を定義しなくてはいけないと思われます(この時点でもう現在のtrunkでは正攻法では修正不可ではありますが)。DOM3の仕様案では、keyCodeはモディファイアキーを押していない状態で入力される文字から算出するべきであるという指針が提案されています。これは非常に良いアイデアだと思いますので採用すべきでしょう。現に、現在のGeckoは基本的にはこの考え方で設計されています(考え方が、というだけで、一部のキーはそうではありませんし、USのキーボードレイアウト以外では無茶苦茶ですが)。それに対して、Unicode文字を入力してしまうキー、例えばàのようなキーは0を返すしかないでしょう。

ただし、馬鹿正直にモディファイアキー無しのキーの入力文字からキーコードを算出すると、キリルとかギリシャあたりのレイアウトでは使い物にならなくなります(Linux版のGeckoなんかはそうなんですが)。これを回避するために、ハッキーな方法ですが、算出した文字がUnicode文字だった場合、USキーボードレイアウトでAにあたるキーでASCII文字が入力できるキーボードレイアウトを探して、そのレイアウトから算出したキーコードをセットすべきだと考えています。問題点としてすぐに考えられるのは、複数のキーが同じキーコードを返す可能性がある点です。例えば、ギリシャ文字を入力するキーボードレイアウトで入力できるASCII文字の記号のキーが、共にインストールしているASCII文字用のキーボードレイアウトの記号の位置と異なる場合、重なってしまう可能性があります。常にASCII文字入力用のレイアウトからのみ算出されたキーコードを使えばこのようなことはありませんが、それはそれで利用者の直感には反しそうに思います。

また、フランス語用のAZERTY配列に関してはやはり特殊な処理が必要だと考えています。AZERTY配列では数字はShiftキーと共に入力することになります。しかし、他のレイアウトを前提にしたWebアプリでの利用シーンを考えると、Shiftキー押下時の入力文字が数字なのであれば、数字キーとしてのキーコードをルールに反して返すべきではないかと考えています。

最後に、参考までにGeckoのキーイベントで定義されている定数の定義している場所を示しておきます: http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/events/nsIDOMKeyEvent.idl ここで定義されている定数はkeydownイベントハンドラ等で渡されたイベントから参照できます。例えば、event.DOM_VK_CANCELと記述します。

Bug-org 608721 Next character of U+3001 or U+3002 should break line even if it is "[" 初回投稿日時: 2010年12月17日18時13分38秒
カテゴリ: Mozilla Core バグ修正
固定リンク: id=2010121700
SNS: Tweet (list)

誠さんに見つけられてしまった、日本語の句読点の直後に開き括弧が来ても、その間で改行されない、というバグです。

もともと、Bug-org 389056の修正時に設計段階でかなり試行錯誤していましたが、その時に何度も文字のクラスが追加されていきました。とある時点で「前で改行してはいけない記号」と、「必要であれば前で改行しない開き括弧」の組み合わせでも改行を行わないようにしておかないといけないケースが見つかりました(たぶん顔文字)。その後、文字クラスをいくつか追加して、単語の端から「近すぎる場所」では改行しないという特殊ルールが考案されて、上記の組み合わせでは改行しても何の問題も無くなっていました。しかし、それに気付かず改行を禁止したまま、ここまで放置されてしまっていた、という形です。

ちょっとタイミングとしては怖い、リスキーな修正だと思いますが、思いがけずrocがapprovalを出してくれたので修正が完了してしまいました。

Bug-org 543789 Implement DOM3 composition events and text event 初回投稿日時: 2010年12月19日06時47分29秒
カテゴリ: Mozilla Core バグ検証中
固定リンク: id=2010121900
SNS: Tweet (list)

Firefox 4の後に実装すべく、検討を始めてますがやはり仕様書がまだまだ雑でどうしたもんか、という感じです。