El bug de Firefox en `<textarea>` corregido después de 25 años

 (bugzilla.mozilla.org)
1 puntos por GN⁺ 2024-05-23 | 1 comentarios | Compartir por WhatsApp
  • El antiguo Bug 33654 de Firefox era un problema en el que <textarea> se mostraba más grande que las filas y columnas especificadas al aplicar ROWS= y COLS= porque también sumaba el espacio de la barra de desplazamiento, y ahora se cerró como duplicado de Bug 1830576
  • En entornos donde las overlay scrollbars están desactivadas o se usa la opción “always show scrollbars”, se repetía el fenómeno de que <textarea rows=N> se calculaba con una altura de aproximadamente N+1 filas
  • La discusión inicial se amplió a la herencia de fuentes, la aplicación forzada de monospace, el cálculo de cols basado en el ancho promedio de w y W, y la forma de reservar espacio para la barra de desplazamiento; durante mucho tiempo se acumularon casos de prueba, parches y capturas de pantalla
  • En la práctica, rows=1 podía verse como de 3 filas o rows=2 como de 3 filas de alto, y en cols=80 la posición del salto de línea difería entre IE y Firefox, desajustando el control del layout de formularios entre navegadores
  • Cuando Bug 1830576 pasó a VERIFIED FIXED, la aplicación del espacio de la barra de desplazamiento quedó consistente entre WebKit, Chromium y Firefox, y Bug 33654 se ordenó como RESOLVED DUPLICATE

Estado y alcance de Bug 33654

  • Bug 33654 era un defecto por el cual <textarea> aplicaba incorrectamente ROWS= y COLS=, generando espacio adicional para las barras de desplazamiento horizontal y vertical cuando las overlay scrollbars estaban desactivadas
  • El producto y componente son Core :: Layout: Form Controls, que cubre el layout y la apariencia de los controles de formulario HTML, en particular elementos como textarea
  • Su estado actual es RESOLVED DUPLICATE of bug 1830576
    • El título del bug duplicado, Bug 1830576, es Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • El estado de Bug 1830576 es VERIFIED FIXED
  • El bug se abrió hace 26 años y se cerró hace 2 años como RESOLVED DUPLICATE
  • En los metadatos figuran versión Trunk, plataforma x86 / All, tipo defect, prioridad P3 y severidad S3
  • La palabra clave es testcase, el Whiteboard es [html][behavior]relnote-devel, y el número de votos aparece como 99
  • Los adjuntos figuran como 17 files, 17 obsolete files, con una carga repetida de casos de prueba, parches y capturas de pantalla

Los primeros síntomas detectados

  • En el reporte inicial, Andrew McMillan señaló que un ejemplo de TEXTAREA definido con ROWS=5 COLS=30 se mostraba aproximadamente como ROWS=7 COLS=48
  • En los primeros comentarios se sucedieron casos en los que INPUT TYPE=TEXT y TEXTAREA no usaban correctamente la fuente especificada, o el área era demasiado alta incluso cuando aparecía la barra de desplazamiento
  • Después, la discusión convergió en que el layout de textarea estaba recibiendo información incorrecta: había espacio extra en las columnas y una fila adicional
  • Desde temprano también se consideró como posible causa la forma de reservar anticipadamente espacio para la barra de desplazamiento

