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

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

もずはっく日記(2005年9月)

2005年9月2日

Bug 4102 サブメニューが開く時に、そのメニューが消える
初回投稿日時: 2005年09月02日00時43分27秒
カテゴリ: Mozilla Core
SNS: (list)

人によっては非常に気になっていたのではないかと思われるこのバグ、修正が完了した。

どいういうバグかと言うと、サブメニューが開く瞬間に、そのサブメニューの親のメニューごと閉じられてしまうことがあるというバグ。詳しくはバグ内のコメントを参照。

詳しく、説明してみると、まず、これまであるメニューがハイライトされた時、そのポップアップの他のメニューアイテムがサブメニューを開いているなら、そのサブメニューを閉じるためのタイマーを起動していた。一定時間経過して、そのサブメニューが相変わらずアクティブなメニューではなかった場合にはそのメニューを閉じ、アクティブになっていたらサブメニューを開いたままにしていた。

このメニューがアクティブであるかは閉じようとしているメニューから、子孫メニューの方へ順に下っていき、最後までポップアップ内のどれかのアイテムがハイライトされていたらアクティブ、そうでなければ非アクティブ、という判定方法だった。

この方法は多くの場合に問題が無かったが、以下の場合に最も子孫のメニューがハイライトされていない、という問題を抱えていた。

  • サブフォルダを開いた直後
  • メニューセパレータの上にマウスカーソルを移動した時
  • メニュー内のスクロールボタンにマウスカーソルを移動した時
  • メニュー内がスクロール出来るときに、マウスホイールでスクロールした時

これらの問題を、現在のアプローチのまま解決することは実に難しい。メニューはマウスでもキーボードでも操作できるという事実が特にこれを困難にしている。そこで、閉じるメカニズムはそのままに、アプローチを完全に変えてみるとこにした。

新方式では、あるメニューアイテムがハイライトした時、その祖先のポップアップのサブメニューを閉じるためのタイマーを全てキャンセルし、サブメニューを開いているアイテムをハイライト状態に戻して行っている。逆に言うなら、タイマーがタイムアウトした場合、メニューの状態は非アクティブのままだったいう判定で、常に閉じるようになった。

もし、微妙にフィードバックに違和感を感じるなら、この祖先メニューのハイライト状態の変更が従来よりも素早くなっていることに対するものだろう。(従来は、タイムアウト時に、そのメニューがアクティブと判定された場合に、サブメニューを開いているメニューをハイライトしなおしていた。)

メニューの動作を大きく変更したパッチなので、どのようなregressionがあるか想像つかないため、1.8branchへの承認申請は行わないことに注意して欲しい。

関連するかもしれないエントリ

bug 4102を含むエントリ

このエントリへのリンク元