Firefox-Tooltip-Bug nach 22 Jahren behoben

 (bugzilla.mozilla.org)
1 Punkte von GN⁺ 2023-10-11 | 1 Kommentare | Auf WhatsApp teilen
  • Der tooltip-ghost-Bug, bei dem Tooltips im Vordergrund sichtbar blieben, obwohl Firefox im Hintergrund war, wurde lange Zeit in Bugzilla verfolgt und erhielt im Firefox-119-Branch schließlich den Status VERIFIED FIXED
  • Die ursprüngliche Reproduktion bestand darin, den Mauszeiger über einen Toolbar-Link oder ein Symbol zu bewegen, den Tooltip erscheinen zu lassen und dann per Command-Tab oder Alt-Tab zu einer anderen App zu wechseln, woraufhin der Tooltip nicht verschwand
  • Ähnliche Fälle traten nicht nur unter Mac OS X, Windows und Linux auf, sondern auch in Thunderbird, Sunbird und Lightning; in Firefox 5.0.1 kam es sogar dazu, dass bereits beim Überfahren eines Hintergrundfensters mit der Maus Tooltips und ein Mouseover-Zustand ausgelöst wurden
  • Der finale Patch lautete only show tooltip when document has focus und änderte das Verhalten so, dass Tooltips nur noch angezeigt werden, wenn das Dokument den Fokus hat; übernommen wurde dies in mozilla-central als Revision 8ae372dc88d1
  • Die QA reproduzierte das ursprüngliche Verhalten mit Firefox 106.0.1 unter Ubuntu 22.04 und bestätigte anschließend in einem Nightly-120.0a1-Build, dass das Problem nicht mehr auftrat; danach wurden einige zugehörige Regressions-Bugs separat verknüpft

Tooltip, der über einem Firefox im Hintergrund stehen bleibt

  • Bug 148624 behandelt das Problem, dass ein Tooltip im Vordergrund stehen bleibt, obwohl Firefox im Hintergrund ist
  • Der ursprüngliche Titel lautet Tooltips persist in foreground when Firefox is in background, der Alias ist tooltip-ghost
  • Der Status ist VERIFIED FIXED, das Ziel-Milestone der 119 Branch
  • Die Einordnung ist Core :: XUL, der Typ defect, die Schwere S3

Ursprüngliche Reproduktionsschritte und erwartetes Verhalten

  • Die ursprünglich gemeldete Umgebung war Mozilla/5.0 ... Mac OS X ... Gecko/20020602 BuildID: 2002060203
  • Die Reproduktionsschritte sind einfach
    • Mit der Maus über ein Toolbar-Symbol oder einen Link fahren
    • Warten, bis der Tooltip erscheint
    • Mozilla per Command-Tab in den Hintergrund schicken
  • Tatsächlich blieb eine kleine gelbe Tooltip-Box im Vordergrund sichtbar
  • Erwartet wurde, dass der Tooltip verschwindet, sobald Mozilla in den Hintergrund wechselt
  • Der ursprüngliche Melder schrieb, dass der Tooltip erst verschwand, wenn Firefox wieder in den Vordergrund geholt und die Maus aus der Toolbar herausbewegt wurde

Reproduktionsfälle auf mehreren Plattformen

  • Nach der ersten Bestätigung wurde die Plattformangabe von Mac OS X auf All geändert; das gleiche Problem ließ sich auch unter Windows XP und Windows 98 reproduzieren
  • Weitere Fälle wurden unter 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 und Firefox 117.0 gemeldet
  • Auch in Thunderbird-, Sunbird- und Lightning-Umgebungen trat ein ähnliches Verhalten auf
    • Unter Thunderbird 2.0.0.17 und Lightning 0.9 wurde ein Fall angehängt, in dem ein Tooltip aus dem Aufgabenfenster über einem Benachrichtigungsfenster stehen blieb
    • Auch mit Thunderbird 102.4.1 und Firefox 106.0.1 ließ sich das unter GNU/Linux reproduzieren
    • Für Firefox 117.0 und Thunderbird 115.2.0 in xfce- und xfwm-Umgebungen wurden ebenfalls Reproduktionsschritte eingereicht
  • Ein Nutzer berichtete, dass das Problem unter Firefox 115.0.2 und GNOME 44 weiterhin auftrete, und nutzte als Workaround die Einstellung browser.chrome.toolbar_tips, um Tooltips vollständig zu deaktivieren

