Firefox-`<textarea>`-Bug nach 25 Jahren behoben

 (bugzilla.mozilla.org)
1 Punkte von GN⁺ 2024-05-23 | 1 Kommentare | Auf WhatsApp teilen
  • Der alte Bug 33654 in Firefox betraf das Problem, dass <textarea> beim Anwenden von ROWS= und COLS= den Platz für Scrollbars mit einrechnete und dadurch größer erschien als die angegebene Zahl von Zeilen und Spalten; inzwischen wurde er als Duplikat von Bug 1830576 geschlossen
  • In Umgebungen, in denen Overlay-Scrollbars deaktiviert sind oder die Einstellung „Scrollbars immer anzeigen“ genutzt wird, trat wiederholt das Phänomen auf, dass <textarea rows=N> ungefähr mit einer Höhe von N+1 Zeilen berechnet wurde
  • Die frühen Diskussionen weiteten sich auf Schriftvererbung, erzwungenes monospace, die cols-Berechnung anhand der durchschnittlichen Breite von w und W sowie die Reservierung von Scrollbar-Platz aus; über lange Zeit sammelten sich Testcases, Patches und Screenshots an
  • In der Praxis sah rows=1 wie 3 Zeilen aus oder rows=2 wurde mit einer Höhe von 3 Zeilen angezeigt, und bei cols=80 unterschieden sich die Zeilenumbruchpositionen zwischen IE und Firefox, sodass die Steuerung von Formularlayouts je nach Browser auseinanderlief
  • Nachdem Bug 1830576 VERIFIED FIXED wurde, ist die Anwendung von Scrollbar-Abständen in WebKit, Chromium und Firefox konsistent geworden; Bug 33654 wurde als RESOLVED DUPLICATE abgeschlossen

Status und Umfang von Bug 33654

  • Bug 33654 war ein Defekt, bei dem <textarea> ROWS= und COLS= falsch anwendete, sodass bei deaktivierten Overlay-Scrollbars zusätzlicher Platz für horizontale und vertikale Scrollbars entstand
  • Produkt und Komponente sind Core :: Layout: Form Controls; darunter fallen Layout und Darstellung von HTML-Formularsteuerelementen, insbesondere Elemente wie textarea
  • Der aktuelle Status ist RESOLVED DUPLICATE of bug 1830576
    • Der Titel des Duplikat-Ziels Bug 1830576 lautet Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • Der Status von Bug 1830576 ist VERIFIED FIXED
  • Der Bug wurde vor 26 Jahren eröffnet und vor 2 Jahren als RESOLVED DUPLICATE geschlossen
  • In den Metadaten sind Version Trunk, Plattform x86 / All, Typ defect, Priorität P3 und Schweregrad S3 angegeben
  • Als Keyword ist testcase vermerkt, das Whiteboard enthält [html][behavior]relnote-devel, und die Zahl der Stimmen wird mit 99 angegeben
  • Anhänge werden als 17 files, 17 obsolete files angezeigt; Testcases, Patches und Screenshots wurden wiederholt hochgeladen

Erste sichtbare Symptome

  • Im ersten Bericht schrieb Andrew McMillan, ein TEXTAREA-Beispiel mit ROWS=5 COLS=30 werde ungefähr wie ROWS=7 COLS=48 angezeigt
  • In frühen Kommentaren folgten Beispiele, in denen INPUT TYPE=TEXT und TEXTAREA die angegebene Schrift nicht korrekt verwendeten oder der Bereich trotz sichtbarer Scrollbars zu hoch war
  • Die weitere Diskussion lief darauf hinaus, dass das textarea-Layout falsche Informationen erhält, bei Spalten zusätzlicher Platz vorhanden ist und bei Zeilen eine Zeile zu viel erscheint
  • Schon früh wurde auch die Möglichkeit behandelt, dass die vorab reservierte Fläche für Scrollbars die Ursache ist

