Bug do Firefox em `<textarea>` corrigido após 25 anos

 (bugzilla.mozilla.org)
1 pontos por GN⁺ 2024-05-23 | 1 comentários | Compartilhar no WhatsApp
  • O antigo Bug 33654 do Firefox era um problema em que o <textarea>, ao aplicar ROWS= e COLS=, acabava somando também o espaço da barra de rolagem e parecia maior do que o número de linhas e colunas especificado; agora ele foi fechado como duplicado do Bug 1830576
  • Em ambientes com overlay scrollbars desativadas ou com a opção “always show scrollbars”, repetia-se o comportamento de calcular <textarea rows=N> com altura de aproximadamente N+1 linhas
  • A discussão inicial se expandiu para herança de fonte, aplicação forçada de monospace, cálculo de cols com base na largura média de w e W e a forma de reservar espaço para barras de rolagem, acumulando por muito tempo casos de teste, patches e capturas de tela
  • Na prática, rows=1 podia parecer ter 3 linhas, rows=2 podia aparecer com altura de 3 linhas, e em cols=80 a posição da quebra de linha diferia entre IE e Firefox, causando inconsistências no controle de layout de formulários entre navegadores
  • Com o Bug 1830576 marcado como VERIFIED FIXED, a aplicação do espaço de barras de rolagem ficou consistente entre WebKit, Chromium e Firefox, e o Bug 33654 foi encerrado como RESOLVED DUPLICATE

Estado e escopo do Bug 33654

  • O Bug 33654 era uma falha em que o <textarea> aplicava incorretamente ROWS= e COLS=, criando espaço extra para barras de rolagem horizontal e vertical quando overlay scrollbars estavam desativadas
  • O produto e componente são Core :: Layout: Form Controls, cobrindo layout e aparência de controles de formulário HTML, especialmente elementos como textarea
  • O estado atual é RESOLVED DUPLICATE of bug 1830576
    • O título do bug duplicado, Bug 1830576, é Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
    • O estado do Bug 1830576 é VERIFIED FIXED
  • O bug foi aberto há 26 anos e fechado há 2 anos como RESOLVED DUPLICATE
  • Os metadados mostram versão Trunk, plataforma x86 / All, tipo defect, prioridade P3 e severidade S3
  • As palavras-chave incluem testcase, o Whiteboard é [html][behavior]relnote-devel, e o número de votos exibido é 99
  • Os anexos aparecem como 17 files, 17 obsolete files, com envio recorrente de casos de teste, patches e capturas de tela

Sintomas observados no início

  • No relato inicial, Andrew McMillan registrou que um exemplo de TEXTAREA definido com ROWS=5 COLS=30 era exibido aproximadamente como ROWS=7 COLS=48
  • Nos comentários iniciais, surgiram vários casos em que INPUT TYPE=TEXT e TEXTAREA não usavam corretamente a fonte especificada ou ficavam altos demais mesmo quando a barra de rolagem aparecia
  • Depois, a discussão convergiu para a ideia de que o layout do textarea estava recebendo informações incorretas: havia espaço adicional nas colunas e uma linha extra nas linhas
  • A possibilidade de a causa ser a reserva antecipada de espaço para barras de rolagem também foi levantada desde cedo

Cálculo de fonte e patches iniciais

  • Em um caso do newsgroup de HTML authoring, ao usar textarea { font-size: 8pt } junto com <textarea cols="40" rows="12">, o IE renderizava a largura corretamente, mas o Mozilla parecia calcular a largura com base em fonte 12pt
  • Um arquivo de teste usando a fonte arial incluía <textarea NAME=system_code wrap=soft rows=5 cols=30 WRAP style="font-family:arial">
  • Rod avaliou que, como o cálculo de tamanho estava correto com a fonte padrão, o problema central não era o sizing em si, mas o fato de o textarea não usar a fonte correta
  • Kin encontrou código que, quando a flag PlainText do editor estava ativada, forçava font-family: monospace; na área de conteúdo do TextControl
    • Ao remover esse código, a fonte correta passava a ser usada
    • Porém, no modo NavQuirks, ainda restava o problema de uma string de 30 caracteres ocupar apenas cerca de 2/3 da largura em um textarea de 30 colunas
    • Como causa, apontou-se o método em que nsFormControlHelper obtinha a largura média de w e W da fonte, multiplicava pelo número de colunas e somava a largura da barra de rolagem para calcular a largura do textarea
  • O Patch to use the correct font. adicionava eEditorEnableWrapHackMask às flags de inicialização do editor de texto simples e restringia condicionalmente a aplicação de font-family: monospace;
  • Esse patch chegou a ser tratado como RESOLVED FIXED, mas o autor original informou que, embora COLS=... estivesse certo, ROWS=... ainda se comportava incorretamente, e o bug foi reaberto