Cálculo de fuentes y parches iniciales

  • En un caso del newsgroup de HTML authoring, al usar textarea { font-size: 8pt } junto con <textarea cols="40" rows="12">, IE renderizaba el ancho correctamente, pero Mozilla parecía calcularlo con base en una fuente de 12pt
  • Un archivo de prueba que usaba la fuente arial incluía <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial">
  • Rod consideró que, como el cálculo de tamaño era correcto con la fuente predeterminada, el problema central no era tanto el sizing sino que textarea no estaba usando la fuente correcta
  • Kin encontró código que forzaba font-family: monospace; en el área de contenido de TextControl cuando estaba activado el flag PlainText del editor
    • Al eliminar ese código, se usaba la fuente correcta
    • Sin embargo, en modo NavQuirks seguía quedando el problema de que una cadena de 30 caracteres dentro de un textarea de 30 columnas ocupaba solo alrededor de 2/3 del ancho
    • Como causa se apuntó al método de nsFormControlHelper, que calculaba el ancho del textarea tomando el ancho promedio de w y W de la fuente, multiplicándolo por el número de columnas y sumando el ancho de la barra de desplazamiento
  • Patch to use the correct font. agregaba eEditorEnableWrapHackMask a los flags de inicialización del editor de texto plano y restringía condicionalmente la aplicación de font-family: monospace;
  • Ese parche llegó a marcarse como RESOLVED FIXED, pero se reabrió cuando el reportero original indicó que COLS=... estaba bien, pero ROWS=... seguía funcionando mal

Reproducción repetida y bugs duplicados

  • La lista de bugs duplicados incluía muchos casos donde <textarea> se veía una línea más alto que lo indicado o rows=1 aparecía como si tuviera 3 líneas
    • 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 !
  • El interactive testcase era un documento HTML 4.01 Strict donde los valores de rows y cols podían cambiarse con botones, y no usaba font tag ni fuentes de ancho variable
    • El resultado era que siempre se mostraban 3 columnas más de las especificadas, y normalmente 1 fila más
    • Si se pedía rows=1, se mostraban 3 filas
  • En builds trunk de Linux y Win2000 de 2002, se reportó que <textarea cols=40 rows=2></textarea> se mostraba con 3 filas, y que con rows=N aparecían exactamente N+1 filas
  • También se usó como referencia la prueba de W3C HTML 4.01, y hubo comentarios señalando que el problema se veía claramente en la prueba relacionada con ROWS
  • En Windows 2000 y Mozilla 0.9.3 también se compartieron ejemplos donde un textarea con rows=1 claramente no se veía como de 1 fila

Debate sobre el cálculo del espacio para la barra de desplazamiento

  • El Comment 86 explicaba que el tamaño del textarea se calculaba como el valor especificado de cols/rows más el espacio de la barra de desplazamiento
  • A diferencia de IE, Mozilla mostraba la barra de desplazamiento solo cuando era necesaria, por lo que los usuarios percibían esto como un comportamiento roto
  • Se propusieron tres opciones posibles
    • No sumar el tamaño de la barra de desplazamiento al calcular el tamaño del textarea
    • Mostrar siempre la barra de desplazamiento, como IE
    • Incluir solo la barra de desplazamiento que vaya a mostrarse
  • A la tercera opción se le objetó que el tamaño dependería de si se muestra la barra de desplazamiento, y eso a su vez dependería otra vez del tamaño, creando una circularidad
  • El Comment 87 propuso como cuarta opción que ROWS y COLS controlaran solo el tamaño del contenido del textarea, y que si aparecía la barra de desplazamiento el textarea creciera
  • Después, la dirección de implementación pasó a discutirse como un proceso de hacer reflow con width/height sin barra de desplazamiento para determinar si esta era necesaria, y luego, si hacía falta, volver a hacer reflow con un nuevo width/height

Impacto visible para los usuarios

  • Si se especificaba rows="2" pero aparecía un textarea con altura de 3 filas, se desdibujaba la intención de guiar visualmente la cantidad de texto esperada
    • Una aplicación web pedía un texto breve de resumen y usaba rows="2" para sugerir una cantidad “más que una línea pero no un ensayo”
    • Debido a las diferencias entre Firefox, IE6 y Opera 8, el mismo valor de rows producía guías visuales distintas según el user agent
  • También continuaron comentarios diciendo que el comportamiento de Firefox era incorrecto incluso cuando el contenido del textarea no requería desplazamiento
    • Aunque se configurara rows="3" para un campo como una dirección, cuyo contenido rara vez superaría tres líneas, Firefox siempre mostraba una fila extra
    • La página se hacía innecesariamente más grande y el usuario podía pensar que todavía no había llenado suficiente información porque la caja era más grande de lo esperado
  • En la comparación con cols=80, se describía con capturas que IE hacía el salto de línea después de llenar hasta el borde de la barra de desplazamiento con 80 caracteres 1, mientras que Firefox dejaba espacio para 2 caracteres más después de esos 80 y luego mostraba una barra de desplazamiento horizontal
  • Incluso en 2019 seguían apareciendo comentarios indicando que el problema persistía, y se citó como ejemplo de impacto una tarjeta de Trello de Discord titulada Chat bar is a line taller than usual on Firefox

