Le bug `<textarea>` de Firefox corrigé après 25 ans

 (bugzilla.mozilla.org)
1 points par GN⁺ 2024-05-23 | 1 commentaires | Partager sur WhatsApp
  • L’ancien bug 33654 de Firefox concernait le fait que <textarea> ajoutait aussi l’espace des barres de défilement lors de l’application de ROWS= et COLS=, ce qui l’affichait plus grand que le nombre de lignes et de colonnes demandé ; il est désormais fermé comme doublon du bug 1830576
  • Dans les environnements où les overlay scrollbars sont désactivées ou où le réglage « toujours afficher les barres de défilement » est activé, <textarea rows=N> était régulièrement calculé avec une hauteur d’environ N+1 lignes
  • Les premières discussions se sont étendues à l’héritage des polices, à l’application forcée de monospace, au calcul de cols fondé sur la largeur moyenne de w et W, ainsi qu’à la façon de réserver l’espace des barres de défilement ; des cas de test, correctifs et captures d’écran se sont accumulés pendant longtemps
  • Concrètement, rows=1 pouvait paraître faire 3 lignes, rows=2 s’afficher avec une hauteur de 3 lignes, et avec cols=80, l’emplacement du retour à la ligne différait entre IE et Firefox, ce qui désalignait le contrôle de mise en page des formulaires selon les navigateurs
  • Avec le passage du bug 1830576 à l’état VERIFIED FIXED, l’application de l’espacement des barres de défilement est devenue cohérente entre WebKit, Chromium et Firefox, et le bug 33654 a été reclassé en RESOLVED DUPLICATE

État et périmètre du bug 33654

  • Bug 33654 correspondait à un défaut où <textarea> appliquait incorrectement ROWS= et COLS=, en ajoutant un espace supplémentaire pour les barres de défilement horizontales et verticales lorsque les overlay scrollbars étaient désactivées
  • Le produit et composant sont Core :: Layout: Form Controls, couvrant la mise en page et l’apparence des contrôles de formulaire HTML, notamment des éléments comme textarea
  • Son état actuel est RESOLVED DUPLICATE of bug 1830576
    • Le titre du bug de référence, 1830576, est Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • Le bug 1830576 est à l’état VERIFIED FIXED
  • Le bug a été ouvert il y a 26 ans et fermé comme RESOLVED DUPLICATE il y a 2 ans
  • Les métadonnées indiquent la version Trunk, la plateforme x86 / All, le type defect, la priorité P3 et la sévérité S3
  • Les mots-clés incluent testcase, le Whiteboard est [html][behavior]relnote-devel, et le nombre de votes affiché est 99
  • Les pièces jointes sont indiquées comme 17 files, 17 obsolete files, avec un historique répété d’ajouts de cas de test, de patches et de captures d’écran

Les premiers symptômes observés

  • Dans le signalement initial, Andrew McMillan indiquait qu’un exemple de TEXTAREA défini avec ROWS=5 COLS=30 s’affichait plutôt comme un ROWS=7 COLS=48
  • Les premiers commentaires relayaient aussi des cas où INPUT TYPE=TEXT et TEXTAREA n’utilisaient pas correctement la police spécifiée, ou bien où la zone restait trop haute même quand la barre de défilement apparaissait
  • La discussion a ensuite convergé vers l’idée que la mise en page du textarea recevait de mauvaises informations, avec un espace supplémentaire dans les colonnes et une ligne de plus dans les rangées
  • La possibilité que cela vienne d’une réservation anticipée de l’espace destiné aux barres de défilement a également été évoquée très tôt

