Firefox 147 passa a oferecer suporte à especificação XDG Base Directory

• Adicionado suporte à especificação XDG Base Directory na versão Firefox 147
• Arquivos de configuração e cache passam do diretório home tradicional para caminhos XDG padronizados
• Melhora a consistência no gerenciamento de arquivos de configuração em ambientes Linux
• Os dados existentes do usuário serão migrados automaticamente para o novo local
• Contribui para a organização da estrutura de arquivos e melhoria da compatibilidade em diferentes ambientes de desktop

---

Suporte a XDG Base Directory no Firefox 147

• O Firefox 147 foi alterado para seguir a XDG Base Directory Specification
  • Essa especificação define os locais padrão de armazenamento para configurações, cache e arquivos de dados de aplicativos em sistemas Linux
• Antes, o Firefox criava a pasta .mozilla no diretório home do usuário, mas agora passa a usar caminhos padrão como ~/.config, ~/.cache, ~/.local/share
• Com essa mudança, a estrutura passa a seguir as variáveis de ambiente XDG_CONFIG_HOME, XDG_CACHE_HOME, XDG_DATA_HOME

Dados do usuário e migração

• Os dados existentes de usuários do Firefox serão migrados automaticamente para os caminhos XDG na nova versão
• Durante o processo de migração, as configurações existentes, favoritos e outros dados serão preservados, sem necessidade de ação manual
• Isso facilita para usuários Linux a organização do sistema de arquivos e o gerenciamento de backups

Significado no ecossistema Linux

• A conformidade com a especificação XDG reforça a consistência com outros aplicativos de desktop
• Melhora a integração com ambientes de desktop importantes como GNOME e KDE
• O Firefox reforça sua posição como um navegador alinhado a padrões na plataforma Linux

[GN⁺]

Comentários do Hacker News

• Finalmente parece que a Mozilla começou a corrigir um bug antigo
  Mas, olhando os detalhes, no diff do código não dá para ver nenhuma lógica de migração
  Parece que, se ~/.mozilla existir, ele continua sendo usado; se não existir, usa ~/.config/mozilla. Fico me perguntando se as configurações antigas se perdem caso MOZ_LEGACY_HOME=1 não esteja definido
  Além disso, não parece haver uma separação correta entre ~/.cache, ~/.config e ~/.local/share, e tudo indica que todos os dados do perfil foram movidos para ~/.config

  • Falei brincando, mas de fato um bug de 27 anos foi fechado recentemente
    A versão Nightly ganhou about:keyboard, permitindo editar ou limpar diretamente os atalhos padrão, como salvar, voltar, recarregar e ferramentas de desenvolvedor
  • Pelo diff, parece que, se ~/.mozilla existir ou MOZ_LEGACY_HOME estiver definido, ele continua sendo usado; caso contrário, usa $XDG_CONFIG_HOME/.mozilla
    Ou seja, os dados não são descartados, mas também não há migração
  • Pelo diff completo, ~/.cache já está em uso, mas não há nada relacionado a ~/.local/share
  • Se todos os dados forem colocados em ~/.config, isso não é a mesma coisa que seguir a especificação XDG Base Directory
    Ainda assim, é bom ter um dotfile a menos bagunçando o diretório home
  • Acho que ainda falta bastante para separar completamente a pasta .mozilla
    Como até agora todos os dados foram colocados em uma única pasta, deve ser mais difícil distinguir entre cache, configurações e dados da aplicação

