1 pontos por GN⁺ 2023-10-11 | 1 comentários | Compartilhar no WhatsApp
  • O bug tooltip-ghost, em que tooltips continuavam em primeiro plano mesmo com o Firefox em segundo plano, foi acompanhado por muito tempo no Bugzilla e chegou ao estado VERIFIED FIXED no branch Firefox 119
  • A reprodução inicial consistia em passar o mouse sobre um link ou ícone da barra de ferramentas para exibir o tooltip e então alternar para outro app com Command-Tab ou Alt-Tab, momento em que o tooltip não desaparecia
  • Casos semelhantes continuaram aparecendo não só no Mac OS X, Windows e Linux, mas também no Thunderbird, Sunbird e Lightning; no Firefox 5.0.1, bastava o mouse passar sobre uma janela em segundo plano para disparar o tooltip e o estado de mouseover
  • O patch final foi only show tooltip when document has focus, alterando o comportamento para exibir tooltips somente quando o documento tiver foco, e foi integrado ao mozilla-central na revisão 8ae372dc88d1
  • O QA reproduziu o problema com o procedimento original no Firefox 106.0.1 e Ubuntu 22.04, depois confirmou que ele não persistia em uma configuração Nightly 120.0a1; posteriormente, alguns bugs de regressão relacionados foram vinculados separadamente

Tooltips que permanecem sobre o Firefox em segundo plano

  • O Bug 148624 trata do problema em que tooltips permanecem em primeiro plano mesmo quando o Firefox está em segundo plano
  • O título original é Tooltips persist in foreground when Firefox is in background, e o alias é tooltip-ghost
  • O estado é VERIFIED FIXED, e o marco-alvo é o 119 Branch
  • A classificação é Core :: XUL, o tipo é defect, e a severidade é S3

Procedimento inicial de reprodução e comportamento esperado

  • O ambiente do relatório inicial era Mozilla/5.0 ... Mac OS X ... Gecko/20020602 BuildID: 2002060203
  • O procedimento de reprodução era simples
    • Passar o mouse sobre um ícone da barra de ferramentas ou um link
    • Esperar até o tooltip aparecer
    • Enviar o Mozilla para o segundo plano com Command-Tab
  • Na prática, uma pequena caixa amarela de tooltip continuava em primeiro plano
  • O comportamento esperado era que o tooltip desaparecesse quando o Mozilla fosse alternado para segundo plano
  • O relator original deixou registrado que o tooltip só desaparecia ao trazer o Firefox de volta para o primeiro plano e mover o mouse para fora da barra de ferramentas

Casos de reprodução em várias plataformas

  • Após a confirmação inicial, o escopo de plataforma foi alterado de Mac OS X para All, e o mesmo problema também foi reproduzido no Windows XP e Windows 98
  • Casos continuaram aparecendo também no 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, Firefox 117.0, entre outros
  • Um fenômeno semelhante também apareceu em ambientes com Thunderbird, Sunbird e Lightning
    • No Thunderbird 2.0.0.17 e Lightning 0.9, foi anexado um caso em que o tooltip da janela de tarefas permanecia sobre a janela de notificação
    • A combinação Thunderbird 102.4.1 e Firefox 106.0.1 também reproduzia o problema no GNU/Linux
    • Também foram enviados procedimentos de reprodução no Firefox 117.0 e Thunderbird 115.2.0, em ambientes xfce e xfwm
  • Um usuário relatou que o problema continuava acontecendo no Firefox 115.0.2 com GNOME 44 e usou como workaround a configuração browser.chrome.toolbar_tips para desativar completamente os tooltips

Impacto além de tooltips que permaneciam visíveis

  • Além de tooltips já exibidos continuarem visíveis, também foi confirmado o sintoma de novos tooltips aparecerem quando o mouse passava pela área correspondente da janela do Firefox enquanto ele estava em segundo plano
  • No Firefox 5.0.1, quando o Transmission estava em primeiro plano e o Firefox em segundo plano, foi anexado um caso em que os tooltips do Firefox eram acionados ao mover o mouse sobre a janela Inspector do Transmission
  • Também houve um caso em que um tooltip grande do botão da barra de ferramentas do Adblock Plus apareceu sobre o Transmission
  • Ficou registrado um caso em que o tooltip de Options do Transmission e o tooltip da caixa de pesquisa Google do Firefox eram exibidos simultaneamente, sobrepondo-se
  • Nos itens da barra de favoritos, não apenas o tooltip, mas também o estado de mouseover era disparado
    • O estado do botão de favorito mudava primeiro e, pouco depois, o tooltip da URL aparecia
    • O botão + de Open a New Tab também foi registrado como exceção em que o estado de mouseover e o tooltip ocorriam em segundo plano