Calcul des polices et premiers correctifs

  • Dans un cas issu du groupe de discussion HTML authoring, l’usage conjoint de textarea { font-size: 8pt } et de <textarea cols="40" rows="12"> montrait qu’IE rendait la largeur correctement, alors que Mozilla semblait la calculer comme si la police était en 12pt
  • Un fichier de test utilisant la police arial contenait <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial">
  • Rod estimait que le calcul de taille était correct avec la police par défaut, et que le vrai problème tenait davantage au fait que le textarea n’utilisait pas la bonne police
  • Kin a découvert que lorsque l’indicateur PlainText de l’éditeur était activé, du code forçait font-family: monospace; sur la zone de contenu du TextControl
    • En retirant ce code, la bonne police était utilisée
    • Mais en mode NavQuirks, une chaîne de 30 caractères dans un textarea de 30 colonnes n’occupait encore qu’environ les 2/3 de la largeur
    • La cause pointée était la manière dont nsFormControlHelper calculait la largeur du textarea en prenant la largeur moyenne de w et W dans la police, en la multipliant par le nombre de colonnes, puis en ajoutant la largeur de la barre de défilement
  • Le correctif Patch to use the correct font. ajoutait eEditorEnableWrapHackMask aux indicateurs d’initialisation de l’éditeur plain text et limitait conditionnellement l’application de font-family: monospace;
  • Ce patch a un temps conduit à l’état RESOLVED FIXED, mais le rapporteur d’origine a signalé que si COLS=... semblait correct, ROWS=... restait erroné, ce qui a rouvert le bug

Reproductions répétées et bugs en doublon

  • La liste des bugs en doublon comprend de nombreux cas où <textarea> paraissait avoir une ligne de plus que demandé, ou où rows=1 semblait faire 3 lignes
    • 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 !
  • Le cas de test interactif était un document HTML 4.01 Strict permettant de modifier rows et cols via des boutons, sans utiliser de balise de police ni de police à largeur variable
    • Le résultat montrait toujours 3 colonnes de plus que la valeur demandée, et généralement 1 ligne de plus
    • En demandant rows=1, 3 lignes étaient affichées
  • Sur des builds trunk Linux et Win2000 de 2002, on rapportait que <textarea cols=40 rows=2></textarea> s’affichait sur 3 lignes, et qu’avec rows=N, on obtenait exactement N+1 lignes
  • Les tests W3C HTML 4.01 servaient aussi de référence, avec des commentaires indiquant que le problème était particulièrement visible dans les tests liés à ROWS
  • Sous Windows 2000 et Mozilla 0.9.3, des exemples montraient également qu’un textarea rows=1 ne paraissait clairement pas faire une seule ligne

Débat sur le calcul de l’espace des barres de défilement

  • Le commentaire 86 expliquait que la taille du textarea était calculée comme la valeur de cols/rows demandée plus l’espace des barres de défilement
  • À la différence d’IE, Mozilla n’affichait les barres de défilement que lorsqu’elles étaient nécessaires, ce qui amenait les utilisateurs à percevoir ce comportement comme cassé
  • Trois options possibles ont été proposées
    • Ne pas ajouter la taille des barres de défilement lors du calcul du textarea
    • Toujours afficher les barres de défilement, comme IE
    • N’inclure que les barres de défilement effectivement affichées
  • La troisième option a été critiquée car la taille dépendrait alors de l’affichage des barres, tandis que l’affichage des barres dépend lui-même de la taille, créant une dépendance circulaire
  • Le commentaire 87 proposait une quatrième option : faire en sorte que ROWS et COLS ne contrôlent que la taille du contenu du textarea, et que le textarea s’agrandisse si les barres de défilement apparaissent
  • La direction prise ensuite pour l’implémentation consistait à effectuer un reflow avec une largeur/hauteur sans barres de défilement pour déterminer si elles étaient nécessaires, puis à refaire un reflow avec les nouvelles dimensions si besoin

Impact visible pour les utilisateurs

  • Quand rows="2" produisait un textarea haut de 3 lignes, l’intention de guider visuellement la quantité de texte attendue devenait floue
    • Une application web demandait un court texte de résumé et utilisait rows="2" pour suggérer une saisie « plus qu’une ligne, mais pas une dissertation »
    • En raison des différences de comportement entre Firefox, IE6 et Opera 8, une même valeur rows produisait des indications visuelles différentes selon l’agent utilisateur
  • Des commentaires ont aussi souligné que le comportement de Firefox restait incorrect même quand le contenu du textarea ne nécessitait aucun défilement
    • Pour un champ d’adresse censé rarement dépasser trois lignes, définir rows="3" conduisait malgré tout Firefox à afficher systématiquement une ligne supplémentaire
    • La page devenait inutilement plus grande, et l’utilisateur pouvait penser que le champ, plus haut que prévu, n’avait pas encore été suffisamment rempli
  • Dans la comparaison avec cols=80, une capture expliquait qu’IE remplissait 80 caractères 1 jusqu’au bord de la barre de défilement avant de passer à la ligne, tandis que Firefox laissait encore la place pour 2 caractères après les 80 1, puis affichait une barre de défilement horizontale
  • En 2019, des commentaires signalaient encore la présence du problème, et la carte Trello de Discord Chat bar is a line taller than usual on Firefox était citée comme exemple d’impact