Reprodução recorrente e bugs duplicados

  • A lista de bugs duplicados incluía vários casos em que o <textarea> aparecia uma linha maior do que o especificado ou em que rows=1 parecia ter 3 linhas
    • 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 !
  • O teste interativo era um documento HTML 4.01 Strict em que os valores de rows e cols podiam ser alterados por botões, sem uso de font tag nem fonte de largura variável
    • O resultado era sempre 3 colunas a mais do que o valor especificado, e normalmente 1 linha a mais
    • Ao pedir rows=1, eram exibidas 3 linhas
  • Em builds trunk de 2002 no Linux e Win2000, havia relatos de <textarea cols=40 rows=2></textarea> sendo mostrado com 3 linhas, e de rows=N resultar exatamente em N+1 linhas
  • Testes do W3C HTML 4.01 também foram usados como referência, com comentários indicando que o problema ficava claro nos testes relacionados a ROWS
  • No Windows 2000 e no Mozilla 0.9.3, também foi enviado um exemplo em que um textarea com rows=1 claramente não parecia ter apenas 1 linha

Discussão sobre o cálculo do espaço da barra de rolagem

  • O Comment 86 explicava que o tamanho do textarea era calculado como o valor de cols/rows especificado mais o espaço da barra de rolagem
  • Diferentemente do IE, o Mozilla exibia a barra de rolagem apenas quando necessário, e isso fazia os usuários perceberem o comportamento como quebrado
  • Foram sugeridas três opções possíveis
    • Não somar o tamanho da barra de rolagem ao calcular o tamanho do textarea
    • Mostrar sempre a barra de rolagem, como no IE
    • Incluir apenas a barra de rolagem que será exibida
  • Apontou-se que a terceira opção era circular, porque o tamanho dependeria da exibição da barra de rolagem, e a exibição da barra de rolagem dependeria novamente do tamanho
  • O Comment 87 propôs uma quarta opção: ROWS e COLS controlariam apenas o tamanho do conteúdo do textarea, e, se a barra de rolagem aparecesse, o textarea cresceria
  • Depois, a direção de implementação discutida passou a ser fazer reflow com width/height sem barra de rolagem para decidir se ela era necessária e, caso fosse, refazer o reflow com a nova width/height

Impacto percebido pelos usuários

  • Quando rows="2" era especificado, mas surgia um textarea com altura de 3 linhas, a intenção de orientar visualmente a quantidade esperada de texto ficava enfraquecida
    • Uma aplicação web pedia um texto de resumo curto e usava rows="2" para sugerir um volume “mais que uma linha, mas não uma redação”
    • As diferenças de comportamento entre Firefox, IE6 e Opera 8 faziam o mesmo valor de rows gerar orientações visuais diferentes dependendo do user agent
  • Mesmo quando o conteúdo do textarea não era rolado, continuaram os comentários de que o comportamento do Firefox estava errado
    • Em campos como entrada de endereço, que na maioria dos casos não passariam de três linhas, mesmo definindo rows="3" o Firefox sempre mostrava uma linha extra
    • A página ficava desnecessariamente maior, e o usuário podia pensar que ainda não havia preenchido informação suficiente porque a caixa parecia maior do que o esperado
  • Na comparação com cols=80, uma descrição com captura de tela dizia que o IE quebrava a linha após preencher 80 caracteres 1 até a borda da barra de rolagem, enquanto o Firefox ainda deixava espaço para mais 2 caracteres antes de exibir a barra de rolagem horizontal
  • Em 2019, ainda havia comentário dizendo que o problema persistia, e um cartão do Trello do Discord, Chat bar is a line taller than usual on Firefox, foi citado como exemplo de impacto

