Bug de tooltip do Firefox corrigido após 22 anos
(bugzilla.mozilla.org)- 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 estadoVERIFIED FIXEDno 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 aomozilla-centralna revisão8ae372dc88d1 - 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
xfceexfwm
- 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_tipspara 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
Optionsdo 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
+deOpen a New Tabtambé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
autolande aomozilla-central - O estado mudou de
ASSIGNEDparaRESOLVED, 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
firefox119foi alterado defixedparaverified - Um usuário registrou que o problema aparecia apenas com
MOZ_ENV_XINPUT2=1e desaparecia comMOZ_ENV_XINPUT2=0, o que foi vinculado aobug 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 foco1861427: tooltips deixam de aparecer ao passar o mouse quando outro aplicativo está focado2043757: 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
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
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
https://www.youtube.com/watch?v=ZSRHeXYDLko&t=2729s
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1479858
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
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
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
!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
É 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
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
onmouseleaveouonmouseout, são necessários contornos e hacks. Por exemplo, criar um evento sintético quando a janela perde o focoA 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
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
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
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 barraCuriosamente, 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
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
Link direto do patch: https://hg.mozilla.org/mozilla-central/rev/8ae372dc88d1
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