22年越しに修正されたFirefoxのツールチップバグ
(bugzilla.mozilla.org)- Firefoxがバックグラウンドにあってもツールチップが前面に残る
tooltip-ghostバグ がBugzillaで長期間追跡され、Firefox 119ブランチでVERIFIED FIXED状態になった - 最初の再現は、ツールバーのリンクやアイコンにマウスを載せて ツールチップを表示した後、Command-TabまたはAlt-Tabで別のアプリに切り替えるとツールチップが消えない、というものだった
- Mac OS X、Windows、Linuxだけでなく、Thunderbird、Sunbird、Lightningでも類似の事例が続き、Firefox 5.0.1ではバックグラウンドのウィンドウ上をマウスが通過するだけでもツールチップと マウスオーバー状態 が発生した
- 最終パッチは
only show tooltip when document has focusで、ドキュメントに フォーカスがあるときだけ ツールチップを表示するよう変更され、mozilla-centralに8ae372dc88d1リビジョンとして反映された - QAはFirefox 106.0.1とUbuntu 22.04で元の手順により再現した後、Nightly 120.0a1ビルドでは問題が継続しないことを確認し、その後いくつかの関連リグレッションバグが別途紐付けられた
バックグラウンドのFirefox上に残るツールチップ
- Bug 148624は、Firefoxがバックグラウンドにあるときでも ツールチップが前面に残る問題 を扱う
- 元のタイトルは
Tooltips persist in foreground when Firefox is in backgroundで、別名はtooltip-ghost - 状態は
VERIFIED FIXED、対象マイルストーンは 119 Branch - 分類は
Core :: XUL、タイプはdefect、重要度はS3
最初の再現手順と期待される動作
- 最初の報告環境は
Mozilla/5.0 ... Mac OS X ... Gecko/20020602 BuildID: 2002060203だった - 再現手順は単純
- ツールバーのアイコンまたはリンクにマウスを載せる
- ツールチップが表示されるまで待つ
- Command-TabでMozillaをバックグラウンドに送る
- 実際には 小さな黄色いツールチップボックス が前面に残り続けた
- 期待される動作は、Mozillaがバックグラウンドに切り替わるときにツールチップが消えることだった
- 元の報告者は、Firefoxを再び前面に戻してマウスをツールバーの外へ移動しないとツールチップが消えないと記している
複数プラットフォームで続いた再現事例
- 初期確認後、プラットフォーム範囲はMac OS Xから All に変更され、Windows XPとWindows 98でも同じ問題が再現された
- Linux GTK2、Firefox 0.8、Firefox 2.0.0.14、Firefox 4 nightly、Firefox 5.0.1、Firefox 36.0、Firefox 49.0.2、Firefox 106.0.1、Firefox 113.0.2、Firefox 115.0.2、Firefox 117.0などでも事例が続いた
- Thunderbird、Sunbird、Lightning環境でも似た現象が見られた
- Thunderbird 2.0.0.17とLightning 0.9では、作業ウィンドウのツールチップが通知ウィンドウの上に残る事例が添付された
- Thunderbird 102.4.1とFirefox 106.0.1の組み合わせでもGNU/Linuxで再現された
- Firefox 117.0とThunderbird 115.2.0、
xfceとxfwm環境でも再現手順が提出された
- あるユーザーは、Firefox 115.0.2とGNOME 44でも引き続き発生するとして、
browser.chrome.toolbar_tips設定で ツールチップを完全に無効化 する回避策を使っていた
残留ツールチップを超える影響
- すでに表示されたツールチップが残るだけでなく、Firefoxがバックグラウンドにある間にマウスがFirefoxウィンドウの該当領域上を通過すると 新しいツールチップが現れる症状 も確認された
- Firefox 5.0.1でTransmissionが前面、Firefoxが背景のとき、Transmission Inspectorウィンドウ上でマウスを動かすとFirefoxのツールチップがトリガーされた事例が添付された
- Adblock Plusツールバーボタンの大きなツールチップがTransmissionの上に現れた事例もあった
- Transmissionの
OptionsツールチップとFirefoxのGoogle検索ボックスのツールチップが同時に表示され、互いに重なった事例も残っている - ブックマークツールバー項目では、ツールチップだけでなく マウスオーバー状態 もトリガーされた
- ブックマークボタンの状態が先に変わり、しばらくしてURLツールチップが表示された
Open a New Tabの+ボタンも、バックグラウンド状態でマウスオーバー状態とツールチップが発生する例外として記録された
修正方針と反映されたパッチ
- 2010年代初頭の議論では、ツールチップタイマーが実行されるときにウィンドウにフォーカスがなければツールチップを表示しない方式が提案された
- SafariとGoogle Chromeは、Macで前面アプリではないときにツールチップを表示しない比較事例として使われた
- 最終パッチの説明は
only show tooltip when document has focusだった - パッチはPhabricator添付として上がり、その後
autolandとmozilla-centralに反映された - 状態は
ASSIGNEDからRESOLVEDに変わり、解決は FIXED になった
QA検証とその後のリグレッション
- QAはFirefox 106.0.1とUbuntu 22.04で元の再現手順によりイシューを確認した
- 同じ構成で最新Nightly 120.0a1では問題がもはや継続しないため、状態は VERIFIED に変更された
firefox119状態はfixedからverifiedに変更された- あるユーザーは
MOZ_ENV_XINPUT2=1のときだけ問題が現れ、MOZ_ENV_XINPUT2=0だと消えると記しており、これはbug 1809029と結び付けられている - その後、関連リグレッションとして次のバグが紐付けられた
1857513: ブックマークサイドバーのツールチップが、サイドバーにフォーカスがないときにホバーで表示されない1861427: 別のアプリケーションにフォーカスがある状態では、ホバー時にツールチップがもはや表示されない2043757: Windows 11でFirefoxが別ウィンドウに一部隠れているとき、タブタイトルがホバーで表示されない
1件のコメント
Hacker News のコメント
Firefox のコードベースでバグをどう見つけて修正しているのか気になるなら、Mike Conley が Mozilla での開発作業を何年も毎週ライブ配信している
録画の多くは、バックログからバグを1つ選び、非常に丁寧に追跡して突き止める過程になっている
特にプログラミングを始めたばかりで、実際のコードベースで働く様子がどんなものか見たいならおすすめ: https://youtube.com/@mikeconleytoronto
最初は QA チームでバグのトリアージをしていて、Bugzilla のコンポーネントが正しいか、再現手順が筋の通ったものか、などを確認していた
実務経験がまったくない立場でも、大規模プロジェクトがどう運営されているのか、実際の開発者が修正や機能をどう扱っているのかを見るだけで大きな学びになり、diff、patch、CI/CD のような概念にも触れた。当時は nightly build だったので厳密には継続的インテグレーションではなかったが、方向性は合っていた
その後、アプリのビルド方法を覚えたが、特に Windows では本当に大変だった。Firefox、Thunderbird、そして当時はまだ存在していた Mozilla Suite までビルドした。ブラウザ、メール、HTML エディタなどが統合された形のものだった
最終的には自分でもバグ修正をいくつか貢献した。誤字やずれたアイコンを直す程度だったが、何百万人もの人が実際に使うコードが配布されるという感覚はすごかった
卒業後の最初の職場で、この経験がすぐ役に立った。スタートアップで IT サポートと QA から始めたのだが、ビルドとデプロイの自動化がまったくなかった。誰かが SVN に push しても、ビルドが壊れたかどうか数日間わからないことがあり得た
Mozilla で学んだことをもとに、Buildbot、CruiseControl、Hudson のどれかを使って、push 時にビルドし、コンパイル失敗やテスト失敗時にチームへメールを送るビルドサーバーを作った
熟練した開発者たちが「うちの IT 担当者が、いったいどうしてこんなことを知っているんだ」と尋ねてくるのはかなり面白かったし、DevOps という言葉が生まれる前から、そういう役割を自分で作り出すことができた。すべて余暇に Mozilla をいじりながら学んだおかげだ
結局、Mozilla プロジェクトをハックしてみるのは実務経験を得る良い方法だという点には完全に同意する
ついに直ったか。Mozilla にはこういうことをもっとやってほしい
このバグの特にうっとうしい形の1つは、全画面ゲームを起動しているときにマウスが再配置されてツールチップが出て、それがゲームの上に浮いてしまう場合だ
ゲームは Firefox を処理しようとしてフォーカスを失ったり Alt-Tab されたりするのを嫌うので、結局ゲームを再起動しなければならないことがある
https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
結局、約10年前に Firefox の使用を完全にやめた。主な理由は、このバグが何年もの間、1日に何度も気になっていたことと、その頃には Chrome が代替として十分よくなっていたことだ
ツールチップの内容も「Previous」のようにかなり一般的な場合が多く、どこから来たのか突き止めるために、ほぼすべての Firefox ウィンドウにもう一度フォーカスを当てる必要があり、そのツールチップが消えるまで探し回るのがいつも苦痛だった。しかも、すべてのウィンドウの上に浮いていた
その間の何年ものあいだ、この動作が偶然にでも変わらなかったことのほうが驚きだ。印象的なバグの後方互換性だ
このバグをずっと複数の Linux デスクトップのウィンドウマネージャーのせいにしていたが、犯人がいつも同じだったのだと今になってわかった
小さな画面ではフォームや他の重要な要素の表示を隠してしまうことがあり、かなり厄介な場合があった
アップデートが楽しみだし、これからの22年間、Firefox がバグのないだけでなく、昔のように影響力のあるアプリケーションになってほしい
https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...
このバグを直す5行の修正を見て「自分にもできたかも！」と思うなら、実際にできたはず
本当の問いは「なぜやらなかったのか？」ということ
自分なりに答えるなら、Firefoxをコンパイルしてテストスイートを実行するのがどれだけ簡単かが鍵
その後の長いバグ追跡プロセスこそが面白い部分
hg、複数のリポジトリ、古いWiki、非常に複雑なビルド、Bugzillaなどが絡んだ全体の仕組みが、参入するにはあまりに大変
FirefoxがGitHub、あるいはせめてセルフホストのGitLabにあって、ただフォークして触って同じCIを回せるなら、まったく違う話になっていたはず。そんなふうに簡単だったらいいのに
!doc->HasFocus(IgnoreErrors())うわ、ずっと何となく自分が悪いだけだと思っていた。いくつものWindowsバージョンや再インストールを経ても、何年もついて回っていた
頻繁ではなかったが、記憶に残るくらいには継続的に起きていた
かなり興味深いバグだ。多くの人が遭遇したようで、ある人は1日に少なくとも1回は見ると言っているが、自分はこの15年間で一度もこの挙動を見た記憶がない
OSに限定されているようにも見えないので、実際にこのバグが表に出る条件が何だったのか気になる
似たバグを見た唯一の場所はLibreWolf、つまりプライバシー保護を強化したカスタム版Firefoxだ。ただしブラウザ自体のせいというより、flatpakだからだとほぼ確信している。自分が動かしている他のFirefoxでは、そういう挙動を見たことがない
多くのWebサイトでも、条件がそろえば似た問題が起きる
主な原因はイベント配送の不一致に見える。カーソルが出たときにイベントを受け取るべきなのに、たとえばウィンドウがフォーカスを失って、それ以上マウスイベントが配送されなくなる、といった形で何らかの理由で受け取れない
こうしたケースを安定して検出する専用の方法、たとえばDOMの
onmouseleaveやonmouseoutのようなものがなければ、回避策やハックが必要になる。たとえばウィンドウがフォーカスを失ったときに合成イベントを生成できる一番うまく説明するなら、ツールチップが表示されるまさにそのフレームで、キーボードショートカットで別の仮想デスクトップへ切り替えると発生する
非常に正確なタイミングが必要な競合状態だったので、絞り込むのが難しかったのだと思う。キーボードショートカットを多用する人に主に引っかかるので、多くの人は影響を受けていなかった可能性も高い
修正されたと聞いて本当にうれしいし、そのバージョンのFirefoxを受け取るのが楽しみ
いま試してみたところ、再現するには、ツールチップ対象の上にマウスを置き、ポップアップが出る前にFirefoxが新しいアクティブアプリケーションではない状態で別の仮想デスクトップへ切り替えるだけでよい
ゲーム中はブラウザのタブ1つでYouTube動画を流し、別のタブでゲーム関連情報を調べていることが多い
そのためゲームへAlt-Tabする直前にタブバーを操作することがよくあり、そのときツールチップがトリガーされる
普段のブラウザ利用では、カーソルはほぼ常にWebサイトのコンテンツ上にあり、そこではツールチップはめったに発生しない
流れはこうだ。埋め込みプレイヤーの全画面コントロール上にカーソルを置くと「Full screen (f)」ツールチップが出て、コントロールをクリックすると動画は全画面になるが、ツールチップは再生中の動画の上にそのまま残る
Linux X11で、MATEのMarcoウィンドウマネージャを使っていた
ただし、ブックマークツールバーの拡張メニュー、つまり右上の
>>アイコンを開くと、ツールバーに表示されていないブックマークではなく、すべてのブックマークがドロップダウンリストに表示されるという無害なバグにはよく遭遇する興味深いことに、このバグはFirefoxの最初のバージョンが出る前に登録されていた: https://en.wikipedia.org/wiki/Firefox_early_version_history
バグトラッカーの履歴をここまで長く動き続けるように保っている点は印象的
おお、ついに。関連バグの https://bugzilla.mozilla.org/show_bug.cgi?id=1569439 は9か月前にクローズされていて、そのおかげで少し改善していた
そのバグは、単に別のアプリへ切り替えたときにツールチップが消えないという問題だった。ただ、別のワークスペースへ切り替えたときにはまだ残っていて、ものすごくがっかりした
欠点は、これがある程度「間違った」修正だということ。ツールチップは、ウィンドウにフォーカスがなくても表示されるべきだ。少なくとも Linux の GTK アプリではそうだし、Firefox もその挙動をまねようとしている
ワークスペースが変わって、マウスポインタが実際にはもうウィンドウ上にないときにツールチップが消えないという根本原因を直すべき
パッチへの直接リンク: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1
だとしたら、インデント変更と実際のコード変更を同じコミットに入れるのは一般的なのだろうか？
個人的には、まずインデント変更をコミットして、その次の2つ目のコミットでコード変更をしたと思う