Direção da correção e patch integrado

  • Nas discussões do início da década de 2010, foi proposta uma abordagem em que o tooltip não seria exibido se a janela não tivesse foco quando o temporizador do tooltip fosse executado
  • Safari e Google Chrome foram usados como exemplos de comparação no Mac por não exibirem tooltips quando não são o app em primeiro plano
  • A descrição do patch final foi only show tooltip when document has focus
  • O patch foi enviado como anexo no Phabricator e depois integrado ao autoland e ao mozilla-central
  • O estado mudou de ASSIGNED para RESOLVED, e a resolução passou a ser FIXED

Verificação de QA e regressões posteriores

  • O QA confirmou a issue com o procedimento de reprodução original no Firefox 106.0.1 e Ubuntu 22.04
  • Na mesma configuração, a versão mais recente Nightly 120.0a1 não apresentou mais a persistência do problema, e o estado foi alterado para VERIFIED
  • O estado de firefox119 foi alterado de fixed para verified
  • Um usuário registrou que o problema aparecia apenas com MOZ_ENV_XINPUT2=1 e desaparecia com MOZ_ENV_XINPUT2=0, o que foi vinculado ao bug 1809029
  • Depois disso, os seguintes bugs foram vinculados como regressões relacionadas
    • 1857513: tooltips da barra lateral de favoritos não aparecem ao passar o mouse quando a barra lateral não tem foco
    • 1861427: tooltips deixam de aparecer ao passar o mouse quando outro aplicativo está focado
    • 2043757: no Windows 11, o título da aba não aparece ao passar o mouse quando o Firefox está parcialmente coberto por outra janela

