From a065e04d529da1d847b5062a12c46d916408bf32 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 21:46:22 -0500 Subject: update based on https://github.com/mdn/yari/issues/2028 --- .../building_firefox_with_rust_code/index.html | 34 --- .../mozilla/firefox/developer_edition/index.html | 57 ---- .../developer_edition/revertendo/index.html | 25 -- .../mozilla/firefox/multiple_profiles/index.html | 244 --------------- .../firefox/multiprocess_firefox/index.html | 75 ----- .../multiprocess_firefox/motivacao/index.html | 44 --- .../which_uris_load_where/index.html | 59 ---- .../index.html | 328 --------------------- files/pt-br/mozilla/firefox/privacidade/index.html | 16 - .../index.html" | 84 ------ .../errors/cookieblockedtracker/index.html | 44 --- .../storage_access_policy/errors/index.html | 24 -- .../privacy/storage_access_policy/index.html | 263 ----------------- 13 files changed, 1297 deletions(-) delete mode 100644 files/pt-br/mozilla/firefox/building_firefox_with_rust_code/index.html delete mode 100644 files/pt-br/mozilla/firefox/developer_edition/index.html delete mode 100644 files/pt-br/mozilla/firefox/developer_edition/revertendo/index.html delete mode 100644 files/pt-br/mozilla/firefox/multiple_profiles/index.html delete mode 100644 files/pt-br/mozilla/firefox/multiprocess_firefox/index.html delete mode 100644 files/pt-br/mozilla/firefox/multiprocess_firefox/motivacao/index.html delete mode 100644 files/pt-br/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html delete mode 100644 files/pt-br/mozilla/firefox/performance_best_practices_for_firefox_fe_engineers/index.html delete mode 100644 files/pt-br/mozilla/firefox/privacidade/index.html delete mode 100644 "files/pt-br/mozilla/firefox/privacidade/prote\303\247\303\243o_de_rastreamento/index.html" delete mode 100644 files/pt-br/mozilla/firefox/privacy/storage_access_policy/errors/cookieblockedtracker/index.html delete mode 100644 files/pt-br/mozilla/firefox/privacy/storage_access_policy/errors/index.html delete mode 100644 files/pt-br/mozilla/firefox/privacy/storage_access_policy/index.html (limited to 'files/pt-br/mozilla/firefox') diff --git a/files/pt-br/mozilla/firefox/building_firefox_with_rust_code/index.html b/files/pt-br/mozilla/firefox/building_firefox_with_rust_code/index.html deleted file mode 100644 index 7f50b8a9c2..0000000000 --- a/files/pt-br/mozilla/firefox/building_firefox_with_rust_code/index.html +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Building Firefox with Rust code -slug: Mozilla/Firefox/Building_Firefox_with_Rust_code -translation_of: Archive/Mozilla/Firefox/Building_Firefox_with_Rust_code ---- -

Em maio de 2015, foi lançada a primeira versão 1.0 estável da linguagem de programação Rust, e vários experimentos para escrever partes do Gecko em Rust iniciaram. Esta página é um simples guia para pessoas trabalhando nesta área.

- -

Adicionando código Rust

- -

O suporte básico para buildar códigos em Rust foi lançado no bug 1161339. Se você possui rustc no seu path, você pode adicionar arquivos .rs ao SOURCES em moz.build. Então adicione

- -

ac_add_options --enable-rust

- -

ao seu mozconfig e provavelmente funcionará.

- -

A biblioteca padrão do Rust utiliza armazenamento thread-local, que não é suportado no MacOS X 2.6, então se você está buildando em um Mac, você também precisará disso:

- -

ac_add_options --enable-macos-target=10.7

- -

Alternativamente, você pode compilar com um conjunto de ferramentas costumizadas com --disable-elf-tls. Veja bug 1164109 para detalhes.

- -

Graças as limitações do cargo e do sistema de build do Firefox, atualmente nós buildamos uma biblioteca estática stand-alone para cada arquivo rust listado em SOURCES. Você precisa portanto listar apenas os arquivos rust de alto nível. Tudo precisa ser um único crate, como uma compilação manual unificada. O compilador rust irá pesquisar por módulos interiores pelo nome do arquivo-fonte, mas referências crate externas não serão resolvidas.

- -

Veja o bug 1135640 ('oxidation') para monitoramento global.

- -

Testando código Rust

- -

There's a simple linkage teste unitários in the tree. Você pode utilizá-lo para verificar se Rust está habilitado e funcionando com your build setup.

- -

./mach gtest rust.*

- -

Look for the rust.CallFromCpp test to pass, along with any others.

diff --git a/files/pt-br/mozilla/firefox/developer_edition/index.html b/files/pt-br/mozilla/firefox/developer_edition/index.html deleted file mode 100644 index 5ae8204f4c..0000000000 --- a/files/pt-br/mozilla/firefox/developer_edition/index.html +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Edição do Programador -slug: Mozilla/Firefox/Developer_Edition -tags: - - Firefox - - Iniciante - - Landing -translation_of: Mozilla/Firefox/Developer_Edition ---- -

- -

Uma versão do Firefox sob medida para desenvolvedores web.

- -

Download Firefox Developer Edition

- -

Os recursos mais recentes do Firefox

- -

O Firefox Developer Edition substitui o canal Aurora no Processo de lançamento do Firefox. Como no Aurora, os recursos vão para o Developer Edition a cada seis semanas, depois de serem estabilizados no Nightly builds.

- -

Ao usar o Developer Edition, você ganha acesso a ferramentas e recursos da plataforma pelo menos 12 semanas antes de chegar ao principal canal de lançamento do Firefox.

- -

Descubra o que há de novo na Edição do Programador.

- -

Um tema distinto

- -

Incluindo acesso mais rápido às ferramentas de desenvolvimento.

- -

Ferramentas de desenvolvimento experimentais

- -

Vamos incluir ferramentas experimentais que ainda não estão prontas para liberação.

- -

Por exemplo, o Developer Edition inclui o Valence add-on, que permite que você conecte o Firefox developer tools a outros navegadores como o Chrome no Android e o Safari no iOS.

- -

Um perfil separado

- -

Firefox Developer Edition utiliza um perfil separado de outras versões do Firefox instalado em sua máquina. Isto significa que você pode facilmente executar o Developer Edition ao lado de seu lançamento ou versão beta do Firefox.

- -

Note: Isto significa que a primeira vez que você iniciar o Developer Edition, você verá um navegador completamente não personalizado, sem complementos, bookmarks ou histórico. Você pode usar Firefox Sync se você quer unificar suas configurações entre o Developer Edition e outras edições do Firefox.

- -

Set up para desenvolvedores web

- -

Nós definimos valores de preferência padrões adaptados para desenvolvedores web. Por exemplo, {{glossary("Chrome")}} e depuração remota são ativadas por padrão.

diff --git a/files/pt-br/mozilla/firefox/developer_edition/revertendo/index.html b/files/pt-br/mozilla/firefox/developer_edition/revertendo/index.html deleted file mode 100644 index de8ce406d8..0000000000 --- a/files/pt-br/mozilla/firefox/developer_edition/revertendo/index.html +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Revertendo -slug: Mozilla/Firefox/Developer_Edition/Revertendo -translation_of: Mozilla/Firefox/Developer_Edition/Reverting ---- -

Revertendo tema no Developer Edition

- -

- Se você quiser usar o Developer Edition, mas prefere usar o tema 'Australis' usado no Firefox e Firefox Beta, você poderá alternar para o tema normal do Firefox: basta abrir o painel "Personalizar", clicar em "Temas", e selecionar o tema rotulado como "Padrão":

- -

Alternativamente, digite "about:addons" na barra de localização, selecione "Aparência", e alterne os temas.

- -

Revertendo para Firefox Aurora

- -

- Se você quiser todos os recursos pré-Beta do Firefox Developer Edition, mas não quer nenhuma outra alteração, você pode reverter para algo como o antigo Firefox Aurora. Isso também irá restaurar seu perfil de pré-atualização e os dados da sessão. Este é um processo de 2 etapas, e você precisa seguir os passos nesta ordem:

- -

Abra a página de Preferências do Developer Edition, e desmarque a opção "Permitir que o Firefox Developer Edition e Firefox execute ao mesmo tempo". Será solicitado a reinicialização do navegador.
Depois de reinicializar, você poderá reverter o tema do developer edition como descrito em "Revertendo tema no Developer Edition" acima.

- -

diff --git a/files/pt-br/mozilla/firefox/multiple_profiles/index.html b/files/pt-br/mozilla/firefox/multiple_profiles/index.html deleted file mode 100644 index 54bdf6b45a..0000000000 --- a/files/pt-br/mozilla/firefox/multiple_profiles/index.html +++ /dev/null @@ -1,244 +0,0 @@ ---- -title: Vários perfis no Firefox -slug: Mozilla/Firefox/Multiple_profiles -tags: - - Firefox - - Guía - - Iniciante - - Intro - - Perfis - - QA -translation_of: Mozilla/Firefox/Multiple_profiles ---- -

- -

Um perfil no Firefox é a coleção de configurações, personalizações, complementos e outras personalizações que um usuário fez ou instalou em sua cópia do Firefox. Você pode encontrar detalhes sobre perfis no site de suporte ao usuário final da Mozilla.

- -

Motivos para ter vários perfis

- -

O usuário casual pode querer ter perfis diferentes para trabalho e uso pessoal ou para membros da família diferentes. Ter perfis diferentes ajudaria a separar a vida profissional e pessoal ou permitir que cada membro da família tenha seu próprio conjunto de favoritos, configurações e complementos.

