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

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

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

2014年5月1日

Firefox 29以降では、URLバーからボタンを分離してカスタマイズするにはアドオンが必要になっています 初回投稿日時: 2014年05月01日20時45分21秒
最終更新日時: 2014年05月01日21時24分18秒
カテゴリ: Firefox Mozilla29
固定リンク: id=2014050100
SNS: (list)

Army of Awesomeを見ていると、この件で困っている人がそれなりに居て、なおかつ、解決策を自力で発見されていないことが大半なので、ここに、詳細を書いておきます。困っている方を発見したら、この記事を紹介してあげてください。

まず、この記事に興味がある方の一番の関心事はどうやれば、カスタマイズできるのか、ですので、それを最初に紹介しておきましょう。結論から言うと、アドオンを利用するしかありません。ここでは、一番、有名な、Aris氏作のClassic Theme Restorerを利用した方法を紹介します。他にも単機能でできるものがありそうですが、ざっくりと検索しただけでは、発見できませんでした。

まず、上記アドオンをインストールして、Firefoxを再起動します。再起動すると、UIのカスタマイズ画面には、更新ボタンと、中止ボタンが追加されます。
カスタマイズ画面に出現した、Classic Theme Restorerの更新ボタンと中止ボタンのスクリーンショット

これらをツールバーにドラッグ&ドロップすると、ツールバーに追加可能ですが、このままでは、URLバーに統合されている、戻るボタン・進むボタンのせいで、これらの中間に昔ながらのように配置することはできません。これを解決するには、Classic Theme Restorerの設定を変更する必要があります。

アドオンマネージャから、Classic Theme Restorerの設定画面を呼び出します。下記スクリーンショットの設定ボタンを押してください。
アドオンマネージャに表示されてる、Classic Theme Restorerの設定ボタンのスクリーンショット

これをクリックすると、以下のようなダイアログが表示されます。
Classic Theme Restorerの設定ダイアログのスクリーンショット

このダイアログのGeneral UIの、Movable back-forward buttonにチェックを入れると、URLバーに統合された戻るボタン、進むボタンが消え、移動可能な戻るボタンや進むボタンが出現します。
Classic Theme Restorerの生成した戻る・進むボタンのスクリーンショット

ですが、URLバー内に、更新ボタンがもう一つ存在することになるので、これを消すには、Classic Theme Restorerの設定で、General UIの、Hide urlbars stop & relaod buttonsにチェックを入れます。また、更新ボタンと中止ボタンを並べた時に、二つを融合させ、どちらかしか表示されないようにするには、Combine stop & reload buttonsにチェックを入れます。

あとは、カスタマイズ画面でボタンを並べなおすだけで、昔ながらのボタン配置にカスタマイズできます。
カスタマイズ画面で、ナビゲーションボタンをURLバーの左側に並べた状態のスクリーンショット

更新ボタンと、中止ボタンを融合するように設定してると、カスタマイズを終了した時に、以下のようになります。
カスタマイズ画面を終了し、更新ボタンと中止ボタンが融合し、中止ボタンが非表示になっているスクリーンショット

このアドオンは他にも、細かく、タブのスタイルや、Firefoxボタンを復活させることもできるので、設定ダイアログをいじってみると、お好みの状態にカスタマイズできると思います(まだ、英語版しかないのが残念ですが)。

そもそも、何故、このような変更になったのか、その理由も紹介しておきましょう。個人的に、以下の理由には納得できませんが……

Frank Yan (:fryn) 2012-05-15 18:13:30 PDT

We're planning to merge back/forward, URL bar, reload/stop/go into one toolbar item to reduce maintenance costs and make customization more intuitive (eschewing magicall combining UI) when we land the customization panel flow for Australis.

訳: 私たちは、戻る・進む・URLバー・更新・中止、Goボタンを、ひとつのツールバーアイテムとして統合することを計画しています。メンテナンスコストを削減し、(ボタン同士を条件付きで融合する変わったUIを避け、)より直感的なカスタマイズが行えるようにするのが目的です。これは、カスタマイズ可能なパネルをAustralis (Firefox 29の新UIのコードネーム)を投入する際に行います。