Des tentatives de correction sur la durée

  • Hideo Saito a joint à plusieurs reprises des patches et cas de test
    • patch for rows and cols
    • cas de test du patch wrap="off"
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • Une approche consistait à faire exécuter nsTextControlFrame::Reflow avec une intrinsic size excluant les barres de défilement, puis, si celles-ci étaient présentes, à leur ajouter leur taille avant de relancer le reflow
  • Une autre approche examinée consistait à modifier GetScrollbarStyles pour permettre au text control frame de choisir entre auto, hidden et scroll pour les barres de défilement
  • roc préférait une solution traitée dans nsTextControlFrame plutôt qu’une approche introduisant de nombreux changements dans nsGfxScrollFrame
  • Les patches ultérieurs ont fait l’objet de plusieurs cycles de revue et de reprise autour de mécanismes comme SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow et les callbacks post-reflow
  • Certains patches ont reçu un review- ou ont été rendus obsolètes, les relecteurs signalant la nécessité de mises à jour adaptées au trunk

Contournements temporaires et limites

  • Il a été proposé d’ajouter textarea{ overflow-x: hidden } en CSS pour corriger le problème
  • Cette méthode n’était valable qu’à condition qu’aucune barre de défilement horizontale ne soit nécessaire
  • D’autres commentaires ont rétorqué que ce bug ne pouvait pas être corrigé via le seul overflow CSS, et que Firefox était le seul navigateur à rendre les textarea avec une ligne supplémentaire
  • Emilio Cobos Álvarez a indiqué que la cause semblait liée à la taille des barres de défilement et qu’appliquer scrollbar-width: none à <textarea> semblait résoudre le problème
  • Le même commentaire ajoutait cependant que le bug devait malgré tout être corrigé proprement

Conclusion

  • Il y a 3 ans, BugBot notait que la sévérité de ce bug était relativement faible (S3), mais qu’il comptait 27 doublons, 103 votes et 91 personnes en CC, et demandait s’il fallait envisager une hausse de sévérité
  • Le résumé du bug a été modifié de TEXTAREA incorrectly applying ROWS= and COLS= en TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled)
  • Daniel Holbert a ajouté comme dépendance le bug 1830576, Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
  • Luke Warlow a demandé si le bug 33654 pouvait être fermé maintenant que le bug 1830576 avait été corrigé, puisque l’application de l’espacement des barres de défilement était désormais cohérente entre WebKit, Chromium et Firefox
  • Emilio Cobos Álvarez a approuvé cette conclusion, et le bug 33654 est passé de NEW à RESOLVED avant d’être fermé comme DUPLICATE
  • Le doublon retenu est le bug 1830576, qui est à l’état VERIFIED FIXED

À lire aussi