Tentativas de correção ao longo de muitos anos

  • Hideo Saito anexou várias vezes patches e casos de teste
    • patch for rows and cols
    • testcase de patch para wrap="off"
    • base patch
    • additional patch for another bug
    • patch which does not remove space
  • Uma das abordagens era fazer nsTextControlFrame::Reflow com tamanho intrínseco excluindo a barra de rolagem e, se ela existisse, somar seu tamanho ao tamanho intrínseco e executar novo reflow
  • Também foi discutida uma abordagem de alterar GetScrollbarStyles para que o text control frame controlasse se a barra de rolagem ficaria como auto, hidden ou scroll
  • roc preferia tratar isso em nsTextControlFrame em vez de introduzir muitas mudanças em nsGfxScrollFrame
  • Os patches seguintes repetiram ciclos de revisão e retrabalho em torno de mecanismos como SetScrollbarStyles, GetScrollbarStyles, SetScrollbarSpace, GetScrollbarOverflowState, FrameNeedsReflow e callback pós-reflow
  • Alguns patches receberam review- ou foram marcados como obsolete, e os revisores apontaram a necessidade de atualização para o trunk

Soluções temporárias e limitações

  • Houve a sugestão de que adicionar CSS textarea{ overflow-x: hidden } resolveria o problema
  • A condição era que esse método só se aplicava quando não era necessária barra de rolagem horizontal
  • Outro comentário rebateu que esse bug não podia ser corrigido apenas com CSS overflow e que o Firefox era o único navegador a renderizar o textarea com uma linha extra
  • Emilio Cobos Álvarez disse que a causa parecia ser o tamanho da barra de rolagem e que aplicar scrollbar-width: none ao <textarea> parecia resolver
  • No mesmo comentário, ele acrescentou que o bug em si ainda precisava ser corrigido

Encerramento final

  • Há 3 anos, o BugBot observou que a severidade desse bug era relativamente baixa, S3, mas pediu revisão para possível aumento por ele ter 27 duplicados, 103 votos e 91 pessoas em CC
  • O resumo do bug mudou de TEXTAREA incorrectly applying ROWS= and COLS= para TEXTAREA incorrectly applying ROWS= and COLS= (horizontal / vertical scrollbar extra space, with overlay scrollbars disabled)
  • Daniel Holbert adicionou como dependência o Bug 1830576, Firefox sizes <textarea rows=N> as roughly N+1 rows tall, under an "always show scrollbars" configuration
  • Luke Warlow perguntou se, como o Bug 1830576 havia sido corrigido, seria possível fechar este bug, já que a aplicação do espaço de barras de rolagem havia ficado consistente entre WebKit, Chromium e Firefox
  • Emilio Cobos Álvarez concordou, e o Bug 33654 mudou de NEW para RESOLVED, sendo fechado como DUPLICATE
  • O bug duplicado apontado foi o Bug 1830576, que está em estado VERIFIED FIXED

Leituras relacionadas

