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

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

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

2012年7月11日

Bug-org 537230 Modifying spellchecked text may lead to discontinuity in the misspelling marker 初回投稿日時: 2012年07月11日21時29分23秒
最終更新日時: 2012年07月11日21時33分43秒
カテゴリ: CSS Mozilla Core Mozilla16 バグ修正
固定リンク: id=2012071100
リンク元: 0件
SNS: (list)

ころっと修正するのを忘れていたバグです。昨年、text-decoration-styleを実装しましたが、複雑なスタイルを指定した要素同士が隣接している時に、なめらかに接続して描画されないというバグです。

例えば、今までは波線を指定したインライン要素が連続すると、以下のようになっていました。

Firefox 15までの連続した波線のレンダリング

これは、要素ごとに波線の同じ場所から描き始めていたためです。

これが、Firefox 16以降では、以下のようにレンダリングされます。

Firefox 16からの連続した波線のレンダリング

このようにレンダリング可能になったのは、まず、描画すべき領域だけをクリッピングした後に、祖先のブロック要素を探して、そのブロック要素の左端から続いて描かれてきたように描画するようになっています。

text-shadowでは当然、位置をずらさなかった場合のレンダリング結果を、指定されたオフセット分、ずらしてレンダリングするようにしています。

また、インライン要素がposition: relative;でずらされた場合にも、ずれる前の位置での描画イメージのまま、ずらして表示するようになっています。

同じ処理は、dotteddashedにも行われていますので、暇な方は試してみてください。波線ほどは分かりやすくないですけど。

Bug-org 768736 Define constants of native virtual keycodes for nsIDOMWindowUtils::SendNativeKeyEvent() users 初回投稿日時: 2012年07月11日23時02分59秒
カテゴリ: Mozilla Core Mozilla16 バグ修正
固定リンク: id=2012071101
リンク元: 0件
SNS: (list)

nsIDOMWindowUtils::SendNativeKeyEvent()をテストで呼び出す際に、ネイティブのキーコードを指定しないといけないのですが、10進数や、16進数、入り乱れて記述されていますし、プラットフォームごとに値が異なるわけです。そのため、書くのも面倒なら、読んでも分からないという状況でした。

この修正では、testing/mochitest/tests/SimpleTest/NativeKeyCodes.jsにWindowsとMacのSDKで定義されている全てのキーコードをJavascriptで再定義してますので、テストを書く際にはこれを利用してください。

ちなみに、アドオンからは参照できませんし、アドオンはこんなAPI使っちゃいけません。

Bug-org 769190 Should change the acceptable value of the argument of getModifierState() 初回投稿日時: 2012年07月11日23時11分22秒
最終更新日時: 2012年07月11日23時11分46秒
カテゴリ: IE Javascript Mozilla Core Mozilla15 Mozilla16 バグ修正
固定リンク: id=2012071102
リンク元: 0件
SNS: (list)

先日、Firefox 15でKeyboardEvent.getModifierState()と、MouseEvent.getModifierState()を実装しましたが、そのパラメータのモディファイアキーの名前が、最新のDOM Level 3 Eventsのドラフトで変更されてしまいました。このバグは、それにあわせて修正しようというものです。

変わったキー名は二つで、"Scroll"が、"ScrollLock"に、"Win"が、"OS"になりました。

もちろん、既にリリースされているIE9では、"Scroll"と、"Win"で動作しますが、Geckoではこれらのキー名を引数に渡しても、常にfalseが返るようになっています。

IE9と互換性を持たせつつ、これらのキーの状態を調べたい場合は、

if (event.getModifierState("ScrollLock") || event.getModifierState("Scroll")) {
  // in case ScrollLock is locked
}

としたり、

if (event.getModifierState("OS") || event.getModifierState("Win")) {
  // in case Win key is pressed
}

とすることができます。文字列でキー名を指定するというのは効率は良くないですけど、変化の激しいWebの仕様としては好ましいかもしれません。

Bug-org 713052 disable alt+click or alt+enter to save links by default (with a hidden preference to re-enable) 初回投稿日時: 2012年07月11日23時21分51秒
カテゴリ: Firefox Mozilla13 バグ修正 雑談
固定リンク: id=2012071103
リンク元: 2件
SNS: (list)