- -

Os desenvolvedores web podem querer um perfil secundário para testar sites, aplicativos ou outros projetos em diferentes canais do Firefox. Por exemplo, você pode querer ter algumas extensões instaladas para desenvolvimento Web, mas não para navegação na Web de propósito geral. Ao usar o canal Nightly, você pode encontrar alguns complementos que se tornaram temporariamente incompatíveis com novas alterações da API, até que o desenvolvedor do complemento tenha a chance de atualizá-los. Você pode remover esses complementos do seu perfil para uso noturno, mantendo-os para uso com outros perfis.

- -

Para colaboradores de QA, teste e triagem de bugs, você pode querer ter várias versões de desenvolvimento do Firefox instaladas, cada uma com seu próprio perfil. Criar novos perfis para testes pode impedir que você perca suas preferências, favoritos e histórico. Demora pouco tempo para configurar um novo perfil e, uma vez concluído, todas as suas versões do Firefox serão atualizadas separadamente e poderão ser executadas simultaneamente.

- -

Canais disponíveis de desenvolvimento do navegador

- -

Há quatro canais do navegador disponíveis, cada um em um nível diferente de estabilidade e desenvolvimento. Os quatro canais são Release, Beta, Developer Edition e Nightly. O canal Release é recomendado para a maioria dos usuários, já que é o canal de "lançamento oficial". No entanto, para os mais aventureiros, você pode experimentar um dos outros três canais para ver o que está por vir no Firefox e brincar com recursos emergentes. O canal Beta contém os recursos que devem estar na próxima versão do Firefox e estão em fase final de testes. Aurora contém recursos experimentais, que ainda não são de qualidade beta. Nightly contém o código mais recente dos desenvolvedores do Firefox e é o canal menos estável.

- -

Ferramentas de terceiros

- -

Além do Gerenciador de Perfis integrado e do Gerenciador de Perfis externo, existem algumas ferramentas de terceiros que facilitam o trabalho com vários perfis.

- -

Essa lista não é exaustiva. Por favor, adicione a esta lista quaisquer ferramentas úteis que você descobrir!

- -

Mac OS X

- -

Multifirefox por Dave Martorana

- -

Gerenciamento de perfis

- -

Determinando o perfil enquanto o Firefox está em execução

- -

Para determinar o perfil de uma instância do Firefox em execução no Windows, macOS ou Linux,

- -

Digite about:profiles ma barra de pesquisa de URL do navegador.
A página apresenta uma lista de todos os seus perfis, cada um começando com "Perfil: " seguido por seu nome.
O que está sendo usado por esta instância do Firefox incluirá o texto em negrito "Este é o perfil em uso". Por exemplo, se você encontrar este texto sob a entrada de "Perfil: Suzie", então você está usando um perfile chamado Suzie.

- -

Iniciando o Firefox no perfil desejado

- -

Você não pode mudar o perfile enquanto o Firefox está em execução. Apesar de ser possível em alguns casos ter várias instâncias do Firefox em execução em diferentes perfis, para evitar confusão, você deve primeiro sair/terminar todas as instâncias em execução de Firefox, FirefoxDeveloperEdition ou Nightly. Então, siga as instruções abaixo, aplicáveis ao seu sistema operacional.

- -

Windows

- -

Windows XP

- -

Clique no botão de Iniciar.
Clique "Executar".
-
Digite firefox --ProfileManager.
-

- -

Windows Vista/7

- -

Clique no botão de Iniciar.
Clique na barra de pesquisa na parte inferior.
-
Digite firefox --ProfileManager.
-

- -

Windows 8/8.1

- -

Pressione "Windows + R" em seu teclado.
Digite firefox --ProfileManager.

- -

Se a janela do Gerenciador de Perfis não abrir, o Firefox pode estar sendo executado em segundo plano, mesmo que não esteja visível. Feche todas as instâncias do Firefox ou reinicie o computador e tente novamente.

- -

Linux

- -

Se o Firefox já estiver incluído na sua distribuição Linux, ou se você tiver instalado o Firefox com o gerenciador de pacotes da sua distribuição Linux:

- -

No topo da janela do Firefox, clique no menu Arquivo e selecione Sair.
No Terminal, execute firefox --ProfileManager

- -

macOS

- -

Execute o aplicativo Terminal, que é encontrado em Aplicativos/Utilitários.
Digite ou cole no caminho para o Firefox, seguido por .app/Contents/MacOS/firefox. Por exemplo, se o Firefox está instalado no local recomendado, você digitaria /Applications/Firefox.app/Contents/MacOS/firefox.
Se você tiver o caminho para o seu perfil desejado à mão, insira um caractere de espaço, seguido por -profile seguido por outro caractere de espaço, seguido pelo caminho completo para a pasta de perfil na qual você deseja iniciar. Isto irá iniciar o Firefox imediatamente. Caso contrário, insira um caractere de espaço seguido de --profilemanager. Isso apresentará a janela do Gerenciador de Perfis na qual você pode fazer sua seleção.
Pressione enter.

- -

Aqui está um exemplo completo do comando Terminal a partir dos passos 2-3:

- -

/Applications/Firefox.app/Contents/macOS/firefox -profile /Users/Suzie/Library/Application\ Support/Firefox/Profiles/r99d1z7c.default

- -

Se você quiser fazer isso com frequência e de forma mais fácil, você pode querer criar um aplicativo Automatizador, como explicado neste tutorial.

- -

Criando um perfil

- -

Criando um perfil através do Gerenciador de Perfis

- -

Essas instruções devem ser as mesmas para todos os sistemas operacionais.

- -

Para iniciar o Assistente de novo perfil, clique em "Novo perfil..." no Gerenciador de Perfis.
Clique em Próximo e insira o nome do perfil. Use um nome de perfil que seja descritivo, como seu nome pessoal. Este nome não é exposto à Internet.
Você também pode escolher onde armazenar o perfil no seu computador. Para selecionar o local de armazenamento, clique em Pasta....
Se você escolher o local da pasta para o perfil, selecione uma pasta nova ou vazia. Se você escolher uma pasta que não esteja vazia e depois remover o perfil e escolher a opção \"Excluir arquivos\", tudo dentro dessa pasta será excluído.
Para criar o novo perfil, clique Concluir.

- -

Criando um perfil através do navegador Firefox

- -

Você pode criar um novo perfil do Firefox diretamente no navegador.

- -

Digite about:profiles na barra de pesquisa de URL do navegador
Na página, clique no botão Criar um novo perfil
Leia a introdução e clique em Próximo
Digite um nome de perfil para seu novo Perfil. Use um nome de perfil que é descritivo, tal como seu nome pessoal. Esse nome não é exposto para a Internet.
Opcionalmente, para alterar onde o perfil armazenará seu computador, clique em Pasta...
Para criar um novo perfil, clique Concluir.

- -

Excluindo um perfil

- -

No Gerenciador de perfil, selecione o perfil para remover e clique Excluir perfil....
Confirme que você deseja excluir o perfil: -
- "Não excluir arquivos" remove o perfil do Gerenciador de perfil, mas retém os arquivos de dados do perfil no seu computador na pasta de armazenamento, para que suas informações não sejam perdidas. "Não excluir arquivos" é a opção preferida, porque salva a pasta do perfil antigo, permitindo recuperar os arquivos para um novo perfil.
- "Excluir arquivos" remove o perfil e seus arquivos, incluindo os favoritos, configurações, senhas, etc.
  -
  - {{ warning("Se você usar a opção \"Excluir arquivos\", a pasta de perfil e os arquivos serão excluídos. Essa ação não podem ser desfeitas.") }}
- "Cancelar" interrompe a exclusão de perfil.
-

- -

Renomeando um perfil

- -

No Gerenciador de perfil, selecione o perfil que você deseja renomear e clique em "Renomear perfil".
Insira um novo nome para o perfile e clique em OK.

- -

Nota: A pasta contendo os arquivos para o perfil não é renomeada.

- -

Opções

- -

Trabalhar desconectado

- -

A escolha desta opção carrega o perfil selecionado e inicia o Firefox desconectado. Você pode visualizar páginas web visualizadas anteriormente e experimentar seu perfil.

- -

Não perguntar na inicialização

- -

Se você tiver vários perfis, o Firefox solicitará que o perfil seja usado toda vez que você iniciar o Firefox. Selecione essa opção para permitir que o Firefox carregue o perfil selecionado, sem solicitar a inicialização.

- -

Nota: Para acessar outros perfis após selecionar esta opção, você deve iniciar o Gerenciador de perfis primeiro.

- -

Usando os perfis

- -

Windows

- -

Se você deseja que o gerenciador de perfil seja exibido toda vez que iniciar o Firefox, para poder escolher um perfil, será necessário editar o "Destino" do ícone de inicialização. Para fazer isso:

- -

Clique com o botão direito o ícone e escolha "Propriedades".
Quando a caixa de diálogo de propriedades for exibida, você verá um campo de texto "Destino" que poderá editar e deverá mostrar o caminho atual do arquivo.
Após fechar as aspas, adicione -ProfileManager.
Clique Ok.

- -

Agora, sempre que você clicar duas vezes nesse ícone, o Gerenciador de perfis deverá aparecer, permitindo que você escolha o perfil que deseja usar.

- -

Se você quiser que ícones individuais iniciem perfis específicos, será necessário editar o "Destino" de cada ícone. Para fazer isso:

- -