1 commentaires

 
GN⁺ 2024-05-23
Commentaires sur Hacker News

  • Ha ! J’ai suivi ce bug pendant la majeure partie de ces 25 ans. À l’époque, Firefox n’existait pas encore, et il avait été enregistré côté Mozilla, avant ou après cette période, plutôt que pour Netscape Navigator
    Je ne me souviens plus pourquoi je le suivais, mais j’ai sans doute laissé un commentaire. Tous les quelques années, je recevais un mail de notification et ça me faisait toujours rire, puis il a enfin été corrigé il y a quelques jours

    • Ce qui est étonnant, c’est que l’abonnement à ce fil de bug ait survécu pendant tout ce temps
    • Pareil pour moi. Je me souviens qu’à l’époque où j’envisageais pour la première fois de travailler dans la création de sites web, j’étais fasciné par l’idée de sites dont l’arrière-plan serait transparent ou semi-transparent jusqu’au bureau lui-même
      Je me suis toujours dit que quelque chose comme html { background: transparent; } devrait simplement fonctionner. Cela dit, cette correction de bug ne fait pas vraiment cela. D’abord, ce n’est pas une fonctionnalité activée par défaut par les sites web, mais un réglage que l’utilisateur ou une extension peut activer. C’est probablement mieux ainsi, car si c’était autorisé par défaut, cela aurait ouvert une nouvelle voie au clickjacking
    • Plutôt que « enregistré pour Netscape Navigator », c’était du côté de Mozilla Suite. En 2000, on était déjà bien entrés dans l’ère Mozilla, et il est peu probable que des bugs Netscape aient été dans Bugzilla
    • Waouh, ce bug est plus vieux que Firefox lui-même
    • Au tour maintenant des tickets de version inter-projets de Jira d’être résolus

  • C’est un peu hors sujet, mais je déteste vraiment cette mode des indications de durée lisibles par les humains comme « il y a un mois ». Affichez juste la date et je ferai le calcul moi-même
    Outlook, au moins sur Mac, est le pire. Les mails d’avant aujourd’hui apparaissent par exemple juste comme « hier », et il faut cliquer sur le message pour voir jusqu’à l’heure. Je reçois des dizaines de mails par jour, donc voir 50 messages d’affilée marqués seulement « hier » ne sert à rien

    • Ce serait bien si le survol d’une indication lisible par un humain affichait le horodatage exact
    • Franchement, j’aimerais que cette mode disparaisse vite. Savoir si un mail est arrivé à 6 h du matin ou à 23 h fait une énorme différence. Afficher simplement « hier » ne suffit pas
      La bière doit être fraîche, et les horodatages précis
    • C’est encore pire quand c’est faux. Discogs prétend qu’octobre 2021 date de « plus de 3 ans »
    • Le « affichez juste la date et je ferai le calcul moi-même » est vraiment difficile pour moi. J’ai beaucoup de mal avec les dates et même avec la notion de passage du temps
    • En survolant la date, on voit la date et l’heure exactes

  • La Bugzilla de Firefox fait clairement partie des suivis de bugs les plus anciens encore en activité. Elle a connu d’innombrables révisions, et il est impressionnant qu’elle ait conservé autant de sa sensation d’origine. Avant, c’était une base de code assez brute, presque monstrueuse
    Vers 2000, dans une organisation de développement Windows, nous avons déployé une instance pour remplacer un outil interne de suivi de bugs basé sur Microsoft Access/Outlook. C’était complexe, mais pendant un temps c’était pratiquement ce qui se faisait de mieux en matière de suivi de bugs. FogBugz commençait tout juste à cette époque, et je pense que leur équipe a été l’une des premières à prendre vraiment l’expérience utilisateur au sérieux

    • Même aujourd’hui, Bugzilla reste difficile à battre. En fait, certaines options récentes sont tellement pires que Bugzilla qu’on se demande comment elles peuvent exister. Mantis BT, par exemple, utilisé par Dwarf Fortress, est vraiment lamentable
      À l’inverse, FogBugz est un outil que j’ai toujours eu envie d’essayer dès que l’occasion se présenterait

  • Ce genre de chose me réchauffe le cœur. J’ai récemment vécu quelque chose de similaire avec un bug Firefox vieux de 24 ans : https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • Bon sang, je me souviens avoir galéré et tourné en rond à cause de ça

  • Parmi les bugs non résolus de longue date, le plus agaçant pour moi est l’impossibilité dans LibreOffice de définir correctement l’axe x d’un nuage de points au format date
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    C’est un bug vieux de 12 ans. À en juger par les commentaires, le code est si « horriblement complexe » qu’ils hésitent à le corriger, de peur de provoquer des régressions

    • J’espérais que LibreOffice reprendrait certaines fonctionnalités d’Excel que j’aime bien, mais en voyant ça, j’y crois moins
    • Si vous n’avez besoin que d’un tableur et d’un outil de graphiques, gnumeric est un bon choix sous Linux
    • C’est toujours agréable quand les mainteneurs finissent par avoir peur du code qu’ils ont eux-mêmes accepté de fusionner

  • La prochaine fois, j’aimerais qu’ils s’attaquent à XDG. Ça aussi, on l’attend depuis 20 ans [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • Je pense que les répertoires par défaut XDG ne seront jamais adoptés de manière complète et universelle. Ça fait déjà 21 ans. Si Arch Linux n’avait pas été aussi agressif envers les programmes qui ne les respectent pas, par exemple en verrouillant les permissions du répertoire personnel de root, ça ne se serait probablement jamais autant répandu récemment
      Honnêtement, cette spécification ne résout pas activement de vrais problèmes rencontrés par les gens. L’essentiel de son adoption vient de personnes agacées par l’organisation du répertoire $HOME qui ont harcelé les mainteneurs, et 99 % des utilisateurs se moquent de savoir si un programme respecte ou non les répertoires par défaut XDG. Cela sert surtout à pouvoir dire que c’est « plus propre », conformément à une spécification freedesktop qui n’a jamais été largement adoptée en plus de 20 ans
      Personnellement, je n’aime pas cette séparation floue entre configuration, données et cache, ni les intentions implicites qu’elle véhicule. Tout ne rentre pas dans ces catégories, et cela rend alors le comportement du système difficile à prévoir. Un démon va-t-il effacer mon cache ? L’utilisateur va-t-il copier partout son dossier de configuration ? Qu’est-ce qui sera sauvegardé exactement ? La spécification ne standardise pas la façon dont ces dossiers doivent réellement être traités. C’est volontairement vague, mais d’une manière qui casse dès que les gens commencent à faire des suppositions
      C’est un peu comme séparer /usr de la racine, ou /usr/local de la racine, ou avoir /opt. On a l’impression d’essayer de créer encore une nouvelle relique d’une époque révolue qui continue de traîner
      Dans notre produit aussi, on le prend en charge à contrecœur, mais uniquement si les variables d’environnement concernées sont explicitement définies. Quand elles ne le sont pas, on ignore à 100 % le comportement XDG qui dit que cela devrait être la valeur par défaut sur tous les systèmes Linux. Parce que ce n’est pas comme ça que d’autres UNIX, comme macOS, sont censés fonctionner. On a juste ajouté ce qu’il fallait pour éviter que des passionnés d’Arch Linux débarquent chaque semaine sur le bug tracker pour exiger son adoption, alors qu’ils représentent moins de 1 % de l’ensemble des utilisateurs. C’est déjà assez difficile de documenter où les utilisateurs doivent chercher les fichiers de notre produit sur leur système. Les utilisateurs ne connaissent pas toujours XDG, et pour la plupart ce n’est déjà pas une convention établie qu’ils attendent. À part pour ceux qui veulent un répertoire personnel propre, ça n’apporte pas une valeur forte, et il y a trop d’héritage pour faire basculer tout le monde vers cette spécification
      Honnêtement, il faudrait tout repenser et aller vers une solution basée sur des conteneurs où les applications desktop ne peuvent pas sortir de leur petite prison. Quelque chose de très proche des applis snap. On pourrait aussi apprendre un peu de Nix. Il faut reconnaître comme un échec l’idée de faire en sorte que toutes les applications utilisateur Linux du monde prêtent attention aux répertoires par défaut XDG, voire même au répertoire personnel, et les adoptent. C’est déjà assez difficile de prendre en charge les ports Mac et Windows, qui ne suivent pas ce comportement. Il faut sortir du modèle de permissions UNIX où les programmes s’exécutent avec les droits de l’utilisateur, et faire tourner chaque programme sous son propre uid. C’est comme ça qu’Android fonctionne
    • Oui, moi aussi j’attends ça

  • J’aimerais vraiment qu’ils corrigent le bug où l’option de copie se désactive aléatoirement alors qu’il y a bien du texte à copier. C’est à devenir fou

    • Ça me rassure de ne pas être le seul à l’avoir
    • On verra si ce sera corrigé d’ici 25 ans. Mozilla est parfois trop lent au vu du rythme actuel du web

  • AWS résout ce problème en supprimant périodiquement les vieux bugs et toutes les mentions qui en parlent

    • La stratégie de l’autruche pour éviter les bugs

  • Un article lié en août dernier :
    Happy 25th Birthday to Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • Sympa ! Mais le 2000-03-28, ce n’est pas encore il y a 25 ans

    • Maintenant que tu le dis, c’est une méthode d’arrondi assez bizarre
    • Oui. Honnêtement, à leur place, j’aurais attendu quelques mois de plus pour le corriger pile pour les noces d’argent :P