:Gavin Sharp (email gavin@gavinsharp.com) 2013-05-17 15:26:28 PDT

We discussed this on IRC. The arguments in favor are:

  • "magic" buttons have implementation as well as user customization-interaction downsides (previously detailed here, in comment 0 and comment 12)
  • there is no great "middle ground" here. Allowing flexibility necessarily allows accounting for the various combinations, even if we try to restrict those further. Offering multiple variants of these buttons is still confusing, and doesn't really avoid any implementation complexity.
  • customization of this type is a "2%" use case that is best left addressed by add-ons, and the combined benefits of the simplified model (for users) and implementation/maintenance savings (for us) outweigh the concerns and loss of good will from the set of users who will be upset at losing this built-in flexibility

On the whole I find this argument reasonable, though I really wish we could validate the last assertion with some data. I think we should just move forward with this.

訳: 私たちは、IRCでこの問題について議論しました。その結果は、

  • 融合するような変わったボタンは、その実装面や、カスタマイズ時の関係性について、不利な面があります (これは既に、comment 0やcomment 12で詳しく述べられています)
  • よい妥協点が思いつきません。柔軟なカスタマイズ性を持たせるには、様々な組み合わせについて考慮しなくてはいけません。それは、従来のもの以上に制限したものにしても同様です。これらのボタンの複数の組み合わせを実現しようとすると、ユーザを混乱させることが予想され、実装の簡略化は行えません。
  • このようなカスタマイズを行っているのは2%のユーザのみであり、アドオンに任せるべきでしょう。この機能が標準で実装されていないことによって困るユーザの不満よりも、(ユーザにとって)シンプルな仕様と、(開発者にとって)実装や、メンテナンスコストを削減することによる双方にとってのメリットの方が大きいでしょう。

データを基にした私たちの最後の検証が間違っていないと思いますが、私はこれは合理的な結論だと思います。そして、私は、この方針で行くべきだと思います。

2014年5月2日

ATOKを64bit版Windowsで利用している環境で、Flash Playerのあるページから移動したり、タブを閉じたりする場合にプラグインプロセスがハングアップすることがあります 初回投稿日時: 2014年05月02日00時43分45秒
最終更新日時: 2014年05月02日01時02分33秒
カテゴリ: Firefox Flash
固定リンク: id=2014050200
SNS: (list)

64bit Windows版のATOKには、一部のアプリの終了時に、ハングアップを引き起こすバグがあります。タブを閉じたときに、以下のようなダイアログが度々表示される場合、それはこのバグに遭遇していると思われます。
プラグインプロセスがハングアップした時に表示されるダイアログ

数分放置すると動くこともあるので、完全なデッドロックではないようですが、詳しいことは分かりません。

残念ながら、このバグは、Firefox上でFlash Playerを読み込んだページから移動したり、タブを閉じた際に再現することがあります。残念ながら、最新版のATOK 2014でも根本的には修正されていませんが、ATOK 2013以前で再現する場合は、以下に紹介する設定を行うことで、このバグが発生しなくなる環境もあるそうです。私の環境ではダメでしたが。ちなみに、ATOK 2014では最初からこの設定になっているそうで、設定の必要はないと聞いています。

  1. C:\Program Files (x86)\JustSystems\ATOK26をエクスプローラで開き、ATOK26EE.EXEをダブルクリックして実行する。
    エクスプローラでATOK26EE.EXEを表示しているスクリーンショット
  2. 環境設定の選択ダイアログで*がついている設定を選択し、「選択」ボタンを押す。
    ATOK26EE.EXEの環境設定の選択ダイアログのスクリーンショット
  3. 環境設定編集ツールが開いたら、画面右側のリスト内で右クリックし、コンテキストメニューの「設定項目の追加」実行。
    ATOKの環境設定編集ツールの右側のリストでコンテキストメニューを表示しているスクリーンショット
  4. 設定項目の追加ダイアログで、「SIPモード遅延初期化」を選択し、「OK」ボタンを押す。
    設定項目の追加ダイアログで、「SIPモード遅延初期化」を選択しているスクリーンショット
  5. 環境設定編集ツールに「SIPモード遅延初期化」設定が追加されているので、これを選択。
    環境設定編集ツールで「SIPモード遅延初期化」を選択したスクリーンショット
  6. 値名「しない」周辺をダブルクリックするとドロップダウンリストが開くので「する」に変更。
    「SIPモード遅延初期化」の値をダブルクリックし、「する」に変更しようとしているスクリーンショット
  7. メニューの「ファイル」→「保存」を実行。
    環境設定編集ツールの変更を保存しようとしているスクリーンショット
  8. 環境設定編集ツールを閉じる。