Auswirkungen über stehenbleibende Tooltips hinaus

  • Es blieb nicht nur bei bereits angezeigten Tooltips: Auch neue Tooltips konnten erscheinen, wenn sich Firefox im Hintergrund befand und der Mauszeiger über den entsprechenden Bereich des Firefox-Fensters bewegte
  • Für Firefox 5.0.1 wurde ein Fall angehängt, in dem Transmission im Vordergrund und Firefox im Hintergrund war und Firefox-Tooltips ausgelöst wurden, sobald die Maus über das Transmission-Inspector-Fenster bewegt wurde
  • Es gab auch einen Fall, in dem der große Tooltip des Adblock-Plus-Toolbar-Buttons über Transmission erschien
  • Ein weiterer Bericht zeigt, wie der Options-Tooltip von Transmission und der Tooltip des Firefox-Google-Suchfelds gleichzeitig sichtbar waren und sich überlappten
  • Bei Einträgen in der Lesezeichen-Symbolleiste wurde nicht nur ein Tooltip, sondern auch ein Mouseover-Zustand ausgelöst
    • Der Zustand des Lesezeichen-Buttons änderte sich zuerst, kurz darauf erschien der URL-Tooltip
    • Auch der +-Button von Open a New Tab wurde als Ausnahme dokumentiert, bei der im Hintergrund ein Mouseover-Zustand und ein Tooltip ausgelöst wurden

Richtung der Behebung und übernommener Patch

  • In Diskussionen der frühen 2010er Jahre wurde vorgeschlagen, Tooltips nicht anzuzeigen, wenn das Fenster beim Auslösen des Tooltip-Timers keinen Fokus hat
  • Safari und Google Chrome dienten auf dem Mac als Vergleichsbeispiele, da sie keine Tooltips anzeigen, wenn sie nicht die Vordergrund-App sind
  • Die Beschreibung des finalen Patches lautete only show tooltip when document has focus
  • Der Patch wurde als Phabricator-Anhang eingereicht und anschließend in autoland und mozilla-central übernommen
  • Der Status wechselte von ASSIGNED zu RESOLVED, die Auflösung wurde FIXED