Clique com botão direito no ícone e escolha "Propriedades".
Quando a caixa de diálogo de propriedades for exibida, você verá um campo de texto "Destino" que poderá editar e deverá mostrar o caminho atual do arquivo.
Para definir permanentemente um perfil específico, adicione -p NOME_DO_PERFIL ao caminho de destino, mas fora das aspas, substituindo "NOME_DO_PERFIL" com o nome de perfil que você escolher.
Se você também quiser permitir que várias instâncias do Firefox sejam executadas ao mesmo tempo, adicione -no-remote após o nome do perfil.
Quando terminar, clique em Ok. Faça isso para cada ícone para o qual você gostaria de ter um perfil específico. Uma vez feito, cada um deve iniciar automaticamente com o perfil especificado.

- -

Linux

- -

Não existe uma maneira extremamente direta de criar lançadores de aplicativos personalizados no Gnome 3 como havia no Gnome 2. O tutorial a seguir ajudará você a progredir no geral: Gnome 3 Iniciador de aplicativos personalizado. Depois de chegar ao ponto de adicionar um novo item, você pode ter a caixa de diálogo de perfil sempre exibida ou definir o inicializador para iniciar um perfil específico.

- -

Se você deseja que o gerenciador de perfil seja exibido toda vez que iniciar o Firefox, para poder escolher um perfil, será necessário definir a linha de comando para o seu novo iniciador.

- -

Defina o campo de texto "command" para direcionar o arquivo executável, provavelmente "/usr/bin/firefox", e adicione o parâmetro -p.

- -

Se você quiser que ícones individuais iniciem perfis específicos, você precisará definir a linha de comando para o seu novo lançador. Para fazer isso:

- -

Defina o campo de texto "command" para direcionar o arquivo executável, provavelmente "/usr/bin/firefox", e adicione o parâmetro -p NOME_DO_PERFIL, substituindo "NOME_DO_PERFIL" com o perfil específico.
Repita conforme necessário, para cada perfil adicional que você deseja definir.
Se você também quiser permitir que várias instâncias do Firefox sejam executadas ao mesmo tempo, adicione "-no-remote" após o nome do perfil.

- -

Mac OS X

- -

Você pode encontrar um tutorial útil para configurar lançadores personalizados aqui: Gerenciando vários perfis do Firefox no OSX. Observe que é melhor seguir todas as etapas na seção "Criando os scripts", incluindo a etapa "editar Info.plist". Deixe de fora o nome do perfil se quiser que o seletor de perfis seja exibido toda vez que você iniciar.

- -

Configurando vários perfis para diferentes canais do Firefox

- -

Esta seção será especialmente útil se você for um desenvolvedor, quiser trabalhar com vários canais e cada um tiver seu iniciador separado.

- -

Windows

- -

No Windows, as compilações Developer e Nightly têm seu próprio diretório na pasta "Programas", para que você não precise se preocupar com onde armazenar os arquivos baixados. No entanto, todos os três tentarão usar o mesmo perfil por padrão. Você não vai querer manter esse comportamento, porque os diferentes canais têm diferentes níveis de recursos. Para definir cada ativador, siga as instruções do Windows no Windows Launcher.

- -

Linux

- -

No Linux, as coisas não são configuradas automaticamente. Você provavelmente obterá uma solicitação para fazer o download de um arquivo tar.bz2 para extrair. Extraia os arquivos para um novo diretório e use as instruções do novo lançador aqui. A única mudança que você precisará fazer é o caminho do comando. Você desejará configurá-lo para o diretório em que extraiu o arquivo tar.bz2 do canal Firefox e o arquivo executável "firefox" localizado nesse diretório. Os demais métodos de atribuição de perfil permanecerão os mesmos. Você desejará, com certeza, adicionar a parte -no-remote ao final do campo de comando, para poder executar várias instâncias ao mesmo tempo.

- -

Mac OS X

- -

Você pode encontrar um tutorial útil para configurar lançadores personalizados aqui: Gerenciando vários perfis do Firefox no OSX. Observe que é melhor seguir todas as etapas na seção "Criando os scripts", incluindo a etapa "editar Info.plist". Além disso, você desejará alterar o caminho no script do shell para apontar para o arquivo .app correto para o canal do Firefox que você deseja segmentar.

diff --git a/files/pt-br/mozilla/firefox/multiprocess_firefox/index.html b/files/pt-br/mozilla/firefox/multiprocess_firefox/index.html deleted file mode 100644 index 2dd2134e60..0000000000 --- a/files/pt-br/mozilla/firefox/multiprocess_firefox/index.html +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Multiprocess Firefox -slug: Mozilla/Firefox/Multiprocess_Firefox -tags: - - Português (do Brasil) tags -translation_of: Mozilla/Firefox/Multiprocess_Firefox ---- -

In current versions of desktop Firefox, the entire browser runs in a single operating system process. In particular, the JavaScript that runs the browser UI (also known as "chrome code") runs in the same process as the code in web pages (also known as "content" or "web content").
-
- Future versions of Firefox will run the browser UI in a separate process from web content. In the first iteration of this architecture all browser tabs will run in the same process, and the browser UI will run in a different process. In future iterations, we expect every browser tab to run in its own process. The project that's delivering multiprocess Firefox is called Electrolysis, sometimes abbreviated to e10s.

- -

Normal web pages are unaffected by multiprocess Firefox. People working on Firefox itself and Firefox add-on developers will be affected if their code relies on being able to access web content directly.

- -

Instead of accessing content directly, chrome JavaScript will have to use the message manager to access content. To help ease the transition we've implemented Cross Process Object Wrappers and some compatibility shims for add-on developers. If you're an add-on developer wondering whether you are affected, see the guide to working with multiprocess Firefox.

- -

Multiprocess Firefox is currently enabled by default in Nightly builds. As a visual indicator that you're running multiprocess Firefox, the titles of remote tabs are underlined.

- -

Technical overview: A very high-level view of how multiprocess Firefox is implemented.
Glossary: A reference for the jargon used in multiprocess Firefox.
The message manager: How to communicate between chrome and content.
Message Manager interfaces: Includes links to the API reference for the message manager interfaces.
Frame script environment: The environment frame scripts run in, and especially how it differs from the environment for chrome code.

- -

Motivation: Why we're implementing multiprocess Firefox: performance, security, and stability.
Add-on migration guide: If you're an add-on developer, find out if you're affected and how to update your code.
Cross Process Object Wrappers: Cross Process Object Wrappers are a migration aid, giving chrome code synchronous access to content.
Debugging frame scripts: Using the Browser Content Toolbox to debug frame scripts.

- -

Limitations of chrome scripts: Practices that will no longer work in chrome code, and how to fix them.

- -

Limitations of frame scripts: Practices that will not work inside frame scripts, and what to do instead.

- -

Contact us

- -

Find out more about the project, get involved, or ask us your questions.

- -

Electrolysis project page: https://wiki.mozilla.org/Electrolysis
IRC: #e10s on irc.mozilla.org
Mailing list: dev.tech.electrolysis

diff --git a/files/pt-br/mozilla/firefox/multiprocess_firefox/motivacao/index.html b/files/pt-br/mozilla/firefox/multiprocess_firefox/motivacao/index.html deleted file mode 100644 index 8b3745c16c..0000000000 --- a/files/pt-br/mozilla/firefox/multiprocess_firefox/motivacao/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Motivação para o Multiprocesso do Firefox -slug: Mozilla/Firefox/Multiprocess_Firefox/Motivacao -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Motivation ---- -

Existem três principais razões para fazer o Firefox executar conteúdo em processos separados: desempenho, segurança e estabilidade.

- -

Performance

- -

A maioria dos trabalhos de performances na Mozilla nos últimos dois anos tem se concentrado na capacidade de resposta do navegador. O objetivo é reduzir " jank" - esses momentos em que o navegador parece congelar brevemente ao carregar uma página grande, digitando uma forma, Ou rolagem. A capacidade de resposta tende a importar muito mais do que o rendimento na web hoje. Grande parte deste trabalho foi feito como parte do projeto Snappy. Os principais focos foram:

- -

Moving long-running actions to a separate thread so that the main thread can continue to respond to the user.
Doing I/O asynchronously or on other threads so that the main thread isn’t blocked waiting for the disk.
Breaking long-running code into shorter pieces and running the event loop in between. Incremental garbage collection is an example of this.

- -

Much of the low-hanging fruit in these areas has already been picked. The remaining issues are difficult to fix. For example, JavaScript execution and layout happen on the main thread, and they block the event loop. Running these components on a separate thread is difficult because they access data, like the DOM, that are not thread-safe. As an alternative, we’ve considered allowing the event loop to run in the middle of JavaScript execution, but doing so would break a lot of assumptions made by other parts of Firefox (not to mention add-ons).

- -

Running web content in a separate process is a nice alternative to these approaches. Like the threaded approach, Firefox is able to run its event loop while JavaScript and layout are running in a content process. But unlike threading, the UI code has no access to content DOM or or other content data structures, so there is no need for locking or thread-safety. The downside, of course, is that any code in the Firefox UI process that needs to access content data must do so explicitly through message passing.

- -

We feel this tradeoff makes sense for a few reasons:

- -

It’s not all that common for Firefox code to access content DOM.
Code that is shared with Firefox OS already uses message passing.
In the multiprocess model, Firefox code that fails to use message passing to access content will fail in an obvious, consistent way. In the threaded model, code that accesses content without proper locking will fail in subtle ways that are difficult to debug.

- -

Security

- -