この後、システムの再起動が必要だったかどうかは失念してしまいましたが、環境によっては、これでハングアップが無くなるそうです。

最後に、もうひとつだけ回避策があります。ただし、Flash PlayerではATOKを使わない、アプリごとにIMEの状態を独立させる設定にしていることが条件です。

その方法は、Flash Playerを一度クリックし、Win+Spaceか、左Ctrl+左Shiftを押して、IMEをATOK以外に変更してしまうことです。

そうすれば、Firefoxを閉じるまで、Flash PlayerはATOK以外のIMEになりますが、それ以外のアプリではATOKが有効なままになります。

2014年5月30日

Bug-org 1008244 Regression in 29: "Enter" key on <select> element no longer fires a keypress event 初回投稿日時: 2014年05月30日10時34分32秒
カテゴリ: Events Mozilla Core Mozilla30 Mozilla31 Mozilla32 バグ修正
固定リンク: id=2014053000
SNS: (list)

<select size="1">な要素にフォーカスがある時、Enterキーのkeypressイベントが発生しなくなっている、というバグです。

<select>要素は、non-printableキーを、keypressイベントではなく、keydownで処理するように変更しましたが、<select size="1">の場合、keypressで処理していた時と同様、ドロップダウンが閉じていて、何も処理しない場合でも、preventDefault()を呼び出していました。これが原因で、keypressイベントが発生していなかった訳です。

IEやChromeでは、Enterキーは、non-printableキーにも関わらず、keypressイベントが発生していることが分かりましたので、今後は、defaultPreventedを意識する場合は、その値がtrueの場合はkeydownで、falseの場合はkeypressで処理すべきのようです。

今回の修正では、単に、何もデフォルトアクションが発生しない場合に、preventDefault()を呼ばないようにして対応しています。

この修正は重要なので、Firefox 30以降全てで修正されています。

Bug-org 1008723 menupopup does not stay open, when I clicked the right mouse twice on the menupopup 初回投稿日時: 2014年05月30日10時57分23秒
最終更新日時: 2014年06月10日02時57分17秒
カテゴリ: Firefox Mozilla Core Mozilla32 Windows バグ修正
固定リンク: id=2014053001
SNS: (list)

ブックマークツールバーのサブフォルダを開いている時に、二回目の右クリックで、コンテキストメニューを開き直そうとすると、サブフォルダが閉じてしまう、というバグです。

Bug-org 957019の修正で、ポップアップが開いている時専用のメッセージハンドラで、マウスカーソルに関係の無いメッセージのハンドリング時に、マウスカーソルの位置をチェックしないように修正しましたが、WM_ACTIVATEの、WA_CLICKACTIVATEを忘れており、WM_ACTIVATEの時は常にカーソル位置をチェックしないようになっていました。このため、ポップアップ上で右クリックした場合にも、ポップアップの外側でクリックしたかのように振る舞い、閉じてしまってました。

WA_CLICKACTIVATEの場合には、マウスカーソルの位置を確認するように処理を復元して修正しています。