QA-Verifizierung und nachfolgende Regressionen

  • Die QA bestätigte das Problem mit Firefox 106.0.1 unter Ubuntu 22.04 anhand der ursprünglichen Reproduktionsschritte
  • In derselben Konfiguration trat das Problem im aktuellen Nightly 120.0a1 nicht mehr auf, woraufhin der Status auf VERIFIED gesetzt wurde
  • Der Status firefox119 wurde von fixed auf verified geändert
  • Ein Nutzer vermerkte, dass das Problem nur bei MOZ_ENV_XINPUT2=1 auftrete und bei MOZ_ENV_XINPUT2=0 verschwinde; dies wurde mit bug 1809029 verknüpft
  • Später wurden die folgenden verwandten Regressions-Bugs verlinkt
    • 1857513: Tooltip in der Lesezeichen-Seitenleiste erscheint bei Hover nicht, wenn die Seitenleiste keinen Fokus hat
    • 1861427: Tooltips erscheinen bei Hover nicht mehr, wenn eine andere Anwendung den Fokus hat
    • 2043757: Unter Windows 11 werden Tab-Titel bei Hover nicht angezeigt, wenn Firefox teilweise von einem anderen Fenster verdeckt ist

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-10-11
Meinungen auf Hacker News

  • Falls ihr euch fragt, wie man in der Firefox-Codebasis Bugs findet und behebt: Mike Conley streamt seit Jahren jede Woche live seine Entwicklungsarbeit bei Mozilla.
    Ein großer Teil der Aufzeichnungen besteht darin, dass er sich einen Bug aus dem Backlog nimmt und ihn sehr gründlich nachverfolgt und aufspürt.
    Besonders empfehlenswert, wenn ihr gerade erst mit dem Programmieren angefangen habt und sehen wollt, wie Arbeit an einer echten Codebasis aussieht: https://youtube.com/@mikeconleytoronto

    • Zu Studienzeiten habe ich ungefähr genauso lange nach der Einreichung dieses Bugs viel ehrenamtlich bei Mozilla mitgearbeitet.
      Anfangs war ich im QA-Team mit Bug-Triage beschäftigt und habe geprüft, ob die Bugzilla-Komponente stimmt, ob die Schritte zur Reproduktion sinnvoll sind usw.
      Auch ohne jegliche Praxiserfahrung war es schon sehr lehrreich zu sehen, wie ein großes Projekt betrieben wird und wie echte Entwickler Fixes und Features handhaben; dabei kam ich auch mit Konzepten wie diff, patch und CI/CD in Berührung. Damals waren es Nightly Builds, also streng genommen keine Continuous Integration, aber die Richtung stimmte.
      Später lernte ich, wie man die Apps baut, was besonders unter Windows wirklich mühsam war. Ich baute Firefox, Thunderbird und die damals noch existierende Mozilla Suite, in der Browser, Mail, HTML-Editor usw. integriert waren.
      Am Ende habe ich selbst ein paar Bugfixes beigesteuert. Es ging nur um Dinge wie Tippfehler oder falsch ausgerichtete Icons, aber das Gefühl, dass Code ausgeliefert wird, den tatsächlich Millionen Menschen nutzen, war enorm.
      Nach dem Abschluss half mir diese Erfahrung direkt in meinem ersten Job. Ich fing bei einem Startup im IT-Support und in der QA an, und es gab keinerlei Automatisierung für Builds und Deployments. Wenn jemand nach SVN pushte, konnte es sein, dass man tagelang nicht merkte, dass der Build kaputt war.
      Auf Basis dessen, was ich bei Mozilla gelernt hatte, baute ich mit irgendetwas aus Buildbot, CruiseControl oder Hudson einen Build-Server, der bei einem Push baute und dem Team bei Compiler- oder Testfehlern eine E-Mail schickte.
      Es war ziemlich amüsant, wenn erfahrene Entwickler fragten: „Woher weiß unser IT-Mensch so etwas überhaupt?“ Und schon bevor der Begriff DevOps aufkam, konnte ich mir so eine Rolle selbst schaffen. Das alles habe ich gelernt, weil ich in meiner Freizeit an Mozilla herumgebastelt habe.
      Unterm Strich stimme ich völlig zu: Am Mozilla-Projekt zu hacken ist eine gute Möglichkeit, Praxiserfahrung zu sammeln.

  • Endlich behoben. Ich wünschte, Mozilla würde mehr solcher Dinge angehen.
    Eine der nervigsten Ausprägungen dieses Bugs ist, wenn man ein Spiel im Vollbild startet, die Maus neu positioniert wird und dadurch ein Tooltip erscheint, der dann über dem Spiel schwebt.
    Das Spiel verliert den Fokus, weil es mit Firefox umgehen muss, und mag Alt-Tab nicht, sodass man das Spiel am Ende manchmal neu starten muss.

    • Passenderweise höre ich mir gerade einen Vortrag von Jonathan Blow auf der DevGAMM von vor vier Jahren an, in dem genau diese Art von Defekten als wiederkehrendes Motiv auftaucht.
      https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
    • Ich warte immer noch darauf, dass das grundlegende Container-Tab-Verhalten repariert wird. Da kann man kaum anders, als zu denken, dass das Produktmanagement völlig kaputt ist.
      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
    • Ich erinnere mich, dass ich vor ein paar Jahren einen Kommentar zu dem Bug geschrieben habe, sinngemäß: „Ich habe das auch, und hier sind ein paar Informationen dazu.“
      Letztlich habe ich vor etwa zehn Jahren komplett aufgehört, Firefox zu benutzen. Der Hauptgrund war, dass mich dieser Bug über Jahre hinweg mehrmals täglich störte und Chrome zu diesem Zeitpunkt gut genug als Ersatz geworden war.
      Der Tooltip-Inhalt war oft auch ziemlich generisch, etwa „Previous“, sodass ich fast jedes Firefox-Fenster wieder fokussieren musste, um herauszufinden, woher er kam. Es war jedes Mal eine Qual, ihn aufzuspüren, bis der Tooltip verschwand. Außerdem lag er über allen Fenstern.

  • Noch erstaunlicher ist, dass sich dieses Verhalten in all den Jahren dazwischen nicht zufällig geändert hat. Beeindruckende Bug-Abwärtskompatibilität.

  • Ich habe diesen Bug immer verschiedenen Linux-Desktop-Fenstermanagern zugeschoben, und erst jetzt erfahre ich, dass der Schuldige immer derselbe war.
    Auf kleinen Bildschirmen konnte das ziemlich lästig sein, weil Tooltips Formulare oder andere wichtige Elemente verdecken konnten.
    Ich freue mich auf das Update und hoffe, dass Firefox in den nächsten 22 Jahren nicht nur bugfrei ist, sondern auch wieder so eine einflussreiche Anwendung wird wie früher.

    • Trotzdem werde ich wahrscheinlich weiter den Fenstermanagern die Schuld geben. Ich habe das eindeutig auch außerhalb von Firefox gesehen, sogar außerhalb von Linux.
    • Es trat auch unter Windows auf und passiert betriebssystemübergreifend weiterhin in anderen Anwendungen. Man kann nicht einfach eine bestimmte Komponente oder eine einzelne GUI-Schicht verantwortlich machen.
    • Ich glaube, ich habe es auch in LibreOffice gesehen.
    • Es passiert auch anderswo. In DBeaver sehe ich es häufig.
    • Ich erlebe es regelmäßig auch in Chrome unter Fedora/GNOME/X.Org.

  • https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...
    Wenn man sich den Fünf-Zeilen-Fix für diesen Bug ansieht und denkt: „Das hätte ich auch gekonnt!“, dann hätte man es tatsächlich gekonnt.
    Die eigentliche Frage ist: „Warum habe ich es nicht getan?“
    Wenn ich mir selbst antworte, kommt es darauf an, wie einfach es ist, Firefox zu kompilieren und die Testsuite auszuführen.
    Der anschließende lange Prozess der Bug-Nachverfolgung ist der interessante Teil.

    • Ich trage regelmäßig zu Software bei, die ich im Alltag nutze, und wollte auch bei Firefox etwas machen, habe aber aufgegeben, weil es für Außenstehende zu schwierig war.
      Das ganze System aus hg, mehreren Repositories, alten Wikis, einem sehr komplizierten Build, Bugzilla usw. ist extrem schwer zugänglich.
      Wenn Firefox auf GitHub oder wenigstens in einem selbst gehosteten GitLab läge, sodass man es einfach forken, damit herumspielen und dieselbe CI laufen lassen könnte, wäre das eine völlig andere Geschichte gewesen. Ich wünschte, es wäre so einfach.
    • Ich glaube, dieser Fix wird unterschätzt. Ehrlich gesagt wurden ziemlich viele Zeilen gelöscht, und bevor ich nicht genau verstanden hätte, was diese Zeilen ursprünglich tun sollten, hätte ich mich nicht getraut, die Entf-Taste zu drücken.
    • Der eigentliche Fix sieht sogar noch einfacher aus. Es wurde wirklich nur diese eine Prüfung hinzugefügt: !doc->HasFocus(IgnoreErrors())

  • Wow, ich dachte immer irgendwie, es läge an mir. Das hat mich über mehrere Windows-Versionen und Neuinstallationen hinweg jahrelang begleitet.
    Es passierte nicht oft, aber doch regelmäßig genug, um in Erinnerung zu bleiben.

    • Nicht-native UI-Toolkits scheinen alle ein ganz leicht fehlerhaftes Tooltip-Verhalten zu haben.
    • Ich frage mich, wie viel Geld Mozilla in den letzten 22 Jahren hätte verdienen können, wenn sie Werbefläche auf festhängenden Tooltips verkauft hätten. Sie hätten ihre Bugs monetarisieren sollen, bevor es jemand anderes tut.
    • Genau. Ich dachte, ich würde verrückt, oder ich hätte irgendeine kaputte Installation.
    • Ging mir auch so. Ich dachte, nur ich hätte das, aber es trat auf allen meinen Maschinen unter Linux und Windows auf.
    • Unter macOS war es zumindest seit einigen Jahren genauso.

  • Ein ziemlich interessanter Bug. Viele Leute scheinen ihn erlebt zu haben, manche sagen, sie sähen ihn mindestens einmal am Tag, aber ich kann mich nicht erinnern, dieses Verhalten in den letzten 15 Jahren auch nur ein einziges Mal gesehen zu haben.
    Es scheint auch nicht auf ein Betriebssystem beschränkt zu sein, deshalb frage ich mich, unter welchen Bedingungen dieser Bug tatsächlich sichtbar wurde.
    Der einzige Ort, an dem ich einen ähnlichen Bug gesehen habe, war LibreWolf, also ein auf Datenschutz gehärteter, angepasster Firefox. Ich bin mir aber ziemlich sicher, dass das eher an flatpak lag als am Browser selbst. Andere Firefox-Instanzen, die ich nutze, haben sich nie so verhalten.

    • Solche Bugs scheinen in vielen GUI-Systemen recht häufig zu sein. Unter Windows 10 habe ich dieses Verhalten zum Beispiel oft in der Taskleiste gesehen, und die einzige Möglichkeit, herauszukommen, bestand darin, den Cursor über die Schaltfläche für mehrere Fenster zu bewegen und ihn dann aus der Taskleiste herauszuziehen.
      Viele Websites haben unter den richtigen Bedingungen ähnliche Probleme.
      Die Hauptursache scheint eine Inkonsistenz bei der Event-Zustellung zu sein. Beim Verlassen des Cursors müsste ein Event ankommen, aber aus irgendeinem Grund kommt es nicht an, etwa weil das Fenster den Fokus verliert und deshalb keine Maus-Events mehr zugestellt werden.
      Wenn es keine dedizierte Methode gibt, solche Fälle zuverlässig zu erkennen, etwa DOM onmouseleave oder onmouseout, braucht man Workarounds und Hacks. Man könnte zum Beispiel ein synthetisches Event erzeugen, wenn das Fenster den Fokus verliert.
    • Ich nutze es nativ installiert unter Linux KDE Plasma auf OpenSuse Tumbleweed und sehe es täglich, meistens sogar mehrmals am Tag.
      Am besten lässt es sich so beschreiben: Es passiert, wenn man genau in dem Frame, in dem der Tooltip erscheint, per Tastenkürzel auf einen anderen virtuellen Desktop wechselt.
      Es war eine Race Condition, die sehr genaues Timing erforderte, und deshalb wohl schwer einzugrenzen. Da sie vor allem Leute trifft, die viele Tastenkürzel verwenden, waren wahrscheinlich viele nicht betroffen.
      Ich bin wirklich froh, dass es behoben ist, und freue mich darauf, die entsprechende Firefox-Version zu bekommen.
      Ich habe es gerade getestet: Zur Reproduktion reicht es, die Maus über das Tooltip-Ziel zu halten und vor dem Erscheinen des Popups auf einen anderen virtuellen Desktop zu wechseln, während Firefox nicht die neue aktive Anwendung ist.
    • Ein sehr workflow-spezifischer Bug. Ich erlebe ihn fast nur beim Spielen von Videospielen.
      Beim Spielen läuft oft in einem Browser-Tab ein YouTube-Video, während ich in einem anderen Tab spielbezogene Informationen nachschlage.
      Deshalb interagiere ich direkt vor dem Alt-Tab zurück ins Spiel häufig mit der Tab-Leiste, und dabei wird der Tooltip ausgelöst.
      Bei normaler Browsernutzung befindet sich der Cursor fast immer über Website-Inhalten, und dort treten Tooltips nur selten auf.
    • Ich hatte diesen Bug oft beim Interagieren mit in andere Webseiten eingebetteten YouTube-Videos.
      Der Ablauf ist so: Wenn man den Cursor über die Vollbildsteuerung des eingebetteten Players bewegt, erscheint der Tooltip „Full screen (f)“. Klickt man auf die Steuerung, geht das Video in den Vollbildmodus, aber der Tooltip bleibt über dem laufenden Video stehen.
      Ich nutzte unter Linux X11 den Marco-Fenstermanager von MATE.
    • Bei Spielen ist es ähnlich. Wenn ein Spiel von einem Studio erscheint, das für „kaputte“ Titel bekannt ist, posten Leute Sammlungen seltsamer Dinge, die passieren, aber bei mir passiert so etwas überhaupt nicht. Vielleicht habe ich eine angeborene Bug-Resistenz.
      Allerdings habe ich oft einen harmlosen Bug: Wenn ich im Lesezeichen-Symbolleistenmenü, also über das >>-Symbol oben rechts, das Erweiterungsmenü öffne, werden nicht nur die Lesezeichen angezeigt, die nicht in der Symbolleiste sichtbar sind, sondern alle Lesezeichen als Dropdown-Liste.

  • Interessanterweise wurde dieser Bug schon registriert, bevor die erste Firefox-Version überhaupt erschien: https://en.wikipedia.org/wiki/Firefox_early_version_history
    Beeindruckend, dass sie die Historie des Bugtrackers so lange funktionsfähig gehalten haben.

    • Vielleicht reicht die Bugtracker-Historie noch bis in die Phoenix-/Firebird-Zeit zurück.

  • Oh, endlich. Der zugehörige Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1569439 wurde vor 9 Monaten geschlossen, und dadurch ist es etwas besser geworden.
    Bei diesem Bug ging es lediglich darum, dass Tooltips beim Wechsel zu einer anderen App nicht verschwanden. Beim Wechsel auf einen anderen Workspace blieben sie aber weiterhin stehen, was extrem enttäuschend war.
    Der Nachteil ist, dass das gewissermaßen ein „falscher“ Fix ist. Tooltips sollten auch dann angezeigt werden, wenn das Fenster keinen Fokus hat. Zumindest ist das bei GTK-Apps unter Linux so, und Firefox versucht, dieses Verhalten nachzuahmen.
    Man sollte die eigentliche Ursache beheben, dass Tooltips nicht verschwinden, wenn durch einen Workspace-Wechsel der Mauszeiger tatsächlich nicht mehr über dem Fenster ist.

    • Was mir am häufigsten begegnet ist, war nicht der Bug aus TFA, sondern dieser zugehörige Bug. Ich hatte ihn eine Weile nicht mehr gesehen, und jetzt weiß ich auch warum.

  • Direkter Link zum Patch: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1

    • Ist das ein Commit?
      Falls ja: Ist es üblich, Änderungen an der Einrückung und tatsächliche Codeänderungen in denselben Commit zu packen?
      Ich persönlich hätte vermutlich zuerst die Einrückungsänderung committet und danach die Codeänderung in einem zweiten Commit gemacht.
    • Wow, wenn man die wegen der Einrückungsänderung geänderten Zeilen im Commit ausklammert, besteht diese Änderung nur aus fünf neuen Codezeilen!