1 comentários

 
GN⁺ 2024-05-23
Comentários do Hacker News

  • Ha! Eu estava inscrito nesse bug durante a maior parte desses 25 anos. Na época não existia Firefox, e ele tinha sido registrado como um bug do Mozilla, de antes/depois do Netscape Navigator, não exatamente do Navigator
    Não me lembro por que me inscrevi, mas provavelmente comentei lá. A cada poucos anos chegava um e-mail de notificação e isso sempre me fazia rir; há alguns dias, finalmente foi corrigido

    • É impressionante que a assinatura daquela thread do bug tenha sobrevivido por tanto tempo
    • Comigo foi parecido. Lembro de, quando comecei a pensar em trabalhar criando sites, ficar fascinado imaginando sites cujo fundo fosse transparente ou semitransparente até a área de trabalho
      Eu sempre achei que algo como html { background: transparent; } simplesmente deveria funcionar. Só que essa correção de bug não faz isso de fato. Para começar, não é um recurso que o site escolhe por padrão, e sim uma configuração que o usuário ou uma extensão pode ativar. Provavelmente é melhor assim; se fosse permitido por padrão, abriria um novo caminho para clickjacking
    • Em vez de “registrado para o Netscape Navigator”, seria mais para a Mozilla Suite. Em 2000, já estávamos bem dentro da era Mozilla, e também não acho que bugs do Netscape fossem parar no Bugzilla
    • Uau, esse bug é mais velho que o próprio Firefox
    • O próximo da fila é resolver os tickets de versão entre projetos no Jira

  • Fugindo um pouco do assunto, mas eu realmente odeio essa moda de mostrar períodos em formato amigável para humanos, tipo “há um mês”. Mostre a data e eu mesmo faço a conta
    O Outlook, pelo menos na versão para Mac, é o pior. E-mails anteriores a hoje aparecem, por exemplo, só como “ontem”, e você precisa clicar no e-mail para ver até o horário. Recebo dezenas de e-mails por dia; quando 50 mensagens aparecem em sequência apenas como “ontem”, isso não serve para nada

    • Seria bom se, ao passar o mouse sobre a indicação amigável, aparecesse o timestamp exato
    • Torço sinceramente para essa moda desaparecer logo. Faz uma enorme diferença se o e-mail chegou às 6h da manhã ou às 23h. Dizer apenas “ontem” não é suficiente
      Cerveja gelada e timestamps precisos, por favor
    • Pior ainda quando está errado. O Discogs insiste em dizer que outubro de 2021 foi “há mais de 3 anos”
    • “Mostre a data e eu mesmo faço a conta” é algo realmente difícil para mim. Tenho bastante dificuldade com datas e com a própria noção de passagem do tempo
    • Ao passar o mouse sobre a data, aparecem a data e a hora exatas

  • O Bugzilla do Firefox certamente é um dos rastreadores de bugs em operação há mais tempo. É impressionante que, mesmo depois de tantas revisões, ele ainda mantenha bastante da sensação original. Antigamente era uma base de código bem bruta e monstruosa
    Por volta de 2000, em uma organização de desenvolvimento para Windows, montei uma instância para substituir um rastreador de bugs interno baseado em Microsoft Access/Outlook. Era complexo, mas por um tempo foi praticamente um dos melhores rastreadores de bugs. O FogBugz também estava começando naquela época, e acho que aquela equipe foi uma das primeiras a levar a experiência do usuário a sério

    • Ainda hoje não é fácil superar o Bugzilla. Na verdade, algumas opções atuais são tão piores que o Bugzilla que é difícil entender como existem. Por exemplo, o Mantis BT usado pelo Dwarf Fortress é realmente péssimo
      Por outro lado, o FogBugz é uma ferramenta que sempre quis experimentar se tivesse a chance

  • Esse tipo de coisa aquece o coração. Recentemente passei por algo parecido em um bug do Firefox de 24 anos: https://bugzilla.mozilla.org/show_bug.cgi?id=62151

    • Droga, lembro de ter ficado preso por causa disso

  • Entre os bugs antigos não resolvidos, o que mais me incomoda é que no LibreOffice não dá para definir corretamente o eixo x de um gráfico de dispersão em formato de data
    https://bugs.documentfoundation.org/show_bug.cgi?id=54132
    É um bug de 12 anos. Pelos comentários, o clima é de relutância em corrigir porque o código é “terrivelmente complexo” e a correção tem grande chance de causar regressões

    • Eu esperava que o LibreOffice trouxesse os recursos do Excel de que gosto, mas vendo isso minhas expectativas diminuem
    • Se você só precisa de planilha e de um pacote para criar gráficos, no Linux o gnumeric é uma boa opção
    • É ótimo quando os mantenedores passam a ter medo do código que eles mesmos permitiram mesclar

  • Na próxima, queria que cuidassem do XDG. Também estou esperando por isso há 20 anos [1]
    [1] https://bugzilla.mozilla.org/show_bug.cgi?id=259356

    • Não acho que os diretórios base XDG algum dia serão adotados de forma completa e universal. Já se passaram 21 anos. Se o Arch Linux não tivesse sido agressivo com programas que não seguem isso — por exemplo, travando permissões no diretório do usuário root —, nem teria crescido tanto quanto cresceu recentemente
      Sinceramente, essa especificação não resolve ativamente problemas reais que as pessoas enfrentam. A maior parte da adoção é resultado de gente incomodada com a organização do diretório $HOME pressionando mantenedores de forma insistente, e 99% dos usuários não se importam se um programa segue ou não os diretórios base XDG. No máximo, permite dizer que é “mais limpo” por seguir uma especificação da freedesktop que não conseguiu ampla adoção em mais de 20 anos
      Pessoalmente, não gosto daquela separação frouxa entre configuração/dados/cache nem das intenções implícitas. Nem tudo se encaixa nessas categorias, e isso torna difícil prever o comportamento do sistema. Um daemon vai apagar meu cache? O usuário vai sair copiando a pasta de configurações? Exatamente o que será incluído no backup? A especificação não define um padrão para como as pastas devem ser tratadas na prática. Ela é propositalmente vaga, mas vaga de um jeito que pode quebrar coisas quando as pessoas fazem suposições
      É parecido com separar /usr da raiz, separar /usr/local da raiz, ou ter /opt. Restos de uma era passada continuam por aí, e parece que querem criar mais um
      No nosso produto, também damos suporte a contragosto, mas só quando a variável de ambiente correspondente está definida explicitamente. Ignoramos 100% o comportamento do XDG de que, quando ela não está definida, esses deveriam ser os padrões em todos os sistemas Linux, porque isso difere do que outros sistemas do tipo UNIX, como o MacOS, esperam. Implementamos apenas o suficiente para impedir que entusiastas do Arch Linux invadissem nosso rastreador de bugs toda semana exigindo adoção, e eles não chegam a 1% da base total de usuários. Já é difícil o bastante orientar os usuários na documentação sobre onde encontrar os arquivos do nosso produto em seus sistemas. Os usuários nem sempre conhecem XDG e, para a maioria, XDG não é uma convenção estabelecida que eles já esperem. Fora para quem quer um diretório de usuário limpo, não há um valor forte; há legado demais para migrar todo mundo para essa especificação
      Sinceramente, deveríamos repensar tudo e partir para uma solução baseada em contêineres, em que apps de desktop não consigam sair de suas pequenas prisões. Algo bem parecido com apps snap. Talvez dê para aprender um pouco com o Nix. Precisamos admitir que fracassou a ideia de fazer todos os apps de usuário Linux do mundo se importarem com os diretórios base XDG — ou mesmo com o diretório do usuário — e adotarem isso. Já é difícil o bastante dar suporte a ports para Mac e Windows, que não seguem esse comportamento. Precisamos sair do modelo de permissões UNIX em que programas rodam com permissões do usuário e executar cada programa com seu próprio uid. É assim que o Android funciona
    • Sim, eu também estou esperando por isso

  • Espero que corrijam, por favor, o bug em que a opção de copiar fica desativada aleatoriamente mesmo quando há texto para copiar. É de enlouquecer

    • Que bom saber que não sou só eu
    • Vamos ver se corrigem dentro de 25 anos. Para os padrões do ambiente web rápido de hoje, a Mozilla às vezes é lenta demais

  • A AWS resolve esse problema apagando periodicamente bugs antigos e todas as menções a eles

    • É a estratégia do avestruz para evitar bugs

  • Post relacionado de agosto passado:
    Happy 25th Birthday to Bugzilla
    https://news.ycombinator.com/item?id=37279543

  • Legal! Só que 2000-03-28 ainda não foi há 25 anos

    • Pensando bem, é um jeito bem estranho de arredondar
    • Sim. Sinceramente, se fosse eu, teria esperado mais alguns meses e corrigido no aniversário de bodas de prata :P