また、現在、次のESRで修正されているべきだと思ったので、Auroraでの修正を申請中です。

Aurora (31)へのパッチ投入が認められ、既に、Auroraでも修正済みとなっています。

Bug-org 777832 Editable Tree widgets should support Home/End key to jump caret, Home/End key doesn't work>Page Bookmarked>Edit Folder Name 初回投稿日時: 2014年05月30日11時32分46秒
カテゴリ: Mozilla Core Mozilla32 バグ修正
固定リンク: id=2014053002
SNS: (list)

<tree>要素内のアイテムを編集する際、エディタでハンドリングされるべき、一部のキー操作が、動作しない、というバグです。

昔(M16/Netscape 6あたりの頃に)、このような機能があったのは記憶にありますが、非常にバグまみれだったので、無効化されたと聞いていたので、現在のFirefoxのUIにこの機能があることを知って驚きました。

それはさておき、このバグの原因は、<tree>要素が編集用に<input>要素を生成してフォーカスを持たせていても、エディタよりも先にkeydownイベントをハンドリングして、preventDefault()を呼び出しているというものでした。

本来は、エディタもkeydownイベントハンドラを利用して、先に処理すべきなのですが、その修正はすぐにはできないので、<tree>要素がキーイベントをハンドリングする際に、編集中かどうかを先に確認し、編集中ならキーイベントを処理しないようにして、対応しています。

Bug-org 1009388 Support DOM3 Events' virtual modifier "Accel" for getModifierState() 初回投稿日時: 2014年05月30日11時47分45秒
カテゴリ: Events Firefox Mozilla Core Mozilla32 バグ修正
固定リンク: id=2014053003
SNS: (list)

以前から、W3Cに提案していた、ショートカットキー用のモディファイアが押されているかどうかを確認する機能が、承認されて、草案に盛り込まれたので早速実装しました。