Schriftberechnung und frühe Patches

  • In einem Beispiel aus einer HTML-Authoring-Newsgroup schien IE bei gemeinsamer Verwendung von textarea { font-size: 8pt } und <textarea cols="40" rows="12"> die Breite korrekt zu rendern, während Mozilla die Breite offenbar auf Basis einer 12-pt-Schrift berechnete
  • Eine Testdatei mit der Schrift arial enthielt <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial">
  • Rod ging davon aus, dass die Größenberechnung mit der Standardschrift korrekt ist und der Kern des Problems daher weniger das Sizing selbst als vielmehr die Tatsache ist, dass textarea die richtige Schrift nicht verwendet
  • Kin fand Code, der bei gesetztem PlainText-Flag des Editors zwangsweise font-family: monospace; auf den Inhaltsbereich von TextControl anwendet
    • Wird dieser Code entfernt, wird die richtige Schrift verwendet
    • Im NavQuirks-Modus bleibt jedoch das Problem, dass eine 30 Zeichen lange Zeichenkette in einer 30-Spalten-textarea nur etwa 2/3 der Breite einnimmt
    • Als Ursache wurde die Methode von nsFormControlHelper benannt, die durchschnittliche Breite von w und W aus der Schrift zu ermitteln, mit der Spaltenzahl zu multiplizieren und die Scrollbar-Breite hinzuzufügen, um die Breite der textarea zu berechnen
  • Patch to use the correct font. fügte den Initialisierungs-Flags des Plain-Text-Editors eEditorEnableWrapHackMask hinzu und beschränkte die Anwendung von font-family: monospace; auf bestimmte Bedingungen
  • Dieser Patch wurde zeitweise als RESOLVED FIXED behandelt, aber wieder geöffnet, nachdem der ursprüngliche Reporter meldete, dass COLS=... zwar stimme, ROWS=... jedoch weiterhin falsch funktioniere

Wiederholte Reproduktionen und Duplikat-Bugs

  • Die Liste der Duplikat-Bugs enthält zahlreiche Fälle, in denen <textarea> eine Zeile größer erscheint als angegeben oder rows=1 wie 3 Zeilen aussieht
    • Bug 46106: Textarea displaying more rows than designated.
    • Bug 116779: <textarea rows=1> shows 3 rows
    • Bug 133342: textarea always rendered with one more row than defined
    • Bug 186271: textareas are 1 row taller than specified
    • Bug 206946: <textarea rows="2"> shows ~3 lines
    • Bug 911226: <TEXTAREA> always rendered one line too tall !
  • Der interaktive Testcase war ein HTML-4.01-Strict-Dokument, in dem sich die Werte für rows und cols per Button ändern ließen; es verwendete weder font-Tags noch proportional laufende Schrift
    • Das Ergebnis war, dass stets 3 Spalten mehr als der angegebene Wert vorhanden waren und die Zeilenanzahl meist um 1 höher war
    • Bei Anforderung von rows=1 wurden 3 rows angezeigt
  • In Linux- und Win2000-Trunk-Builds von 2002 wurde <textarea cols=40 rows=2></textarea> als 3 rows angezeigt; bei rows=N wurden exakt N+1 rows angezeigt
  • Auch der W3C-HTML-4.01-Test wurde als Referenzmaterial verwendet, mit Kommentaren, dass das Problem in den ROWS-bezogenen Tests klar sichtbar sei
  • Auch unter Windows 2000 und Mozilla 0.9.3 wurde ein Beispiel hochgeladen, in dem eine rows=1-textarea offensichtlich nicht wie 1 row aussah