Right now, if someone discovers an exploitable bug in Firefox, they’re able to take over users’ computers. There are a lot of techniques to mitigate this problem, but one of the most powerful is sandboxing. Technically, sandboxing doesn’t require multiple processes. However, a sandbox that covered single-process Firefox wouldn’t be very useful. Sandboxes are only able to prevent processes from performing actions that a well-behaved process would never do. Unfortunately, a well-behaved Firefox process (especially one with add-ons installed) needs access to much of the network and file system. Consequently, a sandbox for single-process Firefox couldn’t restrict much.

- -

In multiprocess Firefox, content processes will be sandboxed. A well-behaved content process won’t access the filesystem directly; it will have to ask the main process to perform the request. At that time, the main process can verify that the request is safe and that it makes sense. Consequently, the sandbox for content processes can be quite restrictive. Our hope is that this arrangement will make it much harder to craft exploitable security holes for Firefox.

- -

Stability

- -

Currently, a crash in the code running a web page will take down the entire browser. With multiprocess Firefox, only the content process that crashed will be killed.

- -

This page incorporates a lot of content from Bill McCloskey's blog post on multiprocess Firefox: http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/

- -

diff --git a/files/pt-br/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html b/files/pt-br/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html deleted file mode 100644 index 708c6b49f0..0000000000 --- a/files/pt-br/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Aonde cada URI carrega -slug: Mozilla/Firefox/Multiprocess_Firefox/Which_URIs_load_where -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Which_URIs_load_where ---- -

Com base inicialmente no esquema URI da página, o navegador pode decidir se carregar uma página no processo chrome ou um processo de conteúdo. Para alguns esquemas, você pode alterar o comportamento padrão.

- - - - - - - - - - - - - - - - - - - - - - - - - - -

Esquema	Comportamento
`about:`	- Por padrão, as páginas `about:` são sempre carregadas no processo chrome. No entanto, quando você registra uma nova página `about:` você pode alterar esse padrão. - - Duas novas flags são definidas em `nsIAboutModule`: - - - `URI_CAN_LOAD_IN_CHILD`: A página será carregada no mesmo processo que carregou o `navegador`. - `URI_MUST_LOAD_IN_CHILD`: A página sempre será carregada em um processo filho. - - - Para usar um destes flags, retorne em sua implementação o `getURIFlags` no código que registra o `about:` URI. - - Se você usar essas flags, você deve registrar a página sobre um framescript para cada guia. Se você não configurar o multiprocesso Compatível com o verdadeiro no seu `install.rdf`, então serão usados os padrões. Mas os padrões dos e10s serão obsoletos em breve. Leia mais aqui - Erro 1257201. -
`chrome:`	- Por padrão, as páginas `chrome:` são sempre carregadas no processo chrome. No entanto, quando você registra uma nova página `chrome`, você pode alterar esse padrão. - - Duas novas flags são definidas no file chrome.manifest: - - - remoteenabled: a página será carregada no mesmo processo que carregou o `navegador`. - remoterequired: a página sempre será carregada em um processo filho. - -
`file:`	- Sempre carregado em um processo de conteúdo. - - Nota: Isso não significa que o `file:` URIs podem ser usado livremente em código de processos de conteúdo. O Sandboxing pode incluir listas predefinidas de diretórios particulares e futuras alterações podem restringir os `files:` URIs a um processo de conteúdo separado, isolado do conteúdo da Web normal. Veja bug 1187099 como isso pode afetar os addons tentando carregar arquivos no diretório do perfil. -
`resource:`	Sempre carregado em um processo de conteúdo.

diff --git a/files/pt-br/mozilla/firefox/performance_best_practices_for_firefox_fe_engineers/index.html b/files/pt-br/mozilla/firefox/performance_best_practices_for_firefox_fe_engineers/index.html deleted file mode 100644 index 53e23e5f98..0000000000 --- a/files/pt-br/mozilla/firefox/performance_best_practices_for_firefox_fe_engineers/index.html +++ /dev/null @@ -1,328 +0,0 @@ ---- -title: Performance best practices for Firefox front-end engineers -slug: Mozilla/Firefox/Performance_best_practices_for_Firefox_fe_engineers -translation_of: Mozilla/Firefox/Performance_best_practices_for_Firefox_fe_engineers ---- -

- -

This guide will help Firefox developers working on front-end code produce code which is as performant as possible—not just on its own, but in terms of its impact on other parts of Firefox. Always keep in mind the side effects your changes may have, from blocking other tasks, to interfering with other user interface elements.

- -

Avoid the main thread where possible

- -

The main thread is where we process user events and do painting. It's also important to note that most of our JavaScript runs on the main thread, so it's easy for script to cause delays in event processing or painting. That means that the more code we can get off of the main thread, the more that thread can respond to user events, paint, and generally be responsive to the user.

- -

You might want to consider using a {{domxref("Worker")}} if you need to do some computation that can be done off of the main thread. If you need more elevated privileges than a standard worker allows, consider using a {{domxref("ChromeWorker")}}, which is a Firefox-only API which lets you create workers with more elevated privileges.

- -

Use requestIdleCallback()

- -

If you simply cannot avoid doing some kind of long job on the main thread, try to break it up into smaller pieces that you can run when the browser has a free moment to spare, and the user isn't doing anything. You can do that using {{domxref("Window.requestIdleCallback", "requestIdleCallback()")}} and the Cooperative Scheduling of Background Tasks API, and doing it only when we have a free second where presumably the user isn’t doing something.

- -

See also the blog post Collective scheduling with requestIdleCallback.

- -

As of {{bug(1353206)}}, you can also schedule idle events in non-DOM contexts by using Services.tm.idleDispatchToMainThread. See the nsIThreadManager.idl file for more details.

- -

Hide your panels

- -

If you’re adding a new XUL {{XULElem("popup")}} or {{XULElem("panel")}} to a document, set the {{XULAttr("hidden")}} attribute to true by default. By doing so, you cause the binding applied on demand rather than at load time, which makes initial construction of the XUL document faster.

- -

Get familiar with the pipeline that gets pixels to the screen

- -

Learn how pixels you draw make their way to the screen. Knowing the path they will take through the various layers of the browser engine will help you optimize your code to avoid pitfalls.

- -

The rendering process goes through the following steps: This is the pipeline that a browser uses to get pixels to the screen.

- -

The above image is used under Creative Commons Attribution 3.0, courtesy of this page from our friends at Google, which itself is well worth the read.

- -

For a very down-to-earth explanation of the Style, Layout, Paint and Composite steps of the pipeline, this Hacks blog post does a great job of explaining it.

- -

To achieve a 60 FPS frame rate, all of the above has to happen in 16 milliseconds or less, every frame.

- -

Note that {{domxref("Window.requestAnimationFrame", "requestAnimationFrame()")}} lets you queue up JavaScript to run right before the style flush occurs. This allows you to put all of your DOM writes (most importantly, anything that could change the size or position of things in the DOM) just before the style and layout steps of the pipeline, combining all the style and layout calculations into a single batch so it all happens once, in a single frame tick, instead of across multiple frames. See {{anch("Detecting and avoiding synchronous reflow")}} below for more information.

- -

This also means that {{domxref("Window.requestAnimationFrame", "requestAnimationFrame()")}} is not a good place to put queries for layout or style information.

- -

Detecting and avoiding synchronous style flushes

- -

What are style flushes?

- -

When CSS is applied to a document (HTML or XUL, it doesn’t matter), the browser does calculations to figure out which CSS styles will apply to each element. This happens the first time the page loads and the CSS is initially applied, but can happen again if JavaScript modifies the DOM.

- -

JavaScript code might, for example, change DOM node attributes (either directly or by adding or removing classes from elements), and can also add, remove, or delete DOM nodes. Because styles are normally scoped to the entire document, the cost of doing these style calculations is proportional to the number of DOM nodes in the document (and the number of styles being applied).

- -

It is expected that over time, script will update the DOM, requiring us to recalculate styles. Normally, the changes to the DOM just result in the standard style calculation occurring immediately after the JavaScript has finished running during the 16ms window, inside the "Style" step. That's the ideal scenario.

- -

However, it's possible for script to do things that force multiple style calculations (or style flushes) to occur synchronously during the JavaScript part of the 16 ms window. The more of them there are, the more likely they'll exceed the 16ms frame budget. If that happens, some of them will be postponed until the next frame (or possibly multiple frames, if necessary), this skipping of frames is called jank.

- -

Generally speaking, you force a synchronous style flush any time you query for style information after the DOM has changed within the same frame tick. Depending on whether or not the style information you’re asking for has something to do with size or position, you may also cause a layout recalculation (also referred to as layout flush or reflow), which is also an expensive step (see {{anch("Detecting and avoiding synchronous reflow")}} below).

- -

To avoid this: avoid reading style information if you can. If you must read style information, do so at the very beginning of the frame, before any changes have been made to the DOM since the last time a style flush occurred.

- -

Historically, there hasn't been an easy way of doing this - however, {{bug(1434376)}} has recently landed some ChromeOnly helpers to the window binding to make this simpler.

- -

If you want to queue up some JavaScript to run after the next "natural" style and layout flush, try:

- -

// Suppose we want to get the computed "display" style of some node without
-// causing a style flush. We could do it this way:
-async function nodeIsDisplayNone(node) {
-  let display = await window.promiseDocumentFlushed(() => {
-    // Do _not_ under any circumstances write to the DOM in one of these
-    // callbacks!
-    return window.getComputedStyle(node).display;
-  });
-
-  return display == "none";
-}
-

- -

See {{anch("Detecting and avoiding synchronous reflow")}} for a more advanced example of getting layout information, and then setting it safely, without causing flushes.

- -

promiseDocumentFlushed is only available to priviledged script, and should be called on the inner window of a top-level frame. Calling it on the outer window of a subframe is not supported, and calling it from within the inner window of a subframe might cause the callback to fire even though a style and layout flush will still be required. These gotchas should be fixed by {{bug(1441173)}}.