D3Eのキー名に、"Accel"という、仮想モディファイアキー名が追加されています。これは、KeyboardEvent.keyに設定されていることは無い、特殊なキー名で、KeyboardEvent.getModifierState()や、MouseEvent.getModifierState()でのみ利用可能で、具体的には、if (event.getModifierState("Accel")) {のように利用できます。

.getModifierState("Accel")は、そのユーザの環境で、ショートカットキーに利用されるモディファイアキーが押されている場合にtrueを返します。例えば、デフォルト設定のFirefoxでは、Windows版とLinux版は、Ctrlキーが押されている時、Mac版ではcommandキーが押されている時にtrueとなります。また、ui.key.accelKey設定値と連動していますので、主にLinux版で、ユーザが224(Metaキー)や、91(Winキー)にカスタマイズしている場合、その値が返ります(Windows版やMac版でカスタマイズされていることは、ほとんど無いでしょう)。

このAPIは、アドオン開発者や、Webアプリが独自のショートカットキーを実装する場合に非常に便利に使えると思います。具体的な利用方法は、MDNで公開しているサンプルを参照してください。

しかし、Webアプリでこの機能を利用する場合にひとつだけ問題があります。それは、どのキーが"Accel"にマッピングされるのか、知りようが無いということです。このため、ユーザに、適切にショートカットキーの一覧を表示することはできません。これは、次のレベルのDOM Eventsの仕様で改善されると思いますが、当面は、プラットフォーム毎に決め打ちで表示するしかないかと思います。

Bug-org 865649 Implement KeyboardEvent.code (only for physical keyboard) 初回投稿日時: 2014年05月30日12時12分23秒
最終更新日時: 2014年05月30日12時13分30秒
カテゴリ: Events Mozilla Core Mozilla32 Mozilla33 バグ修正
固定リンク: id=2014053004
SNS: (list)

個人的には、Firefox 32、Firefox 33の目玉になる機能です。KeyboardEvent.codeの初期実装が完了しました。

KeyboardEvent.codeは、キーボードの物理キーを一意に識別できる属性です。

例えば、JISキーボードの@キーは、ANSIキーボードでは[キーですし、OSのキーボードレイアウトを変更すると、様々な文字の入力キーになりますが、選択されているキーボードレイアウトや、モディファイアキーの状態に関係無く、このキーのイベントのKeyboardEvent.code値は、"BracketLeft"となります。JISキーボードのことしか知らない開発者の方には誤解を生みそうな値ですが、USBの仕様に沿う形でこのような名前になっています。

ただし、ここで言う、物理キー、というのは、あくまでもOSから一意に判断できるキーの話です。例えば、テンキーが独立していないノートPCでNumLockをかけると、Mキーが0キーになったりします。この場合、NumLockがかかっていなかったら、"KeyM"となりますが、NumLockがかかっている場合、"Numpad0"となります。ただし、テンキーが独立しているキーボードを利用している場合、テンキーの0キーは、NumLockがかかっていない時にInsertキーになりますが、KeyboardEvent.code値は、常に"Numpad0"となります。

KeyboardEvent.keyが選択しているキーボードレイアウトや、モディファイアキーの状態を含めて、そのキーが押された時の機能を表現している属性であるのに対して、KeyboardEvent.codeはそれらの状態を無視しているという、この特性の違いをうまく利用して実装に利用してみてください。

なお、実装は、Mac以外ではスキャンコードからマッピングされていますが、Macのみ、キーイベントからスキャンコードがとれませんので、仮想キーコードを利用しています。Macの仮想キーコードは、キーボードレイアウトに依存せず、キーの位置を示すことを確認していますが、PC用のキーボードを接続した場合、PrintScreenPauseScrollLockキーはそれぞれ、F13からF15キーにマッピングされてしまうので、接続しているキーボードの種類に関係なく、これらのキーの値は"F13"から"F15"になってしまいます。

詳細なマッピング情報はMDNで公開していますので、他のブラウザでの実装時に互換性をしっかりと持って貰えることを期待しています。

現在のところ、OSのイベントで、物理キーを完全にエミュレーションしている場合にのみ、期待通りに動作します。例えば、スクリーンキーボード等の外部アプリから、スキャンコードが適切に設定されていない場合には、値が空文字列か、デタラメな値になる可能性があります。後者はどうしようもありませんが、前者は今後、APIを活用して対応していく予定です。

この属性は、Gecko 32で実装されましたが、リリースビルドでは設定で無効化されていることに注意してください。現在のところ、Gecko 33から、リリース版でも有効化する予定です。

Bug-org 180840 Support evt.accelKey as boolean property 初回投稿日時: 2014年05月30日12時30分31秒
カテゴリ: Events Mozilla Core Mozilla32 バグ却下
固定リンク: id=2014053005
SNS: (list)

KeyboardEvent.accelKeyや、MouseEvent.accelKeyを実装すべき、というリクエストのバグです。

これがD3E"Accel"仮想モディファイアの原形となるアイデアだったのですが、イベントのインターフェースにこれ以上、.fooKeyといった形の属性を追加し続けたくない、ということで、この案自体は却下となりました。そのため、この機能が通常通りに実装されることはありません。

ただし、.getModifierState()は引数に文字列をとり、内部処理コストも若干高いので、Firefoxのchromeでの処理用に必要性が高い、という話になれば、chrome onlyの属性として実装する可能性はありますので、意見があれば書き込んでください。

Bug-org 889401 implement support for Windows 8.1 colored emoji font 初回投稿日時: 2014年05月30日12時44分08秒
カテゴリ: Mozilla Core Mozilla32 バグ修正
固定リンク: id=2014053006
SNS: (list)

Windows 8.1のカラー絵文字フォントのレンダリングをサポートしよう、というバグです。

誠さんが実装し、解説記事をblogに書かれてますので、詳しいことはそちらを参照してください。(よく分かって無いですが、フォントさえあれば、全プラットフォームで描画可能?)

これで、Webメールの利用時や、Thunderbirdの利用がより便利になりそうですね。