• Essa mudança é um avanço bem significativo
  Os principais aplicativos não vinham seguindo corretamente o XDG Base Directory, e a adoção pelo Firefox pode influenciar outros projetos também
  Parece que o artigo da Arch Wiki também vai precisar de atualização

  • Os desenvolvedores do OpenSSH veem a adoção do XDG como um risco de segurança
    Como .ssh lida com permissões de acesso ao sistema, espalhar os caminhos de configuração por vários lugares pode complicar o gerenciamento e aumentar vulnerabilidades
    Talvez desse para mover .ssh/config ou known_hosts para XDG, mas mover só uma parte acaba enfraquecendo o objetivo de organizar os dotfiles
    Há uma discussão relacionada na lista de e-mails
  • É surpreendente que, mesmo sendo uma mudança tão simples, a lista de aplicativos não conformes ainda seja tão grande
    Parece o tipo de problema que um único PR resolveria em poucas horas
  • No passado, quando o Debian trocou o nome de icedove para thunderbird, houve uma grande confusão por causa de conflitos no caminho das configurações
    Com uma estrutura XDG, configurações e dados estariam separados e esse problema não teria acontecido
  • O Chromium ainda usa $HOME/.pki e continua bagunçando o diretório home
    Isso acontece por não usar corretamente a libnss, e aplicativos que embutem Chromium, como o QtWebEngine, sofrem do mesmo problema

• A pasta .mozilla era um dos últimos dotfiles que restavam no meu diretório home
  Fico feliz só de pensar que isso vai ser arrumado
  Também dá para usar a ferramenta xdg-ninja (link) para encontrar aplicativos que violam as regras do XDG
  Muitos programas fazem hardcode de ~/.config ou ~/.local e tentam recriá-los toda vez; é melhor evitar esse tipo de app

  • Talvez dê para resolver com hardlinks, mas o uso de variáveis de ambiente ainda continua sendo uma parte difícil
    Seria bom ter uma configuração em nível de driver que mapeasse XDG_CONFIG_HOME para um caminho virtual
  • Obrigado por me apresentar o xdg-ninja
    Eu realmente detesto programas que bagunçam o diretório home sem controle
    Já estou cansado desse modelo de configuração em que é preciso editar arquivos ocultos manualmente

• Ótima notícia
  O Firefox já seguia bem as pastas do sistema no Windows e no macOS
  O Linux não tinha um padrão único, mas seguir as recomendações do XDG é um grande avanço

• Finalmente chegou a hora certa
  Todo software deveria oferecer suporte a XDG. É surpreendente que o Firefox não seguisse isso desde o começo

  • O XDG surgiu bem depois do Firefox e, durante a maior parte desse período, não foi amplamente adotado
  • A razão pela qual a maioria dos softwares não segue o XDG é que a especificação só apareceu por volta de 2003
    Agora a adoção está aumentando aos poucos, e o diretório home vai ficar muito mais limpo
    O importante, porém, é oferecer um caminho de migração claro para que as configurações antigas não sejam perdidas

• Isso é realmente uma notícia muito bem-vinda
  Era um bug aguardado havia muito tempo, como no caso do Gimp 3, então fico feliz de ver isso finalmente resolvido

• Vendo o Firefox adicionar suporte a .mkv recentemente e fazer esse tipo de melhoria, ele está ficando cada vez melhor
  Minha reclamação restante são apenas os atalhos hardcoded

  • O Firefox Nightly ganhou about:keyboard, então agora é possível editar diretamente os atalhos
    Ainda cobre só funções básicas, mas já é bem utilizável

• Uma melhoria dessas depois de 21 anos: tardia, mas bem-vinda 😄

  • Quando alguém perguntou “por que isso demorou tanto?”, há uma história de que um desenvolvedor respondeu “não havia tempo”
    Depois de 21 anos, isso chega a ser engraçado

• Fico imaginando se a pessoa que reportou esse bug pela primeira vez ainda está viva

  • Talvez a geração dos netos dessa pessoa esteja acompanhando isso agora

• O Firefox continua sendo um excelente navegador em multitarefa com várias abas e uso de memória
  No último ano, quase não tive problemas de renderização
  Fico curioso para ver que outros recursos antigos ainda vão ser melhorados

  • No meu caso, às vezes acontece de links não responderem ao clique
    Provavelmente é problema do bloqueador de anúncios ou da implementação de algum fornecedor SaaS
    Nesses sites importantes, acabo tendo que usar o Safari mesmo