- -

For now, it is up to you as the consumer of this API to not accidentally write to the DOM within the promiseDocumentFlushed callback. Doing so might cause flushes to occur for other promiseDocumentFlushed callbacks that are scheduled to fire in the same tick of the refresh driver. {{bug(1441168)}} tracks work to make it impossible to modify the DOM within a promiseDocumentFlushed callback.

- -

Writing tests to ensure you don’t add more synchronous style flushes

- -

Unlike reflow, there isn’t a “observer” mechanism for style recalculations. However, as of Firefox 49, the {{ifattribute("nsIDOMWindowUtils", "elementsRestyled")}} attribute records a count of how many style calculations have occurred for a particular DOM window.

- -

It should be possible to write a test that gets the nsIDOMWindowUtils for a browser window, records the number of styleFlushes, then synchronously calls the function that you want to test, and immediately after checks the styleFlushes attribute again. If the value went up, your code caused synchronous style flushes to occur.

- -

Note that your test and function must be called synchronously in order for this test to be accurate. If you ever go back to the event loop (by yielding, waiting for an event, etc), style flushes unrelated to your code are likely to run, and your test will give you a false positive.

- -

Detecting and avoiding synchronous reflow

- -

This is also sometimes called “sync layout”, "sync layout flushes" or “sync layout calculations”

- -

Sync reflow is a term bandied about a lot, and has negative connotations. It's not unusual for an engineer to have only the vaguest sense of what it is—and to only know to avoid it. This section will attempt to demystify things.

- -

The first time a document (XUL or HTML) loads, we parse the markup, and then apply styles. Once the styles have been calculated, we then need to calculate where things are going to be placed on the page. This layout step can be seen in the “16ms” pipeline graphic above, and occurs just before we paint things to be composited for the user to see.

- -

It is expected that over time, script will update the DOM, requiring us to recalculate styles, and then update layout. Normally, however, the changes to the DOM just result in the standard style calculation that occurs immediately after the JavaScript has finished running during the 16ms window.

- -

Interruptible reflow

- -

Since the early days, Gecko has had the notion of interruptible reflow. This is a special type of content-only reflow that checks at particular points whether or not it should be interrupted (usually to respond to user events).

- -

Because interruptible reflows can only be interrupted when laying out content, and not chrome UI, the rest of this section is offered only as context.

- -

When an interruptible reflow is interrupted, what really happens is that certain layout operations can be skipped in order to paint and process user events sooner.

- -

When an interruptible reflow is interrupted, the best-case scenario is that all layout is skipped, and the layout operation ends.

- -

The worst-case scenario is that none of the layout can be skipped despite being interrupted, and the entire layout calculation occurs.

- -

Reflows that are triggered "naturally" by the 16ms tick are all considered interruptible. Despite not actually being interuptible when laying out chrome UI, striving for interruptible layout is always good practice because uninterruptible layout has the potential to be much worse (see next section).

- -

To repeat, only interruptible reflows in web content can be interrupted.

- -

Uninterruptible reflow

- -

Uninterruptible reflow is what we want to avoid at all costs. Uninterruptible reflow occurs when some DOM node’s styles have changed such that the size or position of one or more nodes in the document will need to be updated, and then JavaScript asks for the size or position of anything. Since everything is pending a reflow, the answer isn't available, so everything stalls until the reflow is complete and the script can be given an answer. Flushing layout also means that styles must be flushed to calculate the most up-to-date state of things, so it's a double-whammy.

- -

Here’s a simple example, cribbed from this blog post by Paul Rouget:

- -

div1.style.margin = "200px";        // Line 1
-var height1 = div1.clientHeight;    // Line 2
-div2.classList.add("foobar");       // Line 3
-var height2 = div2.clientHeight;    // Line 4
-doSomething(height1, height2);      // Line 5

- -

At line 1, we’re setting some style information on a DOM node that’s going to result in a reflow - but (at just line 1) it’s okay, because that reflow will happen after the style calculation.

- -

Note line 2 though - we’re asking for the height of some DOM node. This means that Gecko needs to synchronously calculate layout (and styles) using an uninterruptible reflow in order to answer the question that JavaScript is asking (“What is the clientHeight of div1?”).

- -

It’s possible for our example to avoid this synchronous, uninterruptible reflow by moving lines 2 and 4 above line 1. Assuming there weren’t any style changes requiring size or position recalculation above line 1, the clientHeight information should be cached since the last reflow, and will not result in a new layout calculation.

- -

If you can avoid querying for the size or position of things in JavaScript, that’s the safest option—especially because it’s always possible that something earlier in this tick of JavaScript execution caused a style change in the DOM without you knowing it.

- -

Note that given the same changes to the DOM of a chrome UI document, a single synchronous uninterruptible reflow is no more computationally expensive than an interruptible reflow triggered by the 16ms tick. It is, however, advantageous to strive for reflow to only occur in the one place (the layout step of the 16ms tick) as opposed to multiple times during the 16ms tick (which has a higher probability of running through the 16ms budget).

- -

How do I avoid triggering uninterruptible reflow?

- -

Here's a list of things that JavaScript can ask for that can cause uninterruptible reflow, to help you think about the problem. Note that some items in the list may be browser-specific or subject to change, and that an item not occurring explicitly in the list doesn't mean it doesn't cause reflow. For instance, at time of writing accessing event.rangeOffset triggers reflow in Gecko, and does not occur in the earlier link. If you're unsure whether something causes reflow, check!

- -

Note how abundant the properties in that first list are. This means that when enumerating properties on DOM objects (e.g. elements/nodes, events, windows, etc.) accessing the value of each enumerated property will almost certainly (accidentally) cause uninterruptible reflow, because a lot of DOM objects have one or even several properties that do so.

- -

If you require size or position information, you have a few options.

- -

{{bug(1434376)}} has recently landed a helper in the window binding to make it easier for priviledged code to queue up JavaScript to run when we know that the DOM is not dirty, and size, position, and style information is cheap to query for.

- -

Here's an example:

- -

async function matchWidth(elem, otherElem) {
-  let width = await window.promiseDocumentFlushed(() => {
-    // Do _not_ under any circumstances write to the DOM in one of these
-    // callbacks!
-    return elem.clientWidth;
-  });
-
-  requestAnimationFrame(() => {
-    otherElem.style.width = `${width}px`;
-  });
-}

- -

Please see the section on promiseDocumentFlushed in {{anch("Detecting and avoiding synchronous style flushes")}} for more information on how to use the API.

- -

Note that queries for size and position information are only expensive if the DOM has been written to. Otherwise, we're doing a cheap look-up of cached information. If we work hard to move all DOM writes into requestAnimationFrame(), then we can be sure that all size and position queries are cheap.

- -

It's also possible (though less infallible than promiseDocumentFlushed) to queue JavaScript to run very soon after the frame has been painted, where the likelihood is highest that the DOM has not been written to, and layout and style information queries are still cheap. This can be done by using a setTimeout or dispatching a runnable inside a requestAnimationFrame callback, for example:

- -

requestAnimationFrame(() => {
-  setTimeout(() => {
-    // This code will be run ASAP after Style and Layout information have
-    // been calculated and the paint has occurred. Unless something else
-    // has dirtied the DOM very early, querying for style and layout information
-    // here should be cheap.
-  }, 0);
-});
-
-// Or, if you are running in privileged JavaScript and want to avoid the timer overhead,
-// you could also use:
-
-requestAnimationFrame(() => {
-  Services.tm.dispatchToMainThread(() => {
-    // Same-ish as above.
-  });
-});

- -

This also implies that querying for size and position information in requestAnimationFrame() has a high probability of causing a synchronous reflow.

- -

Other useful methods

- -

Below you'll find some suggestions for other methods which may come in handy when you need to do things without incurring synchronous reflow. These methods generally return the most-recently-calculated value for the requested value, which means the value may no longer be current, but may still be "close enough" for your needs. Unless you need precisely accurate information, they can be valuable tools in your performance toolbox.

- -

nsIDOMWindowUtils.getBoundsWithoutFlushing()

- -

getBoundsWithoutFlushing() does exactly what its name suggests: it allows you to get the bounds rectangle for a DOM node contained in a window without flushing layout. This means that the information you get is potentially out-of-date, but allows you to avoid a sync reflow. If you can make do with information that may not be quite current, this can be helpful.

- -

nsIDOMWindowUtils.getRootBounds()

- -

Like getBoundsWithoutFlushing(), getRootBounds() lets you get the dimensions of the window without risking a synchronous reflow.

- -

nsIDOMWindowUtils.getScrollXY()

- -

Returns the window's scroll offsets without taking the chance of causing a sync reflow.

- -

Writing tests to ensure you don’t add more unintentional reflow

- -

The interface {{source("docshell/base/nsIReflowObserver.idl", "nsIReflowObserver")}} lets us detect both interruptible and uninterruptible reflows. A number of tests have been written that exercise various functions of the browser (opening tabs, opening windows) and ensure that we don’t add new uninterruptible reflows accidentally while those actions occur.

- -

You should add tests like this for your feature if you happen to be touching the DOM.

- -

Detecting over-painting with paint flashing

- -

Painting is, in general, cheaper than both style calculation and layout calculation; still, the more you can avoid, the better. Generally speaking, the larger an area that needs to be repainted, the longer it takes. Similarly, the more things that need to be repainted, the longer it takes.

- -