Intentos de parche durante muchos años

  • Hideo Saito adjuntó varias veces parches y casos de prueba
    • patch for rows and cols
    • testcase del parche de wrap="off"
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • Un enfoque consistía en ejecutar nsTextControlFrame::Reflow con un intrinsic size que excluyera la barra de desplazamiento y, si la barra existía, sumar su tamaño al intrinsic size y volver a hacer reflow
  • También se trató un enfoque que modificaba GetScrollbarStyles para que el text control frame pudiera controlar si la barra de desplazamiento sería auto, hidden o scroll
  • roc prefería resolverlo en nsTextControlFrame en lugar de introducir muchos cambios en nsGfxScrollFrame
  • Los parches posteriores repitieron revisiones y retrabajo alrededor de mecanismos como SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow y callbacks post-reflow
  • Algunos parches recibieron review- o quedaron obsoletos, y los revisores señalaron que hacía falta actualizarlos para el trunk

Soluciones temporales y límites

  • Hubo una sugerencia de que agregar CSS textarea{ overflow-x: hidden } resolvía el problema
  • Se aclaró que esto solo aplicaba cuando no era necesaria una barra de desplazamiento horizontal
  • Otros comentarios respondieron que este bug no podía corregirse solo con CSS overflow y que Firefox era el único navegador que renderizaba textarea agregando una línea extra
  • Emilio Cobos Álvarez comentó que la causa parecía ser el tamaño de la barra de desplazamiento y que aplicar scrollbar-width: none a <textarea> parecía resolverlo
  • Aun así, el mismo comentario añadía que el bug como tal debía corregirse

