El bug de tooltip de Firefox se corrige después de 22 años

 (bugzilla.mozilla.org)
1 puntos por GN⁺ 2023-10-11 | 1 comentarios | Compartir por WhatsApp
  • Aunque Firefox estuviera en segundo plano, el bug tooltip-ghost, que hacía que los tooltips quedaran al frente, fue seguido durante mucho tiempo en Bugzilla y terminó con estado VERIFIED FIXED en la rama Firefox 119
  • La reproducción inicial consistía en pasar el mouse sobre un enlace o ícono de la barra de herramientas para mostrar el tooltip y luego cambiar a otra app con Command-Tab o Alt-Tab; el tooltip no desaparecía
  • Hubo casos similares no solo en Mac OS X, Windows y Linux, sino también en Thunderbird, Sunbird y Lightning, y en Firefox 5.0.1 incluso bastaba con que el mouse pasara por encima de la ventana en segundo plano para activar el tooltip y el estado de mouseover
  • El parche final fue only show tooltip when document has focus, cambiando el comportamiento para que el tooltip se muestre solo cuando el documento tiene foco, y se integró en mozilla-central con la revisión 8ae372dc88d1
  • QA reprodujo el problema con Firefox 106.0.1 en Ubuntu 22.04 usando el procedimiento original y confirmó que ya no persistía en una build Nightly 120.0a1; después se vincularon por separado algunos bugs de regresión relacionados

Tooltips que quedan sobre Firefox cuando está en segundo plano

  • El Bug 148624 trata el problema de que los tooltips permanecen al frente incluso cuando Firefox está en segundo plano
  • El título original es Tooltips persist in foreground when Firefox is in background y su alias es tooltip-ghost
  • El estado es VERIFIED FIXED y el milestone objetivo es la rama 119
  • La clasificación es Core :: XUL, el tipo es defect y la severidad es S3

Procedimiento de reproducción inicial y comportamiento esperado

  • El entorno del primer reporte fue Mozilla/5.0 ... Mac OS X ... Gecko/20020602 BuildID: 2002060203
  • El procedimiento de reproducción era simple
    • Pasar el mouse sobre un ícono de la barra de herramientas o un enlace
    • Esperar a que aparezca el tooltip
    • Enviar Mozilla al segundo plano con Command-Tab
  • En la práctica, la pequeña caja amarilla del tooltip seguía visible al frente
  • El comportamiento esperado era que el tooltip desapareciera cuando Mozilla pasara a segundo plano
  • El autor original del reporte indicó que el tooltip solo desaparecía al volver a traer Firefox al frente y mover el mouse fuera de la barra de herramientas

Casos de reproducción continuados en varias plataformas

  • Tras la confirmación inicial, el alcance de la plataforma cambió de Mac OS X a All, y el mismo problema también se reprodujo en Windows XP y Windows 98
  • También siguieron apareciendo casos en 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 y Firefox 117.0
  • También se observó un comportamiento similar en Thunderbird, Sunbird y Lightning
    • En Thunderbird 2.0.0.17 y Lightning 0.9 se adjuntó un caso donde el tooltip de la ventana de tareas quedaba sobre la ventana de notificaciones
    • También se reprodujo en GNU/Linux con la combinación Thunderbird 102.4.1 y Firefox 106.0.1
    • También se envió un procedimiento de reproducción en Firefox 117.0 y Thunderbird 115.2.0, en entornos xfce y xfwm
  • Un usuario comentó que seguía ocurriendo en Firefox 115.0.2 con GNOME 44 y usaba como solución alternativa la configuración browser.chrome.toolbar_tips para desactivar por completo los tooltips

Impacto más allá del tooltip persistente

  • No solo persistía un tooltip ya mostrado; también se confirmó que, mientras Firefox estaba en segundo plano, podían aparecer nuevos tooltips si el mouse pasaba por el área correspondiente de la ventana de Firefox
  • Se adjuntó un caso en Firefox 5.0.1 donde, con Transmission al frente y Firefox en segundo plano, mover el mouse sobre la ventana Inspector de Transmission activaba tooltips de Firefox
  • También hubo un caso donde el gran tooltip del botón de la barra de herramientas de Adblock Plus aparecía sobre Transmission
  • Quedó registrado un caso donde el tooltip Options de Transmission y el tooltip del cuadro de búsqueda de Google en Firefox se mostraban al mismo tiempo y se superponían
  • En los elementos de la barra de marcadores se activaba no solo el tooltip, sino también el estado de mouseover
    • El estado del botón de marcador cambiaba primero y poco después aparecía el tooltip con la URL
    • El botón + de Open a New Tab también quedó registrado como una excepción donde, aun en segundo plano, se producían el estado de mouseover y el tooltip