Firefox Inputを見ていると、時々、Firefox 13から、Alt+クリックでリンク先を保存できなくなったという苦情を見かけましたが、このバグがその修正を行ったバグのようです。

ざっと読んでみても、イマイチ、具体的に修正したかった理由(特に根拠)がよく分からないのですが、既にデフォルトの動作は変わってしまったので、それなりにがんばらないと、元の動作に戻したくても戻らないと思います。

自分の環境でのみ、動作を昔の状態に戻したい場合、about:configから、browser.altClickSaveの値を、trueに変更すれば、リンク先を保存する動作に戻るようです。

ただ、動作を元に戻すと、昔からあるバグですが、Alt+ ドラッグで、リンク内のテキストを(リンク先に飛ばずに)選択する、ということができませんので、どちらの機能を優先した方が得なのかを考えてみた方が良いかと思います。

Bug-org 764285 Use virtual keycodes in SDK for Mac instead of defined by ourselves 初回投稿日時: 2012年07月11日23時27分24秒
カテゴリ: Mozilla Core Mozilla16 バグ修正
固定リンク: id=2012071104
リンク元: 0件
SNS: (list)

GeckoのCocoaのwidgetのコードは、自分で仮想キーコードを定義して、それを利用していましたが、実際にはCarbon用のヘッダが、私たちも知らないキーも含めて定義していることを発見しました。そこで、自分達で定義するのはやめて、これを利用しようというのバグです。

ちなみに、Carbon用のヘッダでも定義されてなかったキーに関しては、命名規則を揃えて、今までと同様に定義しています。

2012年7月26日

Bug-org 751749 cannot configure keyboard shortcuts to use Meta modifier instead of Alt 初回投稿日時: 2012年07月26日09時37分18秒
最終更新日時: 2012年07月26日09時56分11秒
カテゴリ: GTK Mozilla Core Mozilla17 バグ修正
固定リンク: id=2012072600
リンク元: 0件
SNS: (list)

Bug-org 630813によるregressionです。

Bug-org 630813では、Linuxでは現在、Meta一般的ではないので、DOM KeyboardEventからは、Metaキーのイベントを参照できるべきではないとの判断で、押されたキーが、モディファイアキー無しで押された場合に、そのキーがGDK_Meta_(L|R)を生成する場合であっても、DOM_VK_METAを生成しないようにし、さらに、KeyboardEvent.metaKeytrueを返さないように修正を行いました。

しかし、実際にBug-org 630813が入ったビルド(Fx13)がリリースされると、一部、特殊なキーボードを利用しているユーザを中心にバグ報告がありました。その内容は、Sunや、MacのキーボードをLinuxで利用した場合、従来まではDOMイベントで、Metaキーとして扱われていたもの(つまり、そのキーと一緒に押したキーのイベントで、metaKeytrueとなるモディファイアキー)が、モディファイアキーとして機能しなくなったというもので、この現象自体がこのバグの修正対象です。

Bug-org 630813の修正内容を理解しなければ、このバグの理由、修正方法が理解できないので、再度説明しておきます。

Bug-org 630813で問題としたのは、ネイティブのモディファイアフラグと、DOMのモディファイアとの関係が、そのモディファイアフラグをアクティブにするキーとの関係と一致していない事でした。

Linuxのツールキット、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では、SuperHyperMetaについても定義があるのですが、新しいものですので、現在のGeckoでは無視しています。

それを踏まえてこのenumを見てみると、ShiftCapsLockCtrlキー以外のモディファイアに対するモディファイアフラグは、1から5が用意されているだけです。現に、GDK_Alt_(L|R)GDK_Meta_(L|R)GDK_Super_(L|R)GDK_Hyper_(L|R)GDK_Num_LockGDK_Scroll_Lockを生成するキーと、モディファイアフラグとの関係性は一定ではありません。極端な話、UbuntuやFedoraに付属しているキーボードレイアウトの設定から、設定をいじるだけで関係がずれてしまいます。