Our graphics team has added a handy feature to help you detect when and where paints are occurring. This feature is called “paint flashing,” and it can be activated for both web content and the browser chrome. Paint flashing tints each region being painted with a randomly selected color so that it’s more easy to see what on the screen is being painted.

- -

You can activate paint flashing for browser chrome by setting nglayout.debug.paint_flashing_chrome to true.
You can activate paint flashing for web content by setting nglayout.debug.paint_flashing to true.

- -

After enabling these, exercise your function and see what’s painting. See a lot of flashing / colors? That means a lot of painting is going on. The worst case is called over-painting. This is when you draw multiple times over the same space. Unless transparency is involved, all but the last painting will be overwritten, becoming unnecessary. If you can find ways to avoid doing this, you can save substantial time.

- -

Keep in mind that painting occurs on the main thread. Remember, too, that the goal is to have as little happen on the main thread as possible. That means that finding and removing (when possible) over-painting is a good place to start reducing your burden on the main thread, which will in turn improve performance.

- -

Perhaps you’re animating something that requires a repaint? For example, transitioning the {{cssxref("background-color")}} of a DOM node from red to blue will result in a repaint for every frame of the animation, and paint flashing will reveal that. Consider using a different animation that can be accelerated by the GPU. These GPU-accelerated animations occur off of the main thread, and have a much higher probability of running at 60 FPS (see the section below called {{anch("Use the compositor for animations")}} for further details).

- -

Perhaps you’re touching some DOM nodes in such a way that unexpected repaints are occurring in an area that don’t need it. Best to investigate and try to remove those as best you can. Sometimes, our graphics layer invalidates regions in ways that might not be clear to you, and a section outside of the thing that just repainted will also repaint. Sometimes this can be addressed by ensuring that the thing changing is on its own layer (though this comes at a memory cost). You can put something on its own layer by setting its {{cssxref("z-index")}}, or by setting the {{cssxref("will-change")}} on the node, though this should be used sparingly.

- -

If you’re unsure why something is repainting, consider talking to our always helpful graphics team in the gfx room on Matrix, and they can probably advise you. Note that a significant number of the graphics team members are in the US Eastern Time zone (UTC-5 or UTC-4 during Daylight Saving Time), so let that information guide your timing when you ask questions in the gfx room .

- -

Adding nodes using DocumentFragments

- -

Sometimes you need to add several DOM nodes as part of an existing DOM tree. For example, when using XUL {{XULElem("menupopup")}}s, you often have script which dynamically inserts {{XULElem("menuitem")}}s. Inserting items into the DOM has a cost. If you're adding a number of children to a DOM node in a loop, it's often more efficient to batch them into a single insertion by creating a {{domxref("DocumentFragment")}}, adding the new nodes to that, then inserting the DocumentFragment as a child of the desired node.

- -

A DocumentFragment is maintained in memory outside the DOM itself, so changes don't cause reflow. The API is straightforward:

- -

Create the DocumentFragment by calling {{domxref("Document.createDocumentFragment()")}}.
Create each child element (by calling {{domxref("Document.createElement()")}} for example), and add each one to the fragment by calling {{domxref("Node.appendChild", "DocumentFragment.appendChild()")}}.
Once the fragment is populated, append the fragment to the DOM by calling {{domxref("Node.appendChild", "appendChild()")}} on the parent element for the new elements.

- -

This example has been cribbed from davidwalsh’s blog post:

- -

// Create the fragment
-
-var frag = document.createDocumentFragment();
-
-// Create numerous list items, add to fragment
-
-for(var x = 0; x < 10; x++) {
-    var li = document.createElement("li");
-    li.innerHTML = "List item " + x;
-    frag.appendChild(li);
-}
-
-// Mass-add the fragment nodes to the list
-
-listNode.appendChild(frag);
-

- -

The above is strictly cheaper than individually adding each node to the DOM.

- -

The Gecko profiler add-on is your friend

- -

The Gecko profiler is your best friend when diagnosing performance problems and looking for bottlenecks. There’s plenty of excellent documentation on MDN about the Gecko profiler:

- -

Don’t guess—measure.

- -

If you’re working on a performance improvement, this should go without saying: ensure that what you care about is actually improving by measuring before and after.

- -

Landing a speculative performance enhancement is the same thing as landing speculative bug fixes—these things need to be tested. Even if that means instrumenting a function with a {{jsxref("Date.now()")}} recording at the entrance, and another Date.now() at the exit points in order to measure processing time changes.

- -

Prove to yourself that you’ve actually improved something by measuring before and after.

- -

Use the performance API

- -

The performance API is very useful for taking high-resolution measurements. This is usually much better than using your own hand-rolled timers to measure how long things take. You access the API through {{domxref("Window.performance")}}.

- -

Also, the Gecko profiler back-end is in the process of being modified to expose things like markers (from {{domxref("Performance.mark", "window.performance.mark()")}}).

- -

Use the compositor for animations

- -

Performing animations on the main thread should be treated as deprecated. Avoid doing it. Instead, animate using {{domxref("Element.animate()")}}. See the article Animating like you just don't care for more information on how to do this.

- -

Explicitly define start and end animation values

- -

Some optimizations in the animation code of Gecko are based on an expectation that the from (0%) and the to (100%) values will be explicitly defined in the @keyframes definition. Even though these values may be inferred through the use of initial values or the cascade, the offscreen animation optimizations are dependent on the explicit definition. See this comment and a few previous comments on that bug for more information.

- -

Use IndexedDB for storage

- -

AppCache and LocalStorage are synchronous storage APIs that will block the main thread when you use them. Avoid them at all costs!

- -

IndexedDB is preferable, as the API is asynchronous (all disk operations occur off of the main thread), and can be accessed from web workers.

- -

IndexedDB is also arguably better than storing and retrieving JSON from a file—particularly if the JSON encoding or decoding is occurring on the main thread. IndexedDB will do JavaScript object serialization and deserialization for you using the structured clone algorithm, meaning that you can stash things like maps, sets, dates, blobs, and more, without having to do conversions for JSON compatibility.

- -

A Promise-based wrapper for IndexedDB, IndexedDB.jsm, is available for chrome code.

- -

Test on weak hardware

- -

For the folks paid to work on Firefox, we tend to have pretty powerful hardware for development. This is great, because it reduces build times, and means we can do our work faster.

- -

We should remind ourselves that the majority of our user base is unlikely to have similar hardware. Look at the Firefox Hardware Report to get a sense of what our users are working with. Test on slower machines to make it more obvious to yourself if what you’ve written impacts the performance of the browser.

- -

Consider loading scripts with the subscript loader asynchronously

- -

If you've ever used the subscript loader, you might not know that it can load scripts asynchronously, and return a Promise once they're loaded. For example:

- -

Services.scriptloader.loadSubScriptWithOptions(myScriptURL, { async: true }).then(() => {
-  console.log("Script at " + myScriptURL + " loaded asynchronously!");
-});

diff --git a/files/pt-br/mozilla/firefox/privacidade/index.html b/files/pt-br/mozilla/firefox/privacidade/index.html deleted file mode 100644 index dd6979435e..0000000000 --- a/files/pt-br/mozilla/firefox/privacidade/index.html +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Privacidade -slug: Mozilla/Firefox/Privacidade -translation_of: Mozilla/Firefox/Privacy ---- -

Proteção de rastreamento

- - - - diff --git "a/files/pt-br/mozilla/firefox/privacidade/prote\303\247\303\243o_de_rastreamento/index.html" "b/files/pt-br/mozilla/firefox/privacidade/prote\303\247\303\243o_de_rastreamento/index.html" deleted file mode 100644 index 438c240001..0000000000 --- "a/files/pt-br/mozilla/firefox/privacidade/prote\303\247\303\243o_de_rastreamento/index.html" +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Proteção de rastreamento -slug: Mozilla/Firefox/Privacidade/Proteção_de_rastreamento -translation_of: Mozilla/Firefox/Privacy/Tracking_Protection ---- -

- -

O que é proteção de rastreamento?

- -

Começando na versão 42, o Firefox Desktop e o Firefox para Android incluem proteção de rastreamento embutida. Nas janelas de Navegação Privada (guias, no Firefox para Android), o Firefox bloqueará o conteúdo carregado de domínios que acompanham os usuários em todos os sites.

- -

Alguns conteúdos bloqueados fazem parte do layout da página e os usuários podem notar problemas de layout onde o Firefox bloqueou essas cargas. Às vezes, os usuários não percebem nada, mas a grade da página pode funcionar de modo que outros elementos da página se deslizem para preencher os buracos deixados pelos elementos bloqueados.

- -

Quando o Firefox bloqueia o conteúdo, ele registrará uma mensagem no Console da Web como este:

- -

The resource at "http://some/url" was blocked because tracking protection is enabled.

- -

Note que, com o Firefox para Android, você pode acessar a saída do console usando o depurador remoto.

- -

A interface do usuário do Firefox indicará aos usuários quando o conteúdo foi bloqueado e habilitá-los a desbloqueá-lo para a sessão atual se eles escolherem. Os usuários também poderão desativar a proteção de rastreamento inteiramente se eles escolherem.

- -

Como o Firefox escolhe o que bloquear?

- -

O conteúdo é bloqueado com base no domínio do qual ele deve ser carregado.

- -

O Firefox enviará uma lista de sites que foram identificados como envolvidos no rastreamento de sites de usuários. Quando a proteção de rastreamento é ativada, o Firefox bloqueará o conteúdo de sites na lista.

- -

Os sites que rastreiam usuários são mais comuns os sites de publicidade e análise de terceiros.

- -

O que isso significa para o seu site?

- -