Dirección de la corrección y parche aplicado

  • En las discusiones de inicios de la década de 2010 se propuso no mostrar el tooltip si la ventana no tenía foco cuando se ejecutaba el temporizador del tooltip
  • Safari y Google Chrome se usaron como casos comparativos, ya que en Mac no muestran tooltips cuando no son la aplicación en primer plano
  • La descripción del parche final fue only show tooltip when document has focus
  • El parche se subió como adjunto en Phabricator y luego se integró en autoland y mozilla-central
  • El estado cambió de ASSIGNED a RESOLVED y la resolución pasó a ser FIXED

Verificación de QA y regresiones posteriores

  • QA confirmó el issue en Firefox 106.0.1 con Ubuntu 22.04 usando el procedimiento original de reproducción
  • En la misma configuración, el problema ya no persistía en la Nightly 120.0a1 más reciente, por lo que el estado cambió a VERIFIED
  • El estado firefox119 cambió de fixed a verified
  • Un usuario comentó que el problema solo aparecía con MOZ_ENV_XINPUT2=1 y desaparecía con MOZ_ENV_XINPUT2=0, lo que se vinculó con bug 1809029
  • Después se enlazaron como regresiones relacionadas los siguientes bugs
    • 1857513: el tooltip de la barra lateral de marcadores no aparece al pasar el mouse cuando la barra lateral no tiene foco
    • 1861427: los tooltips ya no aparecen al pasar el mouse cuando otra aplicación tiene el foco
    • 2043757: en Windows 11, el título de la pestaña no aparece al pasar el mouse cuando Firefox está parcialmente cubierto por otra ventana

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-10-11
Opiniones en Hacker News

  • Si te da curiosidad cómo se encuentran y corrigen bugs en la base de código de Firefox, Mike Conley lleva años transmitiendo en vivo cada semana el trabajo de desarrollo que hace en Mozilla.
    Una buena parte de las grabaciones consiste en elegir un bug del backlog y rastrearlo con muchísimo detalle hasta encontrarlo.
    Lo recomiendo especialmente si apenas estás empezando a programar y quieres ver cómo es trabajar en una base de código real: https://youtube.com/@mikeconleytoronto

    • En la universidad, más o menos hace casi tanto tiempo como desde que se registró este bug, hice bastante voluntariado en Mozilla.
      Al principio estuve en el equipo de QA haciendo triage de bugs, revisando si el componente de Bugzilla era el correcto, si los pasos para reproducir tenían sentido, etc.
      Incluso sin tener nada de experiencia profesional, aprendí muchísimo solo viendo cómo se operaba un proyecto grande y cómo los desarrolladores reales manejaban correcciones y funcionalidades; también conocí conceptos como diff, patch y CI/CD. En ese entonces eran nightly builds, así que estrictamente no era integración continua, pero la idea iba por ahí.
      Más adelante aprendí a compilar la app, lo cual fue especialmente difícil en Windows. Compilé Firefox, Thunderbird y la Mozilla Suite, que todavía existía en ese momento y que integraba navegador, correo, editor HTML, etc.
      Al final también contribuí con algunas correcciones de bugs. Eran cosas como arreglar typos o íconos desalineados, pero la sensación de que se distribuyera código que millones de personas usaban de verdad era enorme.
      Esa experiencia me sirvió directamente en mi primer trabajo después de graduarme. Empecé en una startup haciendo soporte de IT y QA, y no había nada de automatización de builds ni de despliegues. Si alguien hacía push a SVN, podían pasar días sin que se supiera si el build se había roto.
      Con lo que aprendí en Mozilla, armé un servidor de builds usando algo como Buildbot, CruiseControl o Hudson, para compilar en cada push y enviar un correo al equipo si fallaba la compilación o alguna prueba.
      Era bastante divertido que desarrolladores con experiencia preguntaran “¿cómo demonios sabe hacer esto nuestro encargado de IT?”, y pude crearme ese rol incluso antes de que existiera el término DevOps. Todo fue gracias a lo que aprendí tocando Mozilla en mi tiempo libre.
      En definitiva, estoy totalmente de acuerdo en que hackear el proyecto Mozilla es una buena forma de ganar experiencia práctica.

  • Por fin lo arreglaron. Ojalá Mozilla hiciera más cosas de este tipo.
    Una de las formas más molestas de este bug era cuando ejecutabas un juego en pantalla completa, el mouse se reposicionaba y aparecía un tooltip, que quedaba flotando encima del juego.
    Al juego no le gustaba perder el foco ni hacer Alt-Tab para lidiar con Firefox, así que a veces terminabas teniendo que reiniciar el juego.

    • Justo ahora estoy escuchando una charla de Jonathan Blow en DevGAMM de hace 4 años, y este tipo de fallas aparece como un motivo recurrente.
      https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
    • Todavía sigo esperando que arreglen el comportamiento básico de las pestañas contenedoras. Es difícil no pensar que la gestión del producto está completamente rota.
      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
    • Recuerdo haber comentado en el bug hace años algo como “a mí también me pasa y tengo esta información”.
      Al final dejé de usar Firefox por completo hace unos 10 años, principalmente porque este bug me molestaba varias veces al día durante años y, para entonces, Chrome ya era lo suficientemente bueno como reemplazo.
      El texto del tooltip muchas veces era algo bastante genérico como “Previous”, así que tenía que volver a enfocar casi todas las ventanas de Firefox para averiguar de dónde venía, y siempre era un fastidio ir buscándolo hasta que desapareciera. Además, quedaba flotando por encima de todas las ventanas.

  • Me sorprende más que este comportamiento no haya cambiado ni por accidente durante todos esos años. Impresionante compatibilidad retroactiva de bugs.

  • Siempre le echaba la culpa de este bug a varios gestores de ventanas de escritorio en Linux, y recién ahora me entero de que el culpable siempre fue el mismo.
    En pantallas pequeñas podía ser bastante molesto porque podía tapar formularios u otros elementos importantes.
    Espero con ganas la actualización, y ojalá durante los próximos 22 años Firefox no solo esté libre de bugs, sino que vuelva a ser una aplicación influyente como antes.

    • Aun así, creo que seguiré culpando a los gestores de ventanas. Estoy seguro de haberlo visto fuera de Firefox, e incluso fuera de Linux.
    • También pasaba en Windows, y sigue ocurriendo en otras aplicaciones a través de distintos sistemas operativos. No se puede culpar a un solo componente o capa de GUI en particular.
    • Creo que también lo he visto en LibreOffice.
    • También ocurre en otros lugares. Lo veo seguido en DBeaver.
    • Lo sufro regularmente en Chrome sobre Fedora/GNOME/X.Org.

  • https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...
    Si al ver el cambio de cinco líneas que corrige este bug pensás “¡yo también podría haberlo hecho!”, en realidad sí podrías haberlo hecho
    La verdadera pregunta es “¿por qué no lo hice?”
    Si intento responderme, la clave es qué tan fácil es compilar Firefox y ejecutar el conjunto de pruebas
    El largo proceso posterior de rastrear el bug es la parte divertida

    • Suelo contribuir con frecuencia al software que uso y también intenté hacer algo en Firefox, pero para alguien externo era demasiado difícil, así que simplemente me rendí
      Todo el sistema, con hg, varios repositorios, wikis viejas, una compilación muy compleja, Bugzilla, etc., es demasiado difícil para entrar
      Si Firefox estuviera en GitHub, o aunque fuera en un GitLab autoalojado, y uno pudiera simplemente hacer un fork, probar cambios y correr el mismo CI, sería una historia completamente distinta. Ojalá fuera así de fácil
    • Siento que se subestima este cambio. Sinceramente, hay bastantes líneas eliminadas, y hasta entender a fondo qué intentaban hacer originalmente esas líneas, yo no me habría animado a apretar Delete
    • La corrección real parece aún más simple que eso. En verdad solo agregaron esta comprobación: !doc->HasFocus(IgnoreErrors())

  • Vaya, siempre pensé que de algún modo era culpa mía. Me siguió durante años, pasando por varias versiones de Windows y reinstalaciones
    No ocurría muy seguido, pero sí con suficiente constancia como para recordarlo

    • Todos los toolkits de UI no nativos parecen tener comportamientos de tooltips con bugs muy sutiles
    • Me pregunto cuánto dinero habría ganado Mozilla si hubiera vendido espacio publicitario en los tooltips fijos durante los últimos 22 años. Deberían haber monetizado su bug antes de que alguien más lo hiciera
    • Sí. Pensé que me estaba volviendo loco o que estaba usando una instalación rota
    • A mí también me pasó. Pensé que era solo yo, pero ocurría en todas mis máquinas con Linux y Windows
    • En macOS también fue igual, al menos durante varios años

  • Es un bug bastante interesante. Parece que le pasó a mucha gente, y algunos dicen que lo veían al menos una vez al día, pero no recuerdo haber visto este comportamiento ni una sola vez en los últimos 15 años
    Tampoco parece estar limitado a un sistema operativo, así que me da curiosidad cuáles eran realmente las condiciones que hacían aparecer este bug
    El único lugar donde vi un bug parecido fue en LibreWolf, es decir, un Firefox personalizado con mayor protección de privacidad. Pero estoy casi seguro de que era por flatpak más que por el navegador en sí. Los otros Firefox que uso nunca mostraron ese comportamiento

    • Este tipo de bug parece bastante común en varios sistemas GUI. Por ejemplo, lo vi muchas veces en la barra de tareas de Windows 10, y la única forma de salir era poner el cursor sobre el botón de múltiples ventanas y luego sacarlo fuera de la barra de tareas
      Muchos sitios web también tienen problemas similares si se dan las condiciones adecuadas
      La causa principal parece ser una inconsistencia en la entrega de eventos. Debería recibir un evento cuando el cursor sale, pero por algún motivo no lo recibe, por ejemplo porque la ventana pierde el foco y ya no se le entregan eventos de mouse
      Si no hay una forma dedicada de detectar estos casos de manera confiable, como DOM onmouseleave o onmouseout, hacen falta workarounds y hacks. Por ejemplo, se podría generar un evento sintético cuando la ventana pierde el foco
    • Lo uso instalado de forma nativa en OpenSuse Tumbleweed con Linux KDE Plasma y lo veo todos los días, la mayoría de las veces varias veces al día
      La mejor forma de describirlo es que ocurre cuando, justo en el frame en que aparece el tooltip, cambio a otro escritorio virtual con un atajo de teclado
      Parece haber sido una condición de carrera que requería un timing muy preciso, y por eso debió ser difícil de acotar. Como afecta sobre todo a quienes usan mucho los atajos de teclado, es muy probable que mucha gente no se haya visto afectada
      Me alegra mucho que lo hayan corregido y espero recibir esa versión de Firefox
      Acabo de probarlo y, para reproducirlo, basta con poner el mouse sobre el elemento que dispara el tooltip y, antes de que aparezca el popup, cambiar a otro escritorio virtual mientras Firefox no es la nueva aplicación activa
    • Es un bug muy específico del flujo de trabajo. Casi solo me pasa cuando juego videojuegos
      Mientras juego, suelo tener un video de YouTube reproduciéndose en una pestaña del navegador y, en otra, busco información relacionada con el juego
      Por eso es común que interactúe con la barra de pestañas justo antes de hacer Alt-Tab hacia el juego, y ahí se dispara el tooltip
      En el uso cotidiano del navegador, el cursor casi siempre está sobre el contenido de los sitios web, donde los tooltips aparecen rara vez
    • Me encontré mucho con este bug al interactuar con videos de YouTube insertados en otras páginas web
      El flujo es así: al poner el cursor sobre el control de pantalla completa del reproductor insertado, aparece el tooltip “Full screen (f)”, y al hacer clic en el control, el video pasa a pantalla completa, pero el tooltip queda ahí encima del video en reproducción
      Usaba Linux X11 con el gestor de ventanas Marco de MATE
    • Con los juegos pasa algo parecido. Cuando sale un juego de un estudio famoso por títulos “rotos”, la gente sube compilados de cosas raras que ocurren, pero a mí no me pasa nada de eso. Quizá tenga una resistencia natural a los bugs
      Eso sí, a menudo me encuentro con un bug inofensivo: al abrir el menú de desbordamiento de la barra de marcadores, es decir, el ícono >> de la esquina superior derecha, en vez de mostrar los marcadores que no caben en la barra, muestra todos los marcadores en una lista desplegable

  • Curiosamente, este bug se registró incluso antes de que saliera la primera versión de Firefox: https://en.wikipedia.org/wiki/Firefox_early_version_history
    Es impresionante que hayan mantenido funcionando durante tanto tiempo el historial del rastreador de bugs

    • Puede ser que el historial del rastreador de bugs venga desde la época de Phoenix/Firebird

  • Ah, por fin. El bug relacionado, https://bugzilla.mozilla.org/show_bug.cgi?id=1569439, se cerró hace 9 meses, y gracias a eso mejoró un poco
    Ese bug era simplemente que el tooltip no desaparecía al cambiar a otra app. Pero seguía quedándose al cambiar a otro espacio de trabajo, lo cual fue una gran decepción
    La desventaja es que esto es una corrección un tanto “incorrecta”. Los tooltips deberían mostrarse aunque la ventana no tenga el foco. Al menos en las apps GTK de Linux es así, y Firefox también intenta imitar ese comportamiento
    Habría que corregir la causa raíz de que el tooltip no desaparezca cuando cambia el espacio de trabajo y el puntero del mouse en realidad ya no está sobre la ventana

    • Lo que me encontraba más seguido no era el bug de TFA, sino ese bug relacionado. Hacía tiempo que no lo veía, y ahora sé por qué

  • Enlace directo al parche: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1

    • ¿Esto es un commit?
      Si es así, ¿es común meter cambios de indentación y cambios reales de código en el mismo commit?
      Personalmente, creo que primero habría hecho un commit con los cambios de indentación y luego, en un segundo commit, los cambios de código
    • ¡Wow, si se excluyen del commit las líneas cambiadas por la indentación, este cambio tiene apenas cinco líneas de código nuevo!