そこで、Geckoは、DOM Level3 EventsのKeyboardEventに対応するため、XのAPIを利用して、各フラグをアクティブにする物理キーが生成するGDKのkeyval値(上の例だと、GDK_Alt_L等)から各フラグがアクティブにする、DOMのモディファイアとの関係を初期化時に決定することにしました。

そのロジックは、基本的には、モディファイアフラグをアクティブにするキーが生成する可能性のある全てのkeyval値に対応する、DOMのモディファイアを同時にアクティブにするというもので、さらに、GDK_Meta_(L|R)は、DOMのMetaはアクティブにしないという(今、考えてみると)バグも混入されました。

ちなみに、それ以前は、MOD1が、AltMOD5が、Metaキーであるという慣例に従って、決め打ちを行っていました。

この事実と、前述の修正内容の結果、MOD5をアクティブにするキーが単独で押された場合に生成されるkeyvalGDK_Meta_(L|R)GDK_Super_(L|R)GDK_Hyper_(L|R)だった場合に、そのキーがショートカットキーや、アクセスキーのためのモディファイアキーとして機能しなくなってしまっていました(SuperHyperWinキーとして読み替えられ、osモディファイアだと扱われますが、osモディファイア自体が、ショートカットキーや、アクセスキーのモディファイアとして利用ができないため、Metaキー以外の場合にも影響が出ました)。

この問題を修正するために、このバグでは以下のアプローチをとりました。

  • DOMのMetaキーを復活
  • XULの<key>要素は簡単に指定すると、全てのモディファイアの状態がマッチしていないと動作しないので、ひとつのモディファイアフラグが、ひとつのDOMモディファイアしかアクティブにしないように修正
  • MOD5をアクティブにしていたキーが、Super、もしくはHyperの場合にも、ショートカットキーや、アクセスキーのモディファイアキーとして利用できるようにXULの<key>要素のmodifiers属性で、osを指定できるように修正

このような修正ですので、このバグで困っていた人は、ui.key.accelKeyの設定を変えなくては依然として、期待通りに利用できない可能性があります。

ui.key.accelKeyの値は新たに、DOM_VK_WINを意味する、91が指定可能になりました。

ui.key.chromeAccessと、ui.key.contentAccessは、16をOR演算で含めることができるようになりました。

Bug-org 773651 on windows XP KeyboardEvent.location for CTRL keys is always set to DOM_KEY_LOCATION_LEFT 初回投稿日時: 2012年07月26日10時41分21秒
カテゴリ: Mozilla Core Mozilla17 Windows バグ修正
固定リンク: id=2012072601
リンク元: 0件
SNS: (list)

Windows XP(と、Windows Server 2003)では、Ctrlキーや、Altキーを押したときに、常にKeyboardEvent.locationに、KeyboardEvent.DOM_KEY_LOCATION_LEFTがセットされているというバグです。

原因はMapVirtualKeyEx() APIはVista以降で完璧に動くようになったのを失念してのミスでした。

Windowsでは物理キーの情報は、scan codeの値と、extended keyであるか否か、この二つの情報から判断しなくてはいけません。一般的なキーボードの、矢印キー、Insert等の六個のキー、そして右Ctrlと、右Altキーがextended keyです。

Windowsのキーメッセージは、左右の区別のつかない、VK_CONTROLと、VK_MENUで通知されるので、KeyboardEvent.locationの実装のためには、MapVirtualKeyEx() APIを利用して、キーメッセージで同時に通知されている、scan codeと、extended keyか否かの情報から、VK_LCONTROLVK_RCONTROLVK_LMENUVK_RMENUという、左右の区別がつく仮想キーコードに変換しなくてはいけません。しかし、Vistaより古いWindowsでは、extended keyのscan codeであるという情報を、このAPIに指定することができないので、普通に呼び出しても、うまくいかないのです。

厳密に調べる方法は簡単にはいかないので、Windows XPの場合は、シンプルに、extended keyであるか否かの情報から、左右を決め打ちするように修正しました。実際にはもうちょっと、想定しない動作にならないように、また、SendMessage()や、PostMessage()でフェイクのキーメッセージが送られてきた場合にも備えて、いくつかの安全装置を入れてあります。