Mais obviamente, isso significa que quando a proteção de rastreamento está habilitada:

- -

O conteúdo veiculado a partir de rastreadores de terceiros não será visível para usuários
Seu site não poderá usar serviços de publicidade ou analítica de terceiros que se envolvam em rastreamento

- -

Mais sutilmente, se outras partes do seu site dependerem de rastreadores sendo carregados, essas partes também serão quebradas quando a proteção de rastreamento estiver ativada. Por exemplo, se o seu site incluir um retorno de chamada que é executado quando o conteúdo de um site de rastreamento é carregado, o retorno de chamada não será executado.

- -

Por exemplo, você não deve usar o Google Analytics da seguinte maneira:

- -

<a href="http://www.example.com" onclick="trackLink('http://www.example.com', event);">Visit example.com</a>
-<script>
-function trackLink(url,event) {
-    event.preventDefault();
-    ga('send', 'event', 'outbound', 'click', url, {
-     'transport': 'beacon',
-     'hitCallback': function() {
-       document.location = url;
-     }
-   });
-}
-</script>

- -

Em vez disso, você deve considerar verificar quando o objeto "ga", para o Google Analytics, foi inicializado ou não:

- -

<a href="http://www.example.com" onclick="trackLink('http://www.example.com', event);">Visit example.com</a>
-<script>
-function trackLink(url,event) {
-    event.preventDefault();
-    if (window.ga && ga.loaded) {
-         ga('send', 'event', 'outbound', 'click', url, {
-         'transport': 'beacon',
-         'hitCallback': function() { document.location = url; }
-       });
-    } else {
-        document.location = url;
-    }
-}
-</script>
-

- -

Mais informações sobre esta técnica estão disponíveis em Google Analytics, Privacy, and Event Tracking.

- -

Observe que, dependendo de um terceiro dessa maneira, não é uma boa prática, pois isso significa que seu site pode ser quebrado se o terceiro estiver lento ou não disponível, ou se o rastreador estiver bloqueado por um complemento.

- - - - diff --git a/files/pt-br/mozilla/firefox/privacy/storage_access_policy/errors/cookieblockedtracker/index.html b/files/pt-br/mozilla/firefox/privacy/storage_access_policy/errors/cookieblockedtracker/index.html deleted file mode 100644 index 0813b1fd2c..0000000000 --- a/files/pt-br/mozilla/firefox/privacy/storage_access_policy/errors/cookieblockedtracker/index.html +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: 'Bloquado: Solicitações de acesso de armazenamento de rastreadores' -slug: Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedTracker -tags: - - Armazenamento - - Cookies - - Erros - - Política de acesso a armazenamento - - Rastreamento -translation_of: Mozilla/Firefox/Privacy/Storage_access_policy/Errors/CookieBlockedTracker ---- -

- -

Mensagem

- -

Firefox:

- -

O pedido para acessar cookies ou armazenamento em "X" foi bloqueado porque veio de um rastreador e o bloqueio de conteúdo está ativado.
-

- -

Oque deu errado?

- -

A requisição para accessar os cookies ou armazenamento foi bloqueada por que o navegador identificou como proveniente de um rastreador e o bloqueio de conteúdo está ativado.

- -

A permissão pode ser modificada ou removida por:

- -

Indo a Preferências > Bloqueio de Conteúdo e - -
- adicionando uma exceção com o botão Gerenciar Exceções…
- escolhendo o Bloqueio de conteúdo personalizado e desmarcar a caixa de seleção Rastreador
-

- -

se a resolução que foi bloqueada não precisar de autenticação, você consegue resolver a aviso de erro adicinando um atributo crossorigin="anonymous" para o elemento relevante.

- -

Veja também

- -

diff --git a/files/pt-br/mozilla/firefox/privacy/storage_access_policy/errors/index.html b/files/pt-br/mozilla/firefox/privacy/storage_access_policy/errors/index.html deleted file mode 100644 index a1e1f54a75..0000000000 --- a/files/pt-br/mozilla/firefox/privacy/storage_access_policy/errors/index.html +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Errors -slug: Mozilla/Firefox/Privacy/Storage_access_policy/Errors -tags: - - Cookies - - Errors - - NeedsTranslation - - Storage - - TopicStub - - storage access policy -translation_of: Mozilla/Firefox/Privacy/Storage_access_policy/Errors ---- -

- -

This page lists the errors that can be raised due to Firefox's anti-tracking functionality, governed by the Storage access policy. You can find further information about them by clicking on the links below:

- -

A request to access cookies or storage was blocked because

- -

diff --git a/files/pt-br/mozilla/firefox/privacy/storage_access_policy/index.html b/files/pt-br/mozilla/firefox/privacy/storage_access_policy/index.html deleted file mode 100644 index c86f213323..0000000000 --- a/files/pt-br/mozilla/firefox/privacy/storage_access_policy/index.html +++ /dev/null @@ -1,263 +0,0 @@ ---- -title: 'Storage access policy: Block cookies from trackers' -slug: Mozilla/Firefox/Privacy/Storage_access_policy -tags: - - NeedsTranslation - - Privacy - - TopicStub - - storage access policy - - tracking protection -translation_of: Mozilla/Firefox/Privacy/Storage_access_policy ---- -

- -

Firefox includes a new storage access policy that blocks cookies and other site data from third-party tracking resources. This policy is designed as an alternative to the older cookie policies, which have been available in Firefox for many years. This policy protects against cross-site tracking while minimizing the site breakage associated with traditional cookie blocking. This article explains how the policy works and how you can test it.

- -

Testing in Firefox

- -

This cookie policy has been available in Firefox since version 63. This documentation describes the policy that we intend to ship to Firefox Release users, but may not match what is implemented in the current Release version of Firefox. That's because we document new aspects of the policy as soon as they land in Firefox Nightly, our pre-release channel. Firefox Nightly may also contain experimental features that we don't yet plan to ship to Release users; experimental features will not be included in this documentation, but may nevertheless impact the functionality of domains classified as trackers.

- -

We recommend sites test with Firefox Nightly, as this includes the newest version of our protections. As described above, note that Nightly may include additional protections that end up getting removed or changed before they reach our Release users. We’ll keep this page updated with the newest information as we strengthen our protections.

- -

These protections are on by default in Nightly. The cookie policy can be enabled in other versions of Firefox through the Content Blocking settings (these steps will vary by version; the linked documentation includes a dropdown to select the appropriate Firefox version).

- -

Report Broken Sites

- -

If you find a website broken as a result of this change, file a bug under the Tracking Protection component within the Firefox product on Bugzilla. Alternatively you can report broken sites directly in Firefox by clicking "Report a Problem" in the Content Blocking section of the Control Center (this shortcut may not be available in all versions of Firefox).

- -

Tracking protection explained

- -

How does Firefox determine which resources are tracking resources?

- -

Firefox uses the Tracking Protection list to determine which resources are tracking resources. The Tracking Protection list is maintained by Disconnect. When the list is applied in Firefox, we make two important changes:

- -

First, we only use the "Basic Protection" version of the list, which excludes some categories of trackers. In the future, we may expand our protections to use the "Strict Protection" version of the list.
Second, Firefox uses an additional "entity list", which prevents domains from being classified as trackers when they are loaded on a top-level site owned by the same organization.

- -

Firefox uses the built-in Tracking Protection URL classifier to determine which resources match the tracking protection list. Domains are matched against the list in accordance with the SafeBrowsing v4 specification. Specifically, we check the exact hostname of the resource against the list, as well as the last four hostnames formed by starting with the last five components and successively removing the leading component. Consider the following examples:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Hostname on the list	Hostname of resource	Matched
`example.com`	`example.com`	Yes
`example.com`	`a.b.example.com`	Yes
`blah.example.com`	`example.com`	No
`a.b.example.com`	`c.d.example.com`	No
`blah.example.com`	`foo.blah.example.com`	Yes

- -

What does the storage access policy block?

- -

The storage access policy blocks resources identified as trackers from accessing their cookies and other site storage when they are loaded in a third-party context. This prevents those resources from retrieving tracking identifiers stored in cookies or site storage and using them to identify users across visits to multiple first parties. Specifically, Firefox does this by imposing the following restrictions:

- -

Cookies:

- -

Block {{httpheader("Cookie")}} request headers and ignore {{httpheader("Set-Cookie")}} response headers.
Return an empty string for calls to {{domxref("Document.cookie")}} and ignore requests to set cookies via Document.cookie.

- -

DOM Storage:

- -

localStorage: Window.localStorage is null. Thus, attempts to read and write using this object will throw a TypeError exception.
sessionStorage: read and write attempts are permitted.
IndexedDB: read and write attempts throw a SecurityError exception.

- -

Messaging and Workers:

- -

Broadcast Channel: attempts to create a new {{domxref("BroadcastChannel")}} will throw a SecurityError exception.
Shared Worker: attempts to create a new {{domxref("SharedWorker")}} will throw a SecurityError exception.
Service Worker: attempts to create a new {{domxref("ServiceWorker")}} will throw a SecurityError exception.

- -

DOM Cache:

- -

Calls to {{domxref("CacheStorage")}} will always reject with a SecurityError.

- -

Browser caches:

- -

The HTTP cache and the Image cache are partitioned for tracking resources, such that each top-level origin will have a separate partition and tracking resources on different top-level origins will be cached separate from each other.

- -

Network connections:

- -

TLS sessions will not be resumed using a session ticket when an HTTPS connection is made to an embedded third-party resource that is classified as a tracker.
HTTP connection reuse by domains classified as trackers is limited to requests that occur under the same top-level origin. For example, a request for content from tracker.example on news.example will not reuse an HTTP connection with a request for content from tracker.example on shopping.example or with requests that occur when tracker.example is visited directly (i.e., as a first party).