1 comentários

 
GN⁺ 2023-10-11
Opiniões no Hacker News
  • Se você tem curiosidade sobre como bugs são encontrados e corrigidos na base de código do Firefox, Mike Conley faz há anos transmissões ao vivo semanais do trabalho de desenvolvimento que realiza na Mozilla
    Boa parte das gravações mostra o processo de escolher um bug no backlog e rastreá-lo de forma bem minuciosa até resolvê-lo
    Recomendo especialmente se você está começando a programar e quer ver como é trabalhar em uma base de código real: https://youtube.com/@mikeconleytoronto

    • Na época da faculdade, fui voluntário bastante na Mozilla, mais ou menos há tanto tempo quanto esse bug está registrado
      No começo, fazia triagem de bugs na equipe de QA, verificando se o componente do Bugzilla estava correto, se os passos para reproduzir faziam sentido etc.
      Mesmo sem nenhuma experiência prática, só observar como um projeto grande era operado e como desenvolvedores de verdade lidavam com correções e funcionalidades já foi um grande aprendizado; também tive contato com conceitos como diff, patch e CI/CD. Na época eram nightly builds, então, estritamente falando, não era integração contínua, mas a direção era essa
      Mais tarde aprendi a compilar o aplicativo, o que foi especialmente difícil no Windows. Compilei o Firefox, o Thunderbird e até o Mozilla Suite, que ainda existia na época e integrava navegador, e-mail, editor HTML etc.
      No fim, também contribuí com algumas correções de bugs. Eram coisas como corrigir erros de digitação ou ícones desalinhados, mas a sensação de ver código realmente usado por milhões de pessoas sendo distribuído era enorme
      Essa experiência ajudou diretamente no meu primeiro emprego depois da graduação. Comecei em uma startup com suporte de TI e QA, mas não havia nenhuma automação de build e implantação. Alguém podia dar push no SVN e ninguém saber por dias se o build tinha quebrado
      Com base no que aprendi na Mozilla, usei alguma coisa entre Buildbot, CruiseControl e Hudson para criar um servidor de build que compilava a cada push e enviava e-mail para a equipe em caso de falha de compilação ou de testes
      Foi bem divertido ver desenvolvedores experientes perguntando “como é que o nosso cara de TI sabe fazer isso?”, e consegui criar para mim esse tipo de função antes mesmo de existir o termo DevOps. Tudo graças ao que aprendi mexendo na Mozilla no meu tempo livre
      No fim, concordo totalmente que hackear o projeto Mozilla é uma ótima forma de ganhar experiência prática
  • Finalmente foi corrigido. Gostaria que a Mozilla fizesse mais coisas assim
    Uma das formas mais irritantes desse bug é quando você abre um jogo em tela cheia, o mouse é reposicionado e aparece uma tooltip, que fica por cima do jogo
    O jogo não gosta de perder o foco nem de Alt-Tab para lidar com o Firefox, então às vezes você acaba tendo que reiniciar o jogo

    • Por coincidência, estou ouvindo agora uma palestra que Jonathan Blow deu na DevGAMM há 4 anos, e esse tipo de defeito aparece como um motivo recorrente
      https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
    • Ainda estou esperando corrigirem o comportamento básico de abas em contêineres. É difícil não pensar que a gestão de produto está completamente quebrada
      [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
    • Lembro de ter comentado no bug alguns anos atrás algo como “também estou passando por isso e tenho estas informações”
      Acabei abandonando completamente o Firefox cerca de 10 anos atrás, principalmente porque esse bug me incomodava várias vezes por dia durante anos e, por volta daquela época, o Chrome já estava bom o suficiente para substituí-lo
      O conteúdo da tooltip muitas vezes era algo bem genérico, como “Previous”, então eu precisava voltar o foco para quase todas as janelas do Firefox para descobrir de onde vinha, e era sempre um tormento ficar procurando até a tooltip sumir. Além disso, ela ficava por cima de todas as janelas
  • O mais surpreendente é que, ao longo de todos esses anos, esse comportamento não tenha mudado nem por acaso. Uma impressionante retrocompatibilidade de bug

  • Eu sempre culpava os vários gerenciadores de janelas de desktops Linux por esse bug, e só agora descobri que o culpado sempre foi o mesmo
    Em telas pequenas, isso às vezes era bem incômodo, porque podia cobrir formulários ou outros elementos importantes
    Estou ansioso pela atualização e espero que, pelos próximos 22 anos, o Firefox não só fique livre de bugs, mas também volte a ser um aplicativo influente como antes

    • Ainda assim, acho que vou continuar culpando o gerenciador de janelas. Já vi isso fora do Firefox e até fora do Linux, com certeza
    • Também acontecia no Windows e continua acontecendo em outros aplicativos em diferentes sistemas operacionais. Não dá para culpar apenas um componente específico ou uma única camada de GUI
    • Acho que já vi isso no LibreOffice também
    • Acontece em outros lugares também. Vejo com frequência no DBeaver
    • Também passo por isso regularmente no Chrome no Fedora/GNOME/X.Org
  • https://phabricator.services.mozilla.com/rMOZILLACENTRAL8ae3...
    Se você olhar para a correção de cinco linhas que conserta esse bug e pensar “eu também conseguiria ter feito isso!”, a verdade é que conseguiria mesmo
    A verdadeira pergunta é: “por que não fiz?”
    Tentando responder por conta própria, a questão é quão fácil é compilar o Firefox e executar a suíte de testes
    O longo processo de rastreamento do bug que vem depois é a parte divertida

    • Eu costumo contribuir com softwares que uso no dia a dia e tentei fazer algo no Firefox também, mas era difícil demais para alguém de fora, então simplesmente desisti
      Todo o sistema envolvendo hg, vários repositórios, wikis antigos, um build muito complexo, Bugzilla etc. é difícil demais para entrar
      Se o Firefox estivesse no GitHub, ou mesmo em um GitLab auto-hospedado, de modo que fosse só fazer um fork, mexer e rodar o mesmo CI, a história teria sido completamente diferente. Queria que fosse fácil assim
    • Acho que essa correção está sendo subestimada. Sinceramente, há um bom número de linhas removidas, e eu não teria confiança para apertar Delete até entender profundamente o que aquelas linhas estavam tentando fazer originalmente
    • A correção real parece ainda mais simples do que isso. Foi literalmente só adicionar esta verificação: !doc->HasFocus(IgnoreErrors())
  • Uau, eu sempre achei que de alguma forma a culpa fosse minha. Isso me acompanhou por anos, passando por várias versões do Windows e reinstalações
    Não acontecia com frequência, mas acontecia de forma consistente o bastante para ficar na memória

    • Parece que todos os toolkits de UI não nativos têm comportamentos de tooltip com bugs muito sutis
    • Fico imaginando quanto dinheiro a Mozilla poderia ter ganhado se tivesse vendido espaço publicitário nos tooltips travados ao longo dos últimos 22 anos. Deveriam ter monetizado o bug antes que alguém fizesse isso
    • Exato. Eu achava que estava ficando louco ou que estava usando alguma instalação quebrada
    • Eu também. Achava que era só comigo, mas acontecia em todas as minhas máquinas com Linux e Windows
    • No macOS também foi assim por pelo menos alguns anos
  • É um bug bem interessante. Parece que muita gente passou por isso, e algumas pessoas dizem que veem pelo menos uma vez por dia, mas eu não me lembro de ter visto esse comportamento nenhuma vez nos últimos 15 anos
    Também não parece ser limitado a um sistema operacional, então fico curioso sobre quais eram, de fato, as condições que faziam esse bug aparecer
    O único lugar onde vi um bug parecido foi no LibreWolf, isto é, um Firefox customizado com privacidade reforçada. Mas tenho quase certeza de que era por causa do flatpak, e não do navegador em si. Os outros Firefox que rodo nunca apresentaram esse comportamento

    • Esse tipo de bug parece ser bastante comum em vários sistemas de GUI. Por exemplo, vi muito esse comportamento na barra de tarefas do Windows 10, e a única forma de sair dele era colocar o cursor sobre o botão de múltiplas janelas e depois tirá-lo da barra de tarefas
      Muitos sites também apresentam problemas parecidos quando as condições certas se alinham
      A causa principal parece ser inconsistência na entrega de eventos. O sistema deveria receber um evento quando o cursor sai, mas por algum motivo acaba não recebendo, por exemplo porque a janela perdeu o foco e os eventos de mouse deixam de ser entregues
      Se não houver uma forma dedicada de detectar esses casos de maneira confiável, como DOM onmouseleave ou onmouseout, são necessários contornos e hacks. Por exemplo, criar um evento sintético quando a janela perde o foco
    • Uso instalado nativamente no OpenSuse Tumbleweed com Linux KDE Plasma e vejo isso todos os dias, na maioria das vezes várias vezes por dia
      A melhor forma de descrever é que acontece quando mudo para outra área de trabalho virtual com um atalho de teclado exatamente no frame em que o tooltip aparece
      Era uma condição de corrida que exigia um timing muito preciso, por isso acho que foi difícil de isolar. Como afeta principalmente quem usa muitos atalhos de teclado, também é bem possível que muita gente não tenha sido impactada
      Fico muito feliz que tenha sido corrigido e estou ansioso para receber essa versão do Firefox
      Acabei de testar: para reproduzir, basta deixar o mouse sobre o alvo do tooltip e, antes de o pop-up aparecer, trocar para outra área de trabalho virtual enquanto o Firefox não é o novo aplicativo ativo
    • É um bug muito específico de fluxo de trabalho. Eu quase só passo por isso quando jogo videogame
      Enquanto jogo, muitas vezes deixo um vídeo do YouTube rodando em uma aba do navegador e procuro informações sobre o jogo em outra aba
      Então é comum eu interagir com a barra de abas logo antes de dar Alt-Tab para o jogo, e é aí que o tooltip é acionado
      No uso cotidiano do navegador, o cursor quase sempre fica sobre o conteúdo do site, onde tooltips aparecem raramente
    • Passei muito por esse bug ao interagir com vídeos do YouTube incorporados em outras páginas
      O fluxo é assim: ao passar o cursor sobre o controle de tela cheia do player incorporado, aparece o tooltip “Full screen (f)”; ao clicar no controle, o vídeo entra em tela cheia, mas o tooltip continua sobre o vídeo em reprodução
      Eu usava Linux X11 com o gerenciador de janelas Marco do MATE
    • Em jogos é parecido. Quando sai um jogo de um estúdio famoso por títulos “quebrados”, as pessoas postam coletâneas de coisas estranhas acontecendo, mas do meu lado nada disso acontece. Talvez seja uma resistência natural a bugs
      Porém, eu costumo ver um bug inofensivo em que, ao abrir o menu de extensões da barra de favoritos, isto é, o ícone >> no canto superior direito, todos os favoritos aparecem na lista suspensa, e não apenas os favoritos que não cabem na barra
  • Curiosamente, esse bug foi registrado antes mesmo da primeira versão do Firefox ser lançada: https://en.wikipedia.org/wiki/Firefox_early_version_history
    É impressionante que tenham mantido o histórico do rastreador de bugs funcionando por tanto tempo

    • Talvez o histórico do rastreador de bugs venha desde a época do Phoenix/Firebird
  • Ah, finalmente. O bug relacionado, https://bugzilla.mozilla.org/show_bug.cgi?id=1569439, foi fechado há 9 meses, e graças a isso melhorou um pouco
    Esse bug era simplesmente o problema de o tooltip não desaparecer ao alternar para outro app. Mas, ao mudar para outro espaço de trabalho, ele ainda ficava lá, o que foi extremamente decepcionante
    O ponto negativo é que isso é, em certa medida, uma correção “errada”. Tooltips devem aparecer mesmo quando a janela não está em foco. Pelo menos em apps GTK no Linux é assim, e o Firefox também tenta imitar esse comportamento
    É preciso corrigir a causa raiz de o tooltip não desaparecer quando o espaço de trabalho muda e o ponteiro do mouse, na prática, não está mais sobre a janela

    • O que eu encontrava com mais frequência não era o bug do TFA, mas esse bug relacionado. Fazia um tempo que eu não via isso, e agora sei o motivo
  • Link direto do patch: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1

    • Isso é um commit?
      Se for, é comum colocar mudanças de indentação e alterações reais de código no mesmo commit?
      Pessoalmente, eu provavelmente teria feito primeiro um commit com as mudanças de indentação e depois, em um segundo commit, as alterações de código
    • Uau, tirando as linhas alteradas por causa das mudanças de indentação no commit, essa alteração tem só cinco linhas de código novo!