Diskussion zur Berechnung des Scrollbar-Platzes

  • Comment 86 erklärt, dass die Größe der textarea als angegebene cols/rows plus Scrollbar-Platz berechnet wird
  • Es wurde analysiert, dass Mozilla Scrollbars im Gegensatz zu IE nur bei Bedarf anzeigt, weshalb Nutzer dieses Verhalten als defekt wahrnehmen
  • Drei mögliche Optionen wurden vorgeschlagen
    • Scrollbar-Größen bei der Größenberechnung der textarea nicht hinzufügen
    • Scrollbars wie IE immer anzeigen
    • Nur die Scrollbars einbeziehen, die angezeigt werden
  • Gegen die dritte Option wurde eingewandt, dass die Größe davon abhängt, ob Scrollbars angezeigt werden, und die Anzeige der Scrollbars wiederum von der Größe abhängt, was zyklisch ist
  • Comment 87 schlug als vierte Option vor, dass ROWS und COLS nur die Content-Größe der textarea steuern und die textarea größer wird, wenn Scrollbars erscheinen
  • Die weitere Implementierungsrichtung wurde so diskutiert: zunächst Reflow mit width/height ohne Scrollbar durchführen, um zu bestimmen, ob Scrollbars nötig sind; falls ja, mit neuer width/height erneut reflowen

Auswirkungen für Nutzer

  • Wenn trotz rows="2" eine textarea mit 3-row-Höhe erscheint, wird die Absicht verwischt, die gewünschte Eingabemenge visuell zu vermitteln
    • Eine Webanwendung forderte einen kurzen Zusammenfassungstext an und nutzte rows="2", um eine Eingabemenge zu signalisieren, die „mehr als eine Zeile, aber kein Essay“ ist
    • Wegen der Verhaltensunterschiede zwischen Firefox, IE6 und Opera 8 erzeugte derselbe rows-Wert je nach User Agent unterschiedliche visuelle Hinweise
  • Auch wenn der Inhalt der textarea nicht scrollte, folgten Kommentare, dass das Firefox-Verhalten falsch sei
    • Selbst wenn für eine textarea, die wie eine Adresse meist nicht mehr als drei Zeilen benötigt, rows="3" angegeben wird, zeigt Firefox immer eine zusätzliche Zeile an
    • Die Seite wird unnötig größer, und Nutzer könnten denken, das Feld sei größer als erwartet, weil sie nicht genug Informationen eingetragen haben
  • Beim Vergleich mit cols=80 erklärte eine Screenshot-Beschreibung, dass IE 80 1-Zeichen bis zur Scrollbar-Kante füllt und dann umbricht, während Firefox nach 80 1-Zeichen noch Platz für zwei weitere Zeichen hat und danach eine horizontale Scrollbar erscheint
  • Auch 2019 gab es noch Kommentare, dass das Problem weiterhin besteht; als betroffenes Beispiel wurde die Trello-Karte Chat bar is a line taller than usual on Firefox von Discord genannt

Langjährige Patch-Versuche

  • Hideo Saito hängte mehrfach Patches und Testcases an
    • patch for rows and cols
    • wrap="off"-Patch-Testcase
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • Ein Ansatz bestand darin, nsTextControlFrame::Reflow mit der intrinsischen Größe ohne Scrollbar auszuführen und dann, falls Scrollbars vorhanden sind, die Scrollbar-Größe zur intrinsischen Größe hinzuzufügen und erneut zu reflowen
  • Auch ein Ansatz wurde behandelt, bei dem GetScrollbarStyles geändert wird, um zu steuern, ob der Text-Control-Frame Scrollbars auf auto, hidden oder scroll setzt
  • roc bevorzugte eine Lösung in nsTextControlFrame statt umfangreicher Änderungen an nsGfxScrollFrame
  • Spätere Patches durchliefen wiederholt Reviews und Überarbeitungen rund um Mechanismen wie SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow und post-reflow callback
  • Einige Patches erhielten review- oder wurden als obsolete markiert; Reviewer wiesen darauf hin, dass Updates für den Trunk erforderlich seien

Workarounds und Grenzen

  • Es gab den Vorschlag, dass das Hinzufügen von CSS textarea{ overflow-x: hidden } das Problem löse
  • Dieser Ansatz galt nur unter der Bedingung, dass keine horizontale Scrollbar benötigt wird
  • Ein anderer Kommentar widersprach, dass dieser Bug nicht allein mit CSS overflow behoben werden könne und Firefox der einzige Browser sei, der bei textarea eine zusätzliche Zeile rendere
  • Emilio Cobos Álvarez sagte, die Ursache scheine die Scrollbar-Größe zu sein, und das Anwenden von scrollbar-width: none auf <textarea> scheine das Problem zu lösen
  • Derselbe Kommentar ergänzte jedoch, dass der Bug selbst trotzdem behoben werden müsse