- -

What is not blocked by the policy?

- -

This policy does not currently restrict third-party storage access for resources that are not classified as tracking resources. We may choose to apply additional restrictions to third-party storage access in the future.
The restrictions applied by the policy will not prevent third-party scripts classified as tracking resources from accessing storage in the main context of the page. These scripts can continue to use storage scoped to the top-level origin.
Origins classified as trackers will have access to their own storage when they are loaded in a first-party context.
Cross-origin resources loaded from the same eTLD+1 as the top-level context will still have access to their storage.
Origins normally classified as trackers will not be blocked if the top-level page origin is determined to be from the same organization as them.

- -

Storage access grants

- -

In order to improve web compatibility and permit third-party integrations that require storage access, Firefox will grant storage access scoped to the first party for a particular third-party origin as described in this section. Currently, Firefox includes some web compatibility heuristics that grant storage access to third-party resources classified as trackers when a user interacts with those third parties. We do this when we expect that not granting access would cause the web page to break. We also support an initial implementation of the Storage Access API, through which embedded {{htmlelement("iframe")}}s can request storage access by calling {{domxref("Document.requestStorageAccess()")}}. Although both of these approaches provide the same level of storage access, we recommend third parties switch to using the Storage Access API in order to guarantee their access to storage.

- -

Automatic storage access upon interaction

- -

In order to improve web compatibility, Firefox currently includes some heuristics to grant storage access automatically to third parties that receive user interaction. These heuristics are intended to allow some third-party integrations that are common on the web to continue to function. They are intended to be temporary and will be removed in a future version of Firefox. They should not be relied upon for current and future web development.

- -

Third-party storage access may be granted to resources that have been classified as tracking resources when a user gesture triggers a pop-up window that has opener access to the originating document. When that occurs, there are two possible ways a third-party origin can be granted access:

- -

The origin of the resource that is initially loaded in the pop-up window is granted storage access on the opener document if that origin has received user interaction as a first party within the past 30 days.
After the initial resource is loaded in the pop-up window, the window may go through a series of redirects to other hosts. If a user interacts with the pop-up window following a redirect, the origin of the content loaded in the pop-up window is given storage access on the opener document.

- -

Scope of storage access

- -

When storage access is granted, it is scoped to the origin of the opener document or subdomains of that origin. Access that is granted on the subdomain of an origin does not extend to the top-level origin. As an example, if a resource from tracker.example is granted storage access on foo.example.com, then tracker.example will be able to access its cookies on bar.foo.example.com but not example.com. Instead, if tracker.example were granted access on example.com it would be able to access its storage on bar.foo.example.com, foo.example.com, and example.com.

- -

When storage access is granted to tracker.example on example.com, all resources loaded from tracker.example on any top-level document loaded from example.com are immediately given storage access. This includes all resources loaded in the main context of the page, embedded <iframe>s, and resources loaded within embedded <iframe>s. Storage access is not extended to other resources loaded on example.com (e.g. other-tracker.example), nor to other first parties on which tracker.example is embedded (e.g. example.org).

- -

Storage access grants extend into the first level of nested contexts, but no further. This means that <iframe>s embedded in the main context of the page and loaded from a domain classified as a tracker will have full access to all storage locations accessible through JavaScript. Similarly, requests for resources loaded in <iframe>s embedded in the main context of the page will have access to HTTP cookies. However, further nested contexts, including but not limited to those from the origin classified as a tracker, will not be granted storage access.

- -

Consider the following embedding scenarios on a top-level page loaded from example.com on which tracker.example has been granted storage access.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Embedding	tracker.example resource storage access
An image is loaded from `tracker.example` and embedded in the main context of `example.com`.	HTTP: Yes - JS: N/A
`example.com` embeds an `<iframe>` from `example.org`. That `<iframe>` goes on to load an image from `tracker.example`.	HTTP: Yes - JS: N/A
`example.com` embeds an `<iframe>` from `example.org`. That `<iframe>` goes on to embed an `<iframe>` from `tracker.example`.	HTTP: Yes - JS: No
`example.com` embeds an `<iframe>` from `tracker.example`.	HTTP: Yes - JS: Yes
`example.com` embeds an `<iframe>` from `example.com` (same origin). The nested `<iframe>` embeds an `<iframe>` from `tracker.example`.	HTTP: Yes - JS: No

- -

Storage access expiration

- -

The storage access grant expires after 30 days. Domains classified as tracking resources may be granted third-party storage access on multiple first parties, and the storage permission for each party expires independently. The above heuristics will also serve to extend the lifetime of a third-party storage permission on origins that have already been granted access. Each time the heuristic is activated, or a success call to the Storage Access API is made, the pre-existing storage access expiration will be extended by 30 days, counting from the time the previous access was granted.

- -

Please note that in the future we expect to make changes to how long storage access will remain valid for. As mentioned before, the way to know that you will be able to use storage as a third-party going forward will be using the Storage Access API.

- -

Debugging

- -

We encourage site owners to test their sites, particularly those that rely on third-party content integrations. We’ve added several new features to Firefox to make testing easier.

- -

Developer Tools notifications

- -

The Network Monitor in Firefox Developer Tools now includes an indicator for all resource requests that have been classified as tracking resources. This indicator is shown as a shield icon in the domain column. In the sample image below, trackertest.org is classified as a tracking resource, while the request to example.com is not.

- -

network requests in Firefox devtools indicating which ones are tracking resources with a small shield icon

- -

Adding custom domains to the Tracking Protection list

- -

Curious how things will work if a third-party domain on your site were classified as a tracker? We’ve added a preference that allows you to add custom domains to the Tracking Protection URL classifier. To do so:

- -

Type about:config in your address bar. If you are presented with a page that warns you "This may void your warranty!", click "I accept the risk!"
Right click on the next page and click "New" > "String".
For the preference name enter "urlclassifier.trackingAnnotationTable.testEntries".
For the preference value enter comma separated origins that you’d like to have classified as trackers. E.g. "example.net,example.org".

- -

Warning: Be sure to remove these entries after you have finished testing.

- -

FAQ

- -

This cookie policy has the potential to lead to site breakage, but has been designed to allow common third-party integrations to continue to work while preventing cross-site tracking. In this section we describe the functionality you can expect in different integration scenarios.

- -

Will this storage access policy block ads from displaying on my website?

- -

No — this feature only restricts access to cookies and site data that can be used to track users across websites. Blocking tracking identifiers does not prevent the display of advertisements.

- -

I use a third-party analytics service that is classified as a tracker. Will I still receive analytics data?

- -

This depends on how the third-party analytics service is implemented. Third-party analytics providers will no longer be able to user their third-party storage to collect data. This means that providers using cookies which are scoped to their third-party domain, or local storage and other site data stored under their origin, will no longer have access to those identifiers across other websites.

- -

If these services are embedded into the main context of the page, they can continue to use first-party cookies and site storage to track users across page visits on that specific first-party domain.

- -

I use third-party services for social login, like, and share button integration. Will my users still be able to make use of these services?

- -

This depends on how the social integration is implemented. We expect that many of the popular social integrations will continue to function as they do under Firefox’s current cookie policy with some minor differences in the user experience.

- -

A social content provider that is classified as a tracker will not have access to their third-party cookies when the user first visits a new first party. Thus, the user may appear logged out to the service despite being logged in when they visit the provider’s website directly. Depending on the type of integration, the user may have to take some action to interact with the social content provider before the provider is given access to their cookies. For example:

- -

For social login, the user may have to click a login button on the first party.
For social like or share buttons, the user will have to first interact with the button in a logged-out state. Once they do, many social content providers will prompt them to log in.

- -

After these interactions, the provider will receive third-party storage access if they prompt the user in a way that is captured by the storage access activation heuristics described above. These providers should consider switching to explicitly request storage access through the Storage Access API as soon as possible. An initial implementation of this API is currently available in Nightly.

- - - -

I use third-party pixels and other tools to measure the effectiveness of my ad campaigns. Will I still be able to measure the conversion rate of my ads?

- -

This depends on how the third party has implemented the measurement tool, but generally ad conversion measurement will be more difficult. Consider the following examples:

- -

You run an ad on a social media website that is seen several times by a user, but never clicked. That user later visits your website, which includes a conversion tracking tag from the same social media website. This type of conversion is often referred to as a “view-through conversion.” Since the social media website does not have access to their third-party storage, they will not recognize the user as the same user that saw the advertisements on their website and the conversion will not be tracked. We expect that most view-through conversion tracking techniques will no longer work, including those offered by display networks.
You run an ad on a display network or social media website that is clicked by a user. That user lands on your website, which includes a conversion tracking tag from the same website that displayed your ad. This type of conversion is often referred to as a “click-through conversion.” Since the social media site or display network will not have access to their third-party storage, they will not recognize the user as the same user that saw the advertisements on their website and the conversion will not be tracked. We expect that this version of click-through conversion will no longer work.
You run an ad that appears on a social media website. A user clicks on your advertisement and is taken to a landing page that contains a conversion tracking tag from the third-party network. On the social media website, the network annotates the advertisement landing page URL with a query parameter that signals that the visit was the result of a click on an advertisement. On your website, the display network’s tag checks the URL query parameters and saves any ad tracking parameters to first-party storage. If a user later completes a conversion event, the network’s tag checks first-party storage to determine which click (or clicks) was responsible for the visit. We expect that click-through conversion implemented in this way will continue to work.

-- cgit v1.2.3-54-g00ecf