Cierre final

  • Hace 3 años, BugBot señaló que, aunque la severidad de este bug era relativamente baja (S3), tenía 27 duplicados, 103 votos y 91 personas en CC, y pidió revisar una posible subida de severidad
  • El resumen del bug cambió de TEXTAREA incorrectly applying ROWS= and COLS= a TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled)
  • Daniel Holbert añadió como dependencia Bug 1830576, Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
  • Luke Warlow preguntó si, dado que Bug 1830576 ya estaba corregido, podía cerrarse este bug porque la aplicación del espacio de la barra de desplazamiento ya era consistente entre WebKit, Chromium y Firefox
  • Emilio Cobos Álvarez estuvo de acuerdo, y Bug 33654 pasó de NEW a RESOLVED y se cerró como DUPLICATE
  • El duplicado quedó apuntando a Bug 1830576, cuyo estado es VERIFIED FIXED

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-05-23
Opiniones de Hacker News

  • ¡Ja! Estuve suscrito a este bug durante la mayor parte de esos 25 años. En ese entonces no existía Firefox, y esto se había registrado como un bug del lado de Mozilla, de antes o después, no de Netscape Navigator.
    No recuerdo por qué me suscribí, pero probablemente había dejado un comentario. Cada tantos años me llegaba un correo de notificación y siempre me daba risa; hace unos días por fin lo arreglaron.

    • Sorprende que la suscripción a ese hilo del bug haya sobrevivido durante tantos años.
    • Me pasó algo parecido. Recuerdo que, cuando recién consideraba dedicarme a crear sitios web, me fascinaba imaginar sitios cuyo fondo se viera transparente o semitransparente hasta el escritorio.
      Siempre pensé que algo como html { background: transparent; } simplemente debería funcionar. Aunque esta corrección de bug en realidad no hace eso. Para empezar, no es una función que los sitios web elijan por defecto, sino una configuración que puede activar el usuario o una extensión. Probablemente sea mejor así; si se permitiera por defecto, habría abierto una nueva vía para el clickjacking.
    • Más que “se registró para Netscape Navigator”, fue para Mozilla Suite. Para el año 2000 ya se estaba bastante dentro de la era Mozilla, y tampoco creo que los bugs de Netscape hubieran llegado a Bugzilla.
    • Guau, este bug es más viejo que el propio Firefox.
    • Lo siguiente es que se resuelva el ticket de versiones entre proyectos en Jira.

  • Me salgo un poco del tema, pero realmente odio la moda de mostrar duraciones fáciles de leer para humanos como “hace un mes”. Que muestren la fecha y ya; yo puedo hacer la cuenta.
    Outlook, al menos la versión para Mac, es lo peor. Los correos anteriores a hoy aparecen, por ejemplo, solo como “ayer”, y hay que hacer clic en el correo para ver también la hora. Recibo decenas de correos al día, así que si 50 mensajes aparecen en fila solo como “ayer”, no sirve para nada.

    • Estaría bien que al pasar el mouse sobre la indicación legible para humanos apareciera la marca de tiempo exacta.
    • De verdad espero que esta moda desaparezca pronto. Hay una diferencia enorme entre que un correo haya llegado a las 6 de la mañana o a las 11 de la noche de ese día. Decir simplemente “ayer” no alcanza.
      La cerveza, fría; las marcas de tiempo, exactas.
    • Es aún peor cuando además se equivoca. Discogs insiste en que octubre de 2021 fue “hace más de 3 años”.
    • Eso de “que muestren la fecha y ya; yo puedo hacer la cuenta” para mí es realmente difícil. Tengo bastantes problemas con el concepto de fechas o del paso del tiempo en sí.
    • Si pasas el mouse sobre la fecha, se ve la fecha y hora exactas.

  • Bugzilla de Firefox es sin duda uno de los rastreadores de bugs que llevan más tiempo en operación. Es impresionante que, pese a haber pasado por muchísimas revisiones, todavía conserve bastante de su sensación original. Antes era una base de código bastante áspera y monstruosa.
    Alrededor del año 2000, en una organización de desarrollo para Windows, monté una instancia para reemplazar un rastreador de bugs interno basado en Microsoft Access/Outlook. Era complejo, pero durante un tiempo fue casi de lo mejor en rastreadores de bugs. FogBugz también estaba empezando por esa época, y creo que ese equipo fue uno de los primeros en tomarse en serio la experiencia de usuario.

    • Incluso hoy no es fácil superar a Bugzilla. De hecho, algunas opciones actuales son tan peores que Bugzilla que no entiendo cómo existen. Por ejemplo, Mantis BT, que usa Dwarf Fortress, es realmente pésimo.
      En cambio, FogBugz es una herramienta que siempre quise probar si se me daba la oportunidad.

  • Cosas así calientan el corazón. Hace poco me pasó algo parecido con un bug de Firefox de 24 años: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • Maldición, recuerdo haberme quedado trabado y dando vueltas por culpa de esto.

  • Entre los bugs sin resolver de larga data, el que más me molesta es que en LibreOffice no se pueda configurar correctamente el eje x de un diagrama de dispersión con formato de fecha.
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    Es un bug de 12 años. Por los comentarios, parece que no quieren arreglarlo porque el código es demasiado “horriblemente complejo” y hay muchas probabilidades de que cualquier corrección introduzca regresiones.

    • Esperaba que LibreOffice incorporara las funciones que me gustan de Excel, pero al ver esto se me reducen las expectativas.
    • Si solo necesitas una hoja de cálculo y un paquete para hacer gráficos, en Linux gnumeric es una buena opción.
    • Me encanta cuando los mantenedores terminan teniendo miedo del código que ellos mismos permitieron fusionar.

  • Espero que la próxima vez se ocupen de XDG. También llevo 20 años esperando esto [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • No creo que los directorios base de XDG lleguen a adoptarse de forma completa y universal. Ya pasaron 21 años. Si Arch Linux no hubiera sido agresivo con los programas que no lo siguen —por ejemplo, bloqueando los permisos del directorio del usuario root—, ni siquiera habría crecido tanto como en los últimos tiempos.
      Sinceramente, esta especificación no resuelve de manera activa los problemas reales que tiene la gente. La mayor parte de la adopción es resultado de personas a las que les molesta la organización del directorio $HOME presionando insistentemente a los mantenedores, y al 99% de los usuarios no les importa si un programa sigue o no los directorios base de XDG. A lo sumo sirve para poder decir que es “más limpio”, siguiendo una especificación de freedesktop que no ha logrado una adopción amplia en más de 20 años.
      En lo personal, no me gusta esa separación laxa entre configuración/datos/caché ni sus intenciones implícitas. No todo encaja en esas categorías, y eso vuelve difícil predecir el comportamiento del sistema. ¿Un daemon va a borrar mi caché? ¿El usuario va a andar copiando su carpeta de configuración? ¿Exactamente qué se va a respaldar? La especificación no tiene un estándar sobre cómo deberían tratarse realmente las carpetas. Es ambigua a propósito, pero de una forma que puede romper cosas cuando la gente hace suposiciones.
      Es parecido a separar /usr de la raíz, separar /usr/local de la raíz, o tener /opt. Se siente como otro intento de crear un residuo de una época pasada que seguirá quedándose ahí.
      En nuestro producto también lo soportamos a regañadientes, pero solo cuando la variable de entorno correspondiente está configurada explícitamente. Ignoramos al 100% el comportamiento de XDG que dice que, si no está configurada, esos deberían ser los valores predeterminados en todos los sistemas Linux. Es porque difiere de lo que esperan otros sistemas tipo UNIX, como MacOS. Solo pusimos lo suficiente para evitar que los fanáticos de Arch Linux lleguen cada semana al rastreador de bugs a exigir que lo adoptemos, y ellos no llegan ni al 1% del total de usuarios. Ya es bastante difícil documentar dónde pueden encontrar los usuarios los archivos de nuestro producto en sus sistemas. Los usuarios no siempre conocen XDG, y para la mayoría XDG tampoco es una convención establecida que ya esperen. No tiene mucho valor salvo para quienes quieren un directorio de usuario limpio, y hay demasiado legado como para mover a todos a esta especificación.
      Sinceramente, habría que repensarlo todo e ir por una solución basada en contenedores en la que las apps de escritorio no puedan escapar de una pequeña cárcel. Algo muy parecido a las apps snap. También se podría aprender un poco de Nix. Hay que admitir que fue un fracaso intentar que todas las apps de usuario de Linux del mundo se preocupen por los directorios base de XDG, e incluso por el directorio de usuario, y los adopten. Ya es suficientemente difícil soportar ports para Mac y Windows, que no siguen este comportamiento. Hay que salir del modelo de permisos UNIX en el que los programas se ejecutan con permisos del usuario y ejecutar cada programa con su propio uid. Android funciona así.
    • Sí, yo también estoy esperando eso.

  • Ojalá arreglen el bug en el que la opción de copiar se desactiva aleatoriamente aunque haya texto para copiar. De verdad me vuelve loco.

    • Me alegra saber que no soy el único al que le pasa.
    • Habrá que ver si lo arreglan dentro de 25 años. Para los estándares del entorno web tan rápido de hoy, Mozilla a veces es demasiado lenta.

  • AWS resuelve este problema borrando periódicamente los bugs antiguos y todas las menciones a ellos.

    • Es la estrategia del avestruz para evitar los bugs.

  • Artículo relacionado de agosto pasado:
    Happy 25th Birthday to Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • ¡Genial! Aunque 2000-03-28 todavía no fue hace 25 años.

    • Ahora que lo dices, es una forma bastante rara de redondear.
    • Sí. Sinceramente, yo habría esperado unos meses más y lo habría arreglado para el aniversario de bodas de plata :P