Abschließende Einordnung

  • Vor 3 Jahren bat BugBot um eine Prüfung, ob der Schweregrad angehoben werden sollte, da dieser Bug zwar den relativ niedrigen Schweregrad S3 hatte, aber 27 Duplikate, 103 Stimmen und 91 CCs aufwies
  • Die Bug-Zusammenfassung wurde von TEXTAREA incorrectly applying ROWS= and COLS= zu TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled) geändert
  • Daniel Holbert fügte Bug 1830576 Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration als Abhängigkeit hinzu
  • Luke Warlow fragte, ob dieser Bug geschlossen werden könne, da Bug 1830576 behoben sei und die Anwendung von Scrollbar-Abständen in WebKit, Chromium und Firefox nun konsistent geworden sei
  • Emilio Cobos Álvarez stimmte dem zu, und Bug 33654 wechselte von NEW zu RESOLVED und wurde als DUPLICATE geschlossen
  • Als Duplikat-Ziel wurde Bug 1830576 festgelegt; dieser Bug hat den Status VERIFIED FIXED

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-23
Meinungen auf Hacker News

  • Ha! Ich hatte diesen Bug während des Großteils dieser 25 Jahre abonniert. Damals gab es Firefox noch nicht, und er war nicht als Bug zu Netscape Navigator eingetragen, sondern bei Mozilla, ungefähr aus der Zeit davor bzw. danach
    Ich weiß nicht mehr, warum ich ihn abonniert hatte, vermutlich hatte ich kommentiert. Alle paar Jahre kam eine Benachrichtigungs-Mail, was mich immer zum Lachen brachte, und vor ein paar Tagen wurde er endlich behoben

    • Erstaunlich, dass das Abo dieses Bug-Threads all die vielen Jahre überlebt hat
    • Bei mir ähnlich. Als ich zum ersten Mal überlegte, Website-Erstellung beruflich zu machen, war ich fasziniert von der Vorstellung einer Website, deren Hintergrund bis zum Desktop transparent oder halbtransparent zu sehen ist
      Ich dachte immer, so etwas wie html { background: transparent; } müsste einfach funktionieren. Allerdings bewirkt dieser Bugfix das nicht wirklich. Zunächst ist es keine Funktion, die Websites standardmäßig wählen, sondern eine Einstellung, die Nutzer oder Erweiterungen aktivieren können. Das ist vermutlich besser so, denn wäre es standardmäßig erlaubt, hätte es neue Wege für Clickjacking eröffnet
    • Es war weniger „für Netscape Navigator eingetragen“, sondern eher für die Mozilla Suite. Im Jahr 2000 war man schon ziemlich weit in der Mozilla-Ära, und ich glaube auch nicht, dass Netscape-Bugs in Bugzilla gelandet wären
    • Wow, dieser Bug ist älter als Firefox selbst
    • Als Nächstes sind die projektübergreifenden Versions-Tickets in Jira dran

  • Etwas abseits des Themas, aber ich hasse diesen Trend zu menschenlesbaren Zeitangaben wie „vor einem Monat“ wirklich. Zeigt mir einfach das Datum, dann kann ich selbst rechnen
    Outlook, zumindest die Mac-Version, ist am schlimmsten. Bei Mails vor heute steht zum Beispiel nur „gestern“, und erst wenn man die Mail anklickt, sieht man auch die Uhrzeit. Ich bekomme an einem Tag Dutzende Mails; wenn dann 50 Nachrichten hintereinander nur als „gestern“ angezeigt werden, ist das völlig nutzlos

    • Schön wäre es, wenn beim Darüberfahren mit der Maus über die menschenlesbare Anzeige der exakte Zeitstempel erscheint
    • Ich hoffe wirklich, dass dieser Trend bald verschwindet. Ob eine Mail an diesem Tag um 6 Uhr morgens oder um 23 Uhr kam, ist ein riesiger Unterschied. Nur „gestern“ zu sagen, reicht nicht
      Bier kalt, Zeitstempel exakt – so ist es gut
    • Noch schlimmer ist es, wenn es auch noch falsch ist. Discogs behauptet, Oktober 2021 sei „vor über 3 Jahren“ gewesen
    • „Zeigt mir einfach das Datum, dann kann ich selbst rechnen“ ist für mich wirklich schwierig. Ich habe ziemlich große Schwierigkeiten mit Daten und dem Konzept des Zeitverlaufs an sich
    • Wenn man mit der Maus über das Datum fährt, sieht man das genaue Datum und die Uhrzeit

  • Firefox’ Bugzilla ist definitiv einer der am längsten laufenden Bugtracker. Beeindruckend ist, dass er trotz zahlloser Überarbeitungen noch ziemlich viel vom ursprünglichen Gefühl behalten hat. Früher war das eine ziemlich raue, monströse Codebasis
    Um 2000 herum habe ich in einer Windows-Entwicklungsorganisation eine Instanz aufgesetzt, um einen eigenen Bugtracker auf Basis von Microsoft Access/Outlook zu ersetzen. Er war komplex, aber eine Zeit lang gehörte er praktisch zur Spitzenklasse der Bugtracker. FogBugz fing damals ebenfalls gerade an, und ich würde sagen, dieses Team gehörte zu den frühen Teams, die User Experience ernsthaft berücksichtigt haben

    • Auch heute ist Bugzilla nicht leicht zu schlagen. Tatsächlich sind manche heutige Alternativen so viel schlechter als Bugzilla, dass ich kaum verstehe, wie sie überhaupt existieren. Mantis BT, das Dwarf Fortress verwendet, ist zum Beispiel wirklich miserabel
      FogBugz dagegen war ein Tool, das ich bei Gelegenheit immer schon einmal ausprobieren wollte

  • So etwas wärmt einem das Herz. Kürzlich habe ich bei einem 24 Jahre alten Firefox-Bug etwas Ähnliches erlebt: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • Verdammt, ich erinnere mich, dass ich deswegen festhing und herumirrte

  • Bei den lange ungelösten Bugs nervt mich am meisten, dass man in LibreOffice die x-Achse eines Streudiagramms nicht richtig als Datumsformat festlegen kann
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    Ein 12 Jahre alter Bug. Den Kommentaren nach zu urteilen ist der Code so „furchtbar kompliziert“, dass man eine Behebung scheut, weil sie wahrscheinlich Regressionen verursachen würde

    • Ich hatte gehofft, LibreOffice würde die Excel-Funktionen übernehmen, die ich mag, aber das hier dämpft meine Erwartungen
    • Wenn man nur eine Tabellenkalkulation und ein Paket zum Erstellen von Diagrammen braucht, ist gnumeric unter Linux eine gute Wahl
    • Es ist schon schön, wenn Maintainer Angst vor Code bekommen, dessen Merge sie selbst zugelassen haben

  • Als Nächstes hätte ich gern XDG. Darauf warte ich auch schon seit 20 Jahren [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • Ich glaube nicht, dass die XDG Base Directories jemals vollständig und allgemein übernommen werden. Es sind schon 21 Jahre vergangen. Wenn Arch Linux Programmen, die sich nicht daran halten, nicht aggressiv begegnet wäre — etwa indem es die Berechtigungen des Root-Benutzerverzeichnisses sperrt —, wäre es in letzter Zeit auch nicht so groß geworden
      Ehrlich gesagt löst diese Spezifikation reale Probleme, die Menschen haben, nicht aktiv. Der Großteil der Adoption ist das Ergebnis davon, dass Leute, die sich an der Struktur ihres $HOME-Verzeichnisses stören, Maintainer nervig unter Druck gesetzt haben; 99 % der Nutzer ist es egal, ob ein Programm die XDG Base Directories befolgt oder nicht. Es dient im Grunde nur dazu, anhand einer freedesktop-Spezifikation, die seit über 20 Jahren nicht breit angenommen wurde, behaupten zu können, es sei „aufgeräumter“
      Persönlich mag ich diese lockere Trennung von Konfiguration/Daten/Cache und die implizite Absicht dahinter nicht. Nicht alles passt in diese Kategorien, und dadurch wird das Systemverhalten schwer vorhersehbar. Wird ein Daemon meinen Cache löschen? Werden Nutzer ihren Konfigurationsordner herumkopieren? Was genau wird gesichert? Die Spezifikation enthält keinen Standard dafür, wie die Ordner tatsächlich behandelt werden sollen. Sie ist absichtlich vage, aber auf eine Weise vage, die kaputtgehen kann, wenn Leute Annahmen treffen
      Es ist ähnlich wie /usr von Root zu trennen, /usr/local von Root zu trennen oder /opt zu haben. Relikte einer vergangenen Ära bleiben weiter bestehen, und es fühlt sich an, als wolle man noch eines schaffen
      In unserem Produkt unterstützen wir es widerwillig auch, aber nur, wenn die entsprechenden Umgebungsvariablen explizit gesetzt sind. Das XDG-Verhalten, wonach auf allen Linux-Systemen bestimmte Defaults gelten sollen, wenn sie nicht gesetzt sind, ignorieren wir zu 100 %. Denn es unterscheidet sich von dem, was andere UNIX-artige Systeme wie macOS erwarten. Wir haben gerade genug eingebaut, um zu verhindern, dass Arch-Linux-Enthusiasten jede Woche in unserem Bugtracker auftauchen und die Übernahme fordern; sie machen nicht einmal 1 % unserer Nutzer aus. Es ist schon schwer genug, den Nutzern per Dokumentation zu erklären, wo sie die Dateien unseres Produkts auf ihrem System finden. Nutzer kennen XDG nicht immer, und für die meisten ist XDG auch keine bereits erwartete, etablierte Konvention. Abgesehen von Leuten, die ein sauberes Benutzerverzeichnis wollen, bietet es keinen starken Wert, und es gibt zu viel Altlast, um alle auf diese Spezifikation umzuziehen
      Ehrlich gesagt sollte man das Ganze neu denken und zu einer containerbasierten Lösung übergehen, bei der Desktop-Apps nicht aus ihrem kleinen Gefängnis ausbrechen können. Ziemlich ähnlich wie bei Snap-Apps. Von Nix könnte man vielleicht auch etwas lernen. Man muss anerkennen, dass es gescheitert ist, alle Linux-User-Apps weltweit dazu zu bringen, sich um die XDG Base Directories — oder sogar um das Benutzerverzeichnis — zu kümmern und sie zu übernehmen. Schon die Unterstützung von Ports für Mac und Windows ist schwer genug, und die folgen diesem Verhalten nicht. Wir sollten vom UNIX-Rechtemodell wegkommen, bei dem Programme mit Benutzerrechten laufen, und jedes Programm unter einer eigenen uid ausführen. Android funktioniert so
    • Stimmt, darauf warte ich auch

  • Bitte behebt den Bug, bei dem die Kopieroption zufällig deaktiviert ist, obwohl es Text zum Kopieren gibt. Das macht mich wirklich wahnsinnig

    • Gut zu wissen, dass ich nicht der Einzige bin
    • Mal sehen, ob das innerhalb von 25 Jahren behoben wird. Für das heutige schnelle Web-Umfeld ist Mozilla manchmal einfach zu langsam

  • AWS löst dieses Problem, indem es alte Bugs und alle Erwähnungen davon regelmäßig löscht

    • Die Straußenstrategie, Bugs auszuweichen

  • Verwandter Beitrag vom letzten August:
    Happy 25th Birthday to Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • Cool! Allerdings ist der 28.03.2000 noch nicht 25 Jahre her

    • Wenn man es so hört, ist das eine ziemlich seltsame Rundung
    • Stimmt. Ehrlich gesagt hätte ich an ihrer Stelle noch ein paar Monate gewartet und es passend zum Silberhochzeits-Jubiläum gefixt :P