From 074785cea106179cb3305637055ab0a009ca74f2 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:42:52 -0500 Subject: initial commit --- .../edi\303\247\303\243o_programador/index.html" | 36 +++ files/pt-pt/mozilla/firefox/index.html | 73 +++++ .../mozilla/firefox/multiple_profiles/index.html | 244 +++++++++++++++++ .../cross_process_object_wrappers/index.html | 157 +++++++++++ .../depuracao_de_frame_scripts/index.html | 56 ++++ .../gestor_de_mensagens/index.html | 74 +++++ .../multiprocess_firefox/glossario/index.html | 36 +++ .../firefox/multiprocess_firefox/index.html | 79 ++++++ .../limitacoes_de_chrome_scripts/index.html | 215 +++++++++++++++ .../limitacoes_de_frame_scripts/index.html | 103 +++++++ .../quais_os_uris_que_carregam_e_onde/index.html | 62 +++++ .../resumo_t\303\251cnico/index.html" | 164 ++++++++++++ files/pt-pt/mozilla/firefox/releases/3/index.html | 298 +++++++++++++++++++++ files/pt-pt/mozilla/firefox/releases/70/index.html | 140 ++++++++++ files/pt-pt/mozilla/firefox/releases/index.html | 25 ++ 15 files changed, 1762 insertions(+) create mode 100644 "files/pt-pt/mozilla/firefox/edi\303\247\303\243o_programador/index.html" create mode 100644 files/pt-pt/mozilla/firefox/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiple_profiles/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiprocess_firefox/cross_process_object_wrappers/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiprocess_firefox/depuracao_de_frame_scripts/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiprocess_firefox/gestor_de_mensagens/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiprocess_firefox/glossario/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiprocess_firefox/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_chrome_scripts/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_frame_scripts/index.html create mode 100644 files/pt-pt/mozilla/firefox/multiprocess_firefox/quais_os_uris_que_carregam_e_onde/index.html create mode 100644 "files/pt-pt/mozilla/firefox/multiprocess_firefox/resumo_t\303\251cnico/index.html" create mode 100644 files/pt-pt/mozilla/firefox/releases/3/index.html create mode 100644 files/pt-pt/mozilla/firefox/releases/70/index.html create mode 100644 files/pt-pt/mozilla/firefox/releases/index.html (limited to 'files/pt-pt/mozilla/firefox') diff --git "a/files/pt-pt/mozilla/firefox/edi\303\247\303\243o_programador/index.html" "b/files/pt-pt/mozilla/firefox/edi\303\247\303\243o_programador/index.html" new file mode 100644 index 0000000000..3f3e7d3c90 --- /dev/null +++ "b/files/pt-pt/mozilla/firefox/edi\303\247\303\243o_programador/index.html" @@ -0,0 +1,36 @@ +--- +title: Edição do Programador +slug: Mozilla/Firefox/Edição_Programador +tags: + - Beta + - Bugs + - Developer Edition + - Edição de Desenvolvimento + - Edição do Programador + - Erros + - Latest + - Mais Recentes +translation_of: Mozilla/Firefox/Developer_Edition +--- +
{{FirefoxSidebar}}
+ +

A 'Edição do Programador' do Firefox é uma versão do Firefox que está preparada para os programadores da Web. Esta inclui:

+ + + +

Novidades na Edição do Programador?

+ +

Transferir a Edição do Programador

diff --git a/files/pt-pt/mozilla/firefox/index.html b/files/pt-pt/mozilla/firefox/index.html new file mode 100644 index 0000000000..2e57b0d4f0 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/index.html @@ -0,0 +1,73 @@ +--- +title: Firefox +slug: Mozilla/Firefox +tags: + - Firefox + - Landing + - Mozilla +translation_of: Mozilla/Firefox +--- +
{{FirefoxSidebar}}
+ +

Firefox é o navegador popular da Web da Mozilla, disponível para múltiplas plataformas, incluindo Linux, OS X e Windows para PC e em todos os dispositivos móveis Android e iOS. Com ampla compatibilidade, as tecnologias da Web mais recentes, e ferramentas de programação poderosas, o Firefox é uma excelente escolha, tanto para os programadores da Web como para os utilizadores finais.

+ +

O Firefox é um projeto de código aberto; a maior parte do código é fornecido pela nossa comunidade enorme de voluntários. Aqui pode aprender sobre como contribuir para o projeto Firefox e irá encontrar também hiperligações para informação sobre a criação de Extras do Firefox, utilizando as ferramentas de programador no Firefox, e outros tópicos.

+ +
+

Aprenda a criar Extras para o Firefox, como desenvolver e criar o próprio Firefox, e como os internos do Firefox e os respetivos subprojetos funcionam.

+
+ + + +

Canais do Firefox

+ +

O Firefox está disponível em cinco canais.

+ +

Firefox Nightly

+ +

Todas as noites nós contruimos o Firefox a partir do último código disponível em mozilla-central. Estas configurações destinam-se aos programadores do Firefox ou para aqueles que desejam experimentar as últimas funcionalidades inovadoras enquanto estas estão ainda em fase de desenvolvimento.

+ +

Transferir Firefox Nightly

+ +

Edição do Programador do Firefox

+ +

Esta é uma versão do Firefox personalizada para programadores. A cada seis semanas, nós selecionamos as funcionalidades do Firefox Nightly que estão estáveis o suficiente e criamos uma nova versão da Edição do Programador do Firefox. Nós adicionamos também algumas funcionalidades extra para programadores, que estão apenas disponíveis neste canal.

+ +

Saiba mais acerca da Edição do Programador do Firefox.

+ +

Transferir Firefox Developer Edition

+ +

Firefox Beta

+ +

Após utilizar a Edição do Programador do Firefox por seis semanas, nós selecionamos as funcionalidades que estão estáveis o suficiente e criamos uma nova versão do Firefox Beta. As configurações do Firefox Beta destinam-se a entusiastas do Firefox para testar as funcionalidades destinadas a serem lançadas na próxima versão do Firefox.

+ +

Transferir Firefox Beta

+ +

Firefox

+ +

Após estabilizar para outras seis semanas com a versão Beta, nós estamos prontos para lançar as novas funcionalidades para milhões de utilizadores numa nova versão de lançamento do Firefox.

+ +

Transferir Firefox

+ +

Firefox Extended Support Release (ESR)

+ +

Firefox ESR is the long-term support edition of Firefox for desktop for use by organizations including schools, universities, businesses and others who need extended support for mass deployments.

+ +

Learn more about Firefox Extended Support Release.

+ +

Transferir Firefox ESR

+ +

Perfis do Firefox

+ +

If you find yourself using multiple Firefox channels—or just multiple configurations—on a regular basis, you should read how to use multiple Firefox profiles by turning Firefox's Profile Manager and other profile management tools to your advantage.

diff --git a/files/pt-pt/mozilla/firefox/multiple_profiles/index.html b/files/pt-pt/mozilla/firefox/multiple_profiles/index.html new file mode 100644 index 0000000000..b7935947d7 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiple_profiles/index.html @@ -0,0 +1,244 @@ +--- +title: Múltiplos perfis do Firefox +slug: Mozilla/Firefox/Multiple_profiles +tags: + - Firefox + - Guía + - Perfis + - Perguntas e Respostas + - Principiante +translation_of: Mozilla/Firefox/Multiple_profiles +--- +
{{FirefoxSidebar}}
+ +

Um perfil no Firefox é a coleção de definições. personalizações, extras, e outras personalizações que um utilizador criou ou instalou na sua cópia do Firefox. Pode encontrar mais detalhes sobre os perfis no site de apoio do utilizador final da Mozilla.

+ +

Razões para ter múltiplos profiles

+ +

The casual user may want to have different profiles for different family members. Having different profiles would allow each person to have his or her own set of bookmarks, settings, and add-ons.

+ +

Web developers might want a secondary profile for testing websites, apps, or other projects on different Firefox channels. For example, you might want to have some extensions installed for Web development, but not for general-purpose Web browsing. While using the Nightly channel, you may encounter some add-ons that have become temporarily incompatible with new API changes, until the add-on developer has a chance to update them. You can remove such add-ons from your profile for Nightly use while keeping them for use with other profiles.

+ +

For QA, testing, and bug triaging contributors, you may want to have multiple development versions of Firefox installed, each with its own profile. Creating new profiles for testing can keep you from losing your preferences, bookmarks, and history. It takes little time to set up a new profile, and once it is complete, all of your Firefox versions will update separately and can be run simultaneously.

+ +

Canais de desenvolvimento do navegador disponíveis

+ +

There are four available browser channels, each at a different level of stability and development. The four channels are Release, Beta, Developer Edition, and Nightly. The Release channel is recommended for most users, as it is the "official release" channel. However, for those more adventurous, you can try one of the other three channels to see what is coming in Firefox and play around with emerging features. The Beta channel contains the features that are expected to be in the next release of Firefox and are in final stages of testing. Aurora contains experimental features, which are not yet at beta quality. Nightly contains the latest code from Firefox developers and is the least stable channel.

+ +

Ferramentas de terceiros

+ +

In addition to the built-in Profile Manager and the external Profile Manager, there are a few third-party tools that make working with multiple profiles easy.

+ +
+

This list is by no means exhaustive. Please add any helpful tools you discover to the list!

+
+ +

Mac OS X

+ + + +

Gestão de perfis

+ +

Determining the profile while Firefox is running

+ +

To determine the profile of a currently-running Firefox instance in Windows, macOS or Linux,

+ +
    +
  1. Type about:profiles into the browser URL search bar.
    2. +
  2. The page presents a list of all of your profiles, each beginning with "Profile: " followed by its name.
    3. +
  3. The one being run by this Firefox instance will include the bold text "This is the profile in use" For example, if you find that text beneath the entry for "Profile: Suzie", then you are running in a profile named Suzie.
    4. +
+ +

Launching Firefox into a Desired Profile

+ +

You cannot change the profile while Firefox is running.  Although it is possible in some cases to have multiple instances of Firefox running in different profiles, to avoid confusion, you should first exit/quit/terminate all running instances of Firefox, FirefoxDeveloperEdition or Nightly.  Then follow the instructions below, applicable to your operating system.

+ +

Windows

+ +
Windows XP
+ +
    +
  1. Click the Start button.
    2. +
  2. Click "Run".
    3. +
  3. +

    Type firefox --ProfileManager.

    +
    4. +
+ +
Windows Vista/7
+ +
    +
  1. Click the Start button.
    2. +
  2. Click the search bar at the bottom.
    3. +
  3. +

    Type firefox --ProfileManager.

    +
    4. +
+ +
Windows 8/8.1
+ +
    +
  1. Press "Windows + R" on your keyboard.
    2. +
  2. Type firefox --ProfileManager.
    3. +
+ +

If the Profile Manager window does not open, Firefox may have been running in the background, even though it was not visible. Close all instances of Firefox, or restart the computer, and then try again.

+ +

Linux

+ +

If Firefox is already included in your Linux distribution, or if you have installed Firefox with the package manager of your Linux distribution:

+ +
    +
  1. At the top of the Firefox window, click on the File menu and select Quit.
    2. +
  2. In Terminal run firefox --ProfileManager
    3. +
+ +

If the Profile Manager window does not open, Firefox may have been running in the background, even though it was not visible. Close all instances of Firefox, or restart the computer and then try again.

+ +

macOS

+ +
    +
  1. Run the Terminal application, which is found in Applications/Utilities.
    2. +
  2. Type or paste in the path to Firefox, followed by .app/Contents/MacOS/firefox.  For example, if Firefox is installed in the recommended location, you would enter /Applications/Firefox.app/Contents/MacOS/firefox.
    3. +
  3. If you have the path to your desired profile handy, enter a space character, followed by -profile followed by another space character, followed by the full path to the profile folder you wish to launch into.  This will launch Firefox immediately.  Otherwise, enter a space character followed by --profilemanager.  This will present the Profile Manager window in which you can make your selection.
    4. +
  4. Hit return.
    5. +
+ +

Here is a complete example Terminal command from steps 2-3:

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

If you want to do this frequently and more easily, you may wish to create an Automator application, as explained in this tutorial.

+ +

Criar um perfil

+ +

Creating a profile through the Profile Manager

+ +

These instructions should be the same for all operating systems.

+ +
    +
  1. To start the Create Profile Wizard, click "Create Profile..." in the Profile Manager.
    2. +
  2. Click Next and enter the name of the profile. Use a profile name that is descriptive, such as your personal name. This name is not exposed to the Internet.
    3. +
  3. You can also choose where to store the profile on your computer. To select storage location, click Choose Folder....
    4. +
  4. If you choose your folder location for the profile, select a new or empty folder. If you choose a folder that isn't empty, and you later remove the profile and choose the \"Delete Files\" option, everything inside that folder will be deleted.
    5. +
  5. To create the new profile, click Finish.
    6. +
+ +

Creating a profile through the Firefox browser

+ +

You can create a new Firefox profile directly from the browser.

+ +
    +
  1. Type about:profiles into the browser URL search bar
    2. +
  2. On the page, click Create a New Profile button
    3. +
  3. Read the introduction, and click Next
    4. +
  4. Enter a profile name for your new Profile. Use a profile name that is descriptive, such as your personal name. This name is not exposed to the Internet.
    5. +
  5. Optionally, to change where the profile will be stored on your computer, click Choose Folder...
    6. +
  6. To create the new profile, click Finish.
    7. +
+ +

Eliminar um perfil

+ +
    +
  1. In the Profile Manager, select the profile to remove, and click Delete Profile....
    2. +
  2. Confirm that you wish to delete the profile: +
      +
    • Don't Delete Files removes the profile from the Profile Manager yet retains the profile data files on your computer in the storage folder so that your information is not lost. "Don't Delete Files" is the preferred option, because it saves the old profile's folder, allowing you to recover the files to a new profile.
      • +
    • Delete Files removes the profile and its files, including the profile bookmarks, settings, passwords, etc.
      +
      + {{ warning("If you use the \"Delete Files\" option, the profile folder, and files will be deleted. This action cannot be undone.") }}
      • +
    • Cancel interrupts the profile deletion.
      • +
    +
    3. +
+ +

Renomear um perfil

+ +
    +
  1. In the Profile Manager, select the profile you want to rename, and then click "Rename Profile".
    2. +
  2. Enter a new name for the profile and click on OK.
    3. +
+ +
+

Nota: The folder containing the files for the profile is not renamed.

+
+ +

Opções

+ +

Trabalhar off-line

+ +

Choosing this option loads the selected profile, and starts Firefox offline. You can view previously viewed web pages, and experiment with your profile.

+ +

Não perguntar no arranque

+ +

If you have multiple profiles, Firefox prompts you for the profile to use each time you start Firefox. Select this option to allow Firefox to load the selected profile, without prompting at startup.

+ +
+

Nota: To access other profiles after selecting this option, you must start the Profile Manager first.

+
+ +

Utilizar os perfis

+ +

Windows

+ +

If you want to have the profile manager to pop up each time you start Firefox, so you can choose a profile, you will need to edit the "Target" of the launch icon. To do this:

+ +
    +
  1. Right-click the icon and choose "Properties".
    2. +
  2. When the properties dialog box pops up, you should see a "Target" text field that you can edit, and it should show the current file path.
    3. +
  3. After the closing quote, add -ProfileManager.
    4. +
  4. Click Ok.
    5. +
+ +

Now whenever you double click that icon, the profile manager should appear, allowing you to choose which profile you'd like to use.

+ +

If you want individual icons to launch specific profiles, you will need to edit the "Target" of each icon. To do this:

+ +
    +
  1. Right-click the icon and choose "Properties".
    2. +
  2. When the properties dialog box pops up, you should see a "Target" text field that you can edit, and it should show the current file path.
    3. +
  3. To permanently set a specific profile, add -p PROFILE_NAME to the target path, but outside of the quotes, replacing "PROFILE_NAME" with the actual profile name you chose.
    4. +
  4. If you would also like to allow multiple instances of Firefox to run at the same time, add -no-remote after the profile name.
    5. +
+ +

Once you are all done, click Ok. Do this for each icon you'd like to have a specific profile for. Once done, each one should automatically start with the specified profile.

+ +

Linux

+ +

There is no extremely straightforward way to create custom application launchers in Gnome 3 like there was in Gnome 2. The following tutorial will help get you going overall: Gnome 3 Custom application launcher. Once you get to the point of adding a new item, you can have the profile dialog show up every time or set the launcher to launch a specific profile.

+ +

If you want to have the profile manager to pop up each time you start Firefox, so you can choose a profile, you will need to set the command line for your new launcher.

+ +
    +
  1. Set the "command" text field to target the executable file, likely "/usr/bin/firefox", and add the -p parameter.
    2. +
+ +

If you want individual icons to launch specific profiles, you will need to set the command line for your new launcher. To do this:

+ +
    +
  1. Set the "command" text field to target the executable file, likely "/usr/bin/firefox", and add the -p PROFILE_NAME parameter, replacing "PROFILE_NAME" with the specific profile.
    2. +
  2. Repeat as necessary, for each additional profile you want to set.
    3. +
  3. If you would also like to allow multiple instances of Firefox to run at the same time, add "-no-remote" after the profile name.
    4. +
+ +

Mac OS X

+ +

You can find a useful tutorial to set up custom launchers here: Managing Multiple Firefox Profiles in OSX. Do note it's best to follow all steps in the "Creating the scripts" section, including the "edit Info.plist" step. Leave off the profile name if you want the profile selector to show up every time you launch.

+ +

Configurar vários perfis para diferentes canais do Firefox

+ +

This section will be especially helpful if you are a developer, wanting to work with multiple channels, and each having their separate launcher.

+ +

Windows

+ +

In Windows, the Developer and Nightly builds get their own directory in the "Programs" folder, so you don't have to worry about where to store the downloaded files. However, all three will attempt to use the same profile by default. You won't want to keep this behavior, because the different channels have different levels of features. To set each launcher, follow the Windows instructions at Windows Launcher.

+ +

Linux

+ +

In Linux, things aren't as automatically set up. You will likely get a prompt to download a tar.bz2 file to extract from. Extract the files to a new directory, and use the new launcher instructions from here. The only change you will need to make is the command path. You will want to set it to the directory where you extracted the Firefox channel's tar.bz2 file, and the executable "firefox" file located within this directory. The remaining profile assignment methods will remain the same. You will want to, for sure, add the -no-remote part to the end of the command field, so that you could run multiple instances at the same time.

+ +

Mac OS X

+ +

You can find a useful tutorial to set up custom launchers here: Managing Multiple Firefox Profiles in OSX. Do note it's best to follow all steps in the "Creating the scripts" section, including the "edit Info.plist" step. Also, you'll want to change the path in the do shell script to point to the correct .app file for the Firefox channel you want to target.

diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/cross_process_object_wrappers/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/cross_process_object_wrappers/index.html new file mode 100644 index 0000000000..d6efcd07ea --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiprocess_firefox/cross_process_object_wrappers/index.html @@ -0,0 +1,157 @@ +--- +title: Cross Process Object Wrappers +slug: Mozilla/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers +--- +
{{FirefoxSidebar}}
+

Este documento descreve Cross Process Object Wrappers (CPOWs), que permite ao código de chrome aceder sincronamente ao conteúdo no 'Multiprocessos do Firefox'.

+
+ +
+

Note that from Firefox 47 onwards, unsafe CPOW usage is no longer permitted in browser code. If browser code tries an unsafe CPOW operation, the browser will throw an exception and you'll see an "unsafe CPOW usage forbidden” error in the Browser Console.

+ +

Add-on code is still allowed to use CPOWs "unsafely". However, if an add-on passes a CPOW into a platform API, and that platform API then attempts an unsafe operation on it, this will throw an exception. So as a general rule, add-ons should avoid passing CPOWs into non-addon code.

+
+ +

In multiprocess Firefox, chrome code runs in a different process from web content. So chrome code can't directly interact with web content: instead, it must factor out the code that interacts with web content into separate scripts that are called frame scripts.

+ +

Chrome code can load frame scripts into the content process using the message manager, and can then communicate with them using a message-passing API. To learn more about this, see the documentation on using the message manager.

+ +

Chrome to content messaging must be asynchronous. This is because the chrome process runs the Firefox UI, so if it were blocked by the content process, then a slow content process could cause Firefox to become unresponsive to users.
+
+ Converting synchronous code to be asynchronous can be difficult and time-consuming. As a migration aid, the messaging framework enables frame scripts to make content objects available to chrome through a wrapper called a Cross Process Object Wrapper, also known as a CPOW. However, although CPOWs are convenient, they have serious limitations and can cause responsiveness problems, so should only be used when necessary and only as a migration aid.

+ +

Passagem de CPOWs de frame scripts

+ +

Frame scripts can send messages to chrome using one of two global functions: sendAsyncMessage() or sendSyncMessage(). The optional third parameter to each of these functions is an object whose properties are objects to wrap. For example, this frame script sends a DOM node to chrome when the user clicks it, as the clicked property of the third argument:

+ +
// frame script
+addEventListener("click", function (event) {
+  sendAsyncMessage("my-e10s-extension-message", {}, { clicked : event.target });
+}, false);
+ +

In the chrome script, the DOM node is now accessible through a Cross Process Object Wrapper, as a property of the objects property of the message. The chrome script can get and set the wrapped object's properties and call its functions:

+ +
// chrome script
+windowMM.addMessageListener("my-e10s-extension-message", handleMessage);
+
+function handleMessage(message) {
+  let wrapper = message.objects.clicked;
+  console.log(wrapper.innerHTML);
+  wrapper.innerHTML = "<h2>Modified by chrome!</h2>"
+  wrapper.setAttribute("align", "center");
+}
+ +

CPOWs gerados automaticamente

+ +

Add-ons that have not declared themselves multiprocess compatible are set up with a number of compatibility shims. One of these shims provides the following behavior: whenever chrome code tries to access content directly (for example, through window.content or browser.contentDocument), it is given back a CPOW that wraps the content object. This means that examples like this will actually work, even in multiprocess Firefox:

+ +
gBrowser.selectedBrowser.contentDocument.body.innerHTML = "replaced by chrome code";
+ +

It's still important to keep in mind, though, that this is access through a CPOW and not direct access to content.

+ +

CPOWs bidirecionais

+ +

A common pattern is for chrome code to access content objects and add event listeners to them. To deal with this, CPOWs are bidirectional. This means that if content passes a CPOW to the chrome process, the chrome process can synchronously pass objects (such as event listener functions) into functions defined in the CPOW.

+ +

This means you can write code like this:

+ +
// frame script
+
+/*
+On mouseover, send the button to the chrome script as a CPOW.
+*/
+
+var button = content.document.getElementById("click-me");
+
+button.addEventListener("mouseover", function (event) {
+  sendAsyncMessage("my-addon-message", {}, { element : event.target });
+}, false);
+ +
// chrome script
+
+/*
+Load the frame script, then listen for the message.
+When we get the message, extract the CPOW and add
+a function as a listener to the button's "click" event.
+*/
+
+  browserMM.loadFrameScript("chrome://my-addon/content/frame-script.js", false);
+  browserMM.addMessageListener("my-addon-message", function(message) {
+    let wrapper = message.objects.element;
+    wrapper.addEventListener("click", function() {
+      console.log("they clicked");
+    });
+  });
+
+ +

Mapear conteúdo de documentos para navegadores XUL

+ +

A common pattern is to get the XUL <browser> that corresponds to a content document. To enable this, gBrowser.getBrowserForDocument and gBrowser.getBrowserForContentWindow can be passed a CPOW for the content document and content window, respectively, and return the XUL  <browser> that these documents / windows belong to. Both return null if no such browser can be found.

+ +

Limitações de CPOWs

+ +

Although CPOWs can be convenient they have several major limitations, which are listed below.

+ +

CPOWs e APIs de plataforma

+ +

You can't pass CPOWs into platform APIs that expect to receive DOM objects. For example, you can't pass a CPOW into nsIFocusManager.setFocus().

+ +

Also, from Firefox 47 onwards, browser code can no longer perform unsafe CPOW operations. This means that as an add-on developer, you should not pass CPOWs into browser APIs.

+ +

Reação de Chrome

+ +

The lack of a synchronous API on the chrome side is intentional: because the chrome process runs the Firefox UI, any responsiveness problems affect the whole browser. By making the chrome process block on the content process, CPOWs break this principle and allow unresponsive content process to make the whole browser unresponsive.

+ +

Consulte em baixo CPOWs seguros e inseguros para mais sobre isto.

+ +

Desempenho

+ +

Although the wrapper looks just like an object completely contained in the chrome script scope, it's really just a reference to an object in the content process. When you access a property of the wrapper, it sends a synchronous message to the content process and returns the result. This means it is many times slower to use than an object.

+ +

Ordenação de mensagem

+ +

CPOWs can violate assumptions you might make about message ordering. Consider this code:

+ +
mm.addMessageListener("GotLoadEvent", function (msg) {
+  mm.sendAsyncMessage("ChangeDocumentURI", {newURI: "hello.com"});
+  let uri = msg.objects.document.documentURI;
+  dump("Received load event: " + uri + "\n");
+});
+
+ +

This sends a message asking the frame script to change the current document URI, then accesses the current document URI via a CPOW. You might expect the value of uri to come back as "hello.com". But it might not: in order to avoid deadlocks, CPOW messages can bypass normal messages and be processed first. It’s possible that the request for the documentURI property will be processed before the "ChangeDocumentURI" message, in which case uri will have its previous value.
+
+ For this reason, it’s best not to mix CPOWs with normal message manager messages. It’s also a bad idea to use CPOWs for anything security-related, since you may get results that are not consistent with surrounding code that might use the message manager.

+ +

CPOWs seguros e inseguros

+ +

The main reason CPOWs can be bad for responsiveness is that they make the chrome process block on the content process.

+ +

Essentially, the problem is this: suppose the content process is busy with some long-running operation (for example, garbage collection). In multiprocess Firefox, the browser UI is still responsive, because it's running in a different process. But if the chrome process then tries to use a CPOW, the chrome process will block until the content process is ready to respond. Suddenly, what looked like a simple property access could block the UI for a noticeable amount of time:

+ +

+ +

There is one scenario, though, in which this is not a problem: when the content process is already blocking on a synchronous message it sent to the chrome process.

+ +

The content process is blocked anyway waiting for the chrome process, so there's no chance, in this situation, that the CPOW call will block on some long-running activity in the content process. The content process can respond immediately to the CPOW call:

+ +


+

+ +

There is still a performance cost to the CPOW in this situation, because the CPOW call is an IPC call instead of a simple property access in the same process. However, the potential impact on responsiveness is much smaller.

+ +

Also, in this situation, the content process is in a known state. We know it's blocked waiting for the synchronous message to return, and we know that won't change during the CPOW call. This makes the CPOW call much safer than it would otherwise be.

+ +

This situation is thus called "safe CPOW usage". All other uses of CPOWs are called "unsafe CPOW usage".

+ +

Consulyat também:

+ + + +

 

+ +

 

diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/depuracao_de_frame_scripts/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/depuracao_de_frame_scripts/index.html new file mode 100644 index 0000000000..6f22e9a0b7 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiprocess_firefox/depuracao_de_frame_scripts/index.html @@ -0,0 +1,56 @@ +--- +title: Depuração de frame scripts +slug: Mozilla/Firefox/Multiprocess_Firefox/Depuracao_de_frame_scripts +tags: + - Caixa de ferramentas de Conteúdo de Navegador + - Multiprocessos do Firefox +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Debugging_frame_scripts +--- +
{{FirefoxSidebar}}
+

A Caixa de Ferramentas de Conteúdo de Navegador só está disponível no Firefox Nightly, e apenas se extiver a executar o Firefox no modo de multiprocessos.

+
+ +

You can use the Browser Content Toolbox to debug frame scripts. The Browser Content Toolbox is a separate window that includes some of the standard Firefox Developer Tools - specifically: the console, the JavaScript debugger, and Scratchpad - but attaches them to the browser's content process. This means you can debug the frame scripts in your add-on.

+ +

Abrir a Caixa de Ferrmanetas de Conteúdo de Navegador

+ +

{{EmbedYouTube("Cg6X_zIu7Xk")}}

+ +

To open the Browser Content Toolbox, you'll need to:

+ + + +

You should now see an item labeled "Browser Content Toolbox" in the Developer submenu in the Firefox Menu (or Tools menu if you display the menu bar or are on OS X). It opens in a separate window:

+ +

If you've used the Firefox Developer Tools before, this should look pretty familiar.

+ +

Along the top is a row of tabs that you can use to switch the active tool. Currently, we only support the Console, the Debugger, and Scratchpad in the Browser Content Toolbox. At the right of this row are three buttons that activate the split console, open settings, and close the toolbox.

+ +

The rest of the toolbox is taken up with the tool you've currently selected.

+ +

Utilização

+ +

{{EmbedYouTube("XF0ULNnNOxg")}}

+ +

O Depurador

+ +

The Debugger lists all the scripts that are loaded into the content process. You'll find your frame scripts listed under the chrome:// URL you registered for them:

+ +

You can set breakpoints, of course, and do all the other things supported by the debugger.

+ +

A Consola

+ +

The Console logs output from your frame scripts. If you want to use it to evaluate JavaScript in your frame script's scope, there's a trick you need to know:

+ + + +

Now the console's scope is your frame script's scope, and you can interact directly with it:

+ +

diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/gestor_de_mensagens/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/gestor_de_mensagens/index.html new file mode 100644 index 0000000000..88d8419e69 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiprocess_firefox/gestor_de_mensagens/index.html @@ -0,0 +1,74 @@ +--- +title: Gestor de mensagens +slug: Mozilla/Firefox/Multiprocess_Firefox/Gestor_de_mensagens +tags: + - API + - Guia(2) + - JavaScript +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Message_Manager +--- +
{{FirefoxSidebar}}

Os gestores de mensagens fornecem uma maneira para o código de JavaScript chrome-privilegiado para comunicar através dos limites de processo. Eles são particularmente úteis para permitir que código do chrome, incluindo o código do navegador e o código de extensão, para aceder ao conteúdo da Web enquanto o navegador está a executar conteúdo da Web num processo separado

+ +

Message managers provide a way for chrome-privileged JavaScript code to communicate across process boundaries. They are particularly useful for allowing chrome code, including the browser's code and extension's code, to access web content while the browser is running web content in a separate process.

+ +

These guides explain how to use message managers in multiprocess Firefox.

+ +

Note that none of this requires multiprocess Firefox: everything described here will work with single-process Firefox, so the same code will work on both variants.

+ +
+

Guias

+ +
+
+
+
Message manager overview
+
 
+
Frame script loading and lifetime
+
 
+
Communicating with frame scripts
+
 
+
Performance Best Practices
+
 
+
+
+ +
+
+
Frame script environment
+
 
+
Limitations of frame scripts
+
 
+
Process scripts
+
 
+
+
+
+ +
+

Referência de API

+ +
+
+
+
nsIFrameScriptLoader
+
 
+
nsIMessageListenerManager
+
 
+
nsIMessageBroadcaster
+
 
+
nsIMessageSender
+
 
+
+
+ +
+
+
nsISyncMessageSender
+
 
+
nsIContentFrameMessageManager
+
 
+
nsIProcessScriptLoader
+
 
+
+
+
diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/glossario/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/glossario/index.html new file mode 100644 index 0000000000..22bb1b5b57 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiprocess_firefox/glossario/index.html @@ -0,0 +1,36 @@ +--- +title: Glossário +slug: Mozilla/Firefox/Multiprocess_Firefox/Glossario +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Glossary +--- +
{{FirefoxSidebar}}
+
+
+
Child-to-parent CPOWs
+
CPOWs that refer to objects in the parent (chrome) process.
+
Chrome process (also called the parent process)
+
The operating system process that runs the Firefox UI, including the toolbar, dialog boxes, and features like session restoration. All add-on code that doesn't run in frame scripts runs here.
+
Content process (also called the child process)
+
The operating system process that runs web content, in multiprocess Firefox. Code for frame scripts runs in this process.
+
Content scripts
+
Deprecated term for frame scripts.
+
CPOWs
+
CPOW stands for Cross Process Object Wrapper. A CPOW gives chrome code synchronous access to content objects, as a migration aid. See more about CPOWs.
+
+
+ +
+
+
Frame scripts
+
When chrome code needs to interact with web content, it factors the code that needs to access content into separate scripts, and loads them into the content process. These separate scripts are called frame scripts. We used to call these scripts "content scripts" but have deprecated that term.
+
Message manager
+
Message managers enable chrome code to load frame scripts into content processes, and communicate with them using a message-passing API. See more about message managers.
+
Parent-to-child CPOWs
+
CPOWs that refer to objects that live in the child (content) process.
+
Shim
+
...
+
+
+
+ +

 

diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/index.html new file mode 100644 index 0000000000..8bf746e32a --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiprocess_firefox/index.html @@ -0,0 +1,79 @@ +--- +title: Multiprocessos do Firefox +slug: Mozilla/Firefox/Multiprocess_Firefox +tags: + - Firefox +translation_of: Mozilla/Firefox/Multiprocess_Firefox +--- +
{{FirefoxSidebar}}
+ +

Nas versões antigas do Firefox para PC, todo o navegador era executado num único processo do sistema operativo. Em particular, o JavaScript que executa a IU do navegador (também conhecido como "código do chrome") executa o mesmo processo como o código nas páginas da Web (também conhecido como "conteúdo" ou "conteúdo da Web").
+
+ As últimas versões do Firefox executam a IU do navegador num processo separado do conteúdo da Web. Na primeira iteração dessa arquitetura, todos os separadores do navegador funcionam no mesmo processo e a IU do navegador é executada num processo diferente. Em iterações futuras, nós esperamos ter mais doque um processo de conteúdo. O projeto que está a distribuir 'Multiprocessos do Firefox' é chamado de Electrolysis, por vezes abreviado para e10s.

+ +

As páginas da Web normais não são afetadas pelo 'Multiprocessos do Firefox'. As pessoas que trabalham no próprio Firefox e os programadores de extras do Firefox não serão afetados se o seu código depende de ser capaz de aceder diretamente ao conteúdo da Web.

+ +

Em vez de aceder ao conteúdo da web diretamente, o código do chrome terá que utilizar o gestor de mensagens. Para ajudar a facilitar esta transição, nós implementamos Cross Process Object Wrappers e alguns shims de compatibilidade para os programadores de extras. Se é um programador de extras perguntando-se a si mesmo se está ou não afetado por esta alteração, consulte o guia para trabalhar com multiprocessos do Firefox.

+ +
+
+
+
+
Resumo técnico
+
A very high-level view of how multiprocess Firefox is implemented.
+
Guia de compatibilidade do conteúdo da Web
+
Guidelines and details on potential Web site compatibility issues that may arise due to the transition. Tip: there aren't very many!
+
Glossário
+
Uma referência para o gíria utilizada em 'Multiprocessos do Firefox'.
+
Gestor de mensagens
+
Complete guide to the objects used to communicate between chrome and content.
+
Extras baseados em SDK
+
How to migrate add-ons developed using the Add-on SDK.
+
Quais os URIs que carregam e onde
+
A quick guide to which URIs - chrome:, about:, file:, resource: - are loaded into which process.
+
+
+ +
+
+
Motivação
+
Why we are implementing multiprocess Firefox: performance, security, and stability.
+
Guia de migração de extras
+
If you are an add-on developer, find out if you are 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.
+
Depuração de processos do conteúdo
+
How to debug code running in the content process, including frame and process scripts.
+
Seleção de separador nos multiprocessos do Firefox
+
How switching tabs works in multiprocess Firefox.
+
+
+
+ +
+
+
+
+
Limitações de chrome scripts
+
Práticas que já não irão funcionar no código de chrome, e como as fixar.
+
+
+ +
+
+
Limitações de frame scripts
+
Práticas que já não irão funcionar dentro de frame scripts, e o que fazer.
+
+
+
+ +
+

Contacte-nos

+ +

Saiba mais sobre o projeto, participe, ou coloque as suas perguntas.

+ + diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_chrome_scripts/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_chrome_scripts/index.html new file mode 100644 index 0000000000..f761b2c6f7 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_chrome_scripts/index.html @@ -0,0 +1,215 @@ +--- +title: Limitações de "chrome scripts" +slug: Mozilla/Firefox/Multiprocess_Firefox/Limitacoes_de_chrome_scripts +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts +--- +
{{FirefoxSidebar}}

This page describes patterns that used to work in the chrome process that will no longer work in multiprocess Firefox. These are the sorts of things that will break an old add-on in multiprocess Firefox. The fix is generally some variant of "do that in a frame script loaded into the content process".

+ +

This is one of a pair of articles: the other one lists limitations of frame scripts.

+ +

Compatibilidade de shims

+ +

For many of the patterns described here we've implemented compatibility shims so the patterns still work. For example: whenever extensions try to access web content from the chrome process, the browser will return a Cross Process Object Wrapper that gives the chrome code synchronous access to the content.

+ +

You'll get the shims for your add-on by default, unless you set the multiprocessCompatible flag in your add-on's install manifest.

+ +

However, these shims are not a substitute for migrating extensions:

+ + + +

You can see all the places where your add-on uses compatibility shims by setting the dom.ipc.shims.enabledWarnings preference and watching the browser console as you use the add-on.

+ +

The rest of this page documents patterns that don't work in multiprocess Firefox as well as how are shims try to paper over the problem. For each pattern we've noted:

+ + + +

gBrowser.contentWindow, window.content...

+ +

Sem shim

+ +

All APIs in the chrome process that provide direct access to content objects will no longer work. For example:

+ +
// chrome code
+
+gBrowser.contentWindow;                    // null
+
+gBrowser.contentDocument;                  // null
+
+gBrowser.selectedBrowser.contentWindow;    // null
+
+window.content;                            // null
+
+content;                                   // null
+
+ +

As a special note, docshells live in the content process, so they are also inaccessible:

+ +
gBrowser.docShell;                         // null
+
+gBrowser.selectedBrowser.docShell;         // null
+ +

Com shim

+ +

The shim will give you a CPOW for the content object in these situations.

+ +

In some situations, the content process may not be initialized when an add-on asks for access to its content. In this case, the shim will return a JavaScript object that looks somewhat like a window or a document for about:blank. However, this "dummy" object is completely static and only exposes a few of the normal properties that windows and documents have. For this reason, add-ons that try to access content objects in fresh <browser> elements may run into trouble.

+ +

To make the shim unnecessary: factor the code that needs to access content into a separate script, load that script into the content process as a frame script, and communicate between the chrome script and the frame script using the message-passing APIs. See the article on using the message manager.

+ +

Limitações de CPOWs

+ +

Cross process object wrappers (CPOWs) are a migration aid giving chrome code synchronous access to content objects. However, there are various limitations on the kinds of things you can do with a CPOW.

+ +
+

Note that from Firefox 47 onwards, unsafe CPOW usage is no longer permitted in browser code. If browser code tries an unsafe CPOW operation, the browser will throw an exception and you'll see an "unsafe CPOW usage forbidden” error in the Browser Console.

+ +

Add-on code is still allowed to use CPOWs "unsafely". However, if an add-on passes a CPOW into a platform API, and that platform API then attempts an unsafe operation on it, this will throw an exception. So as a general rule, add-ons should avoid passing CPOWs into non-addon code.

+
+ +

nsIContentPolicy

+ +

Sem shim

+ +

In multiprocess Firefox, if you register the nsIContentPolicy in the chrome process then it will never see any attempts to load web content, because they happen in the content process.

+ +

Com shim

+ +

The shim enables you to add content policies in the chrome process. It transparently registers an nsIContentPolicy in the content process, whose shouldLoad just forwards to the chrome process. The content to check is forwarded as a CPOW. The chrome process then checks the content against the policy supplied by the add-on, and forwards the response back to the child to be enforced.

+ +

To make the shim unnecessary: define and register nsIContentPolicy in the content process. If you need to ensure that the policy is only registered once, use a process script to register the policy.

+ +

nsIWebProgressListener

+ +

This API will work in the chrome process. There is a shim that gives you access to the DOMWindow property of the nsIWebProgress object passed into onStateChange. However, the DOMWindow is passed asynchronously, so by the time the chrome process receives it, the DOM might have changed (for example, because code running in the content process modified it or we navigated to a different page). We're working on fixing this issue in bug 1118880.

+ +

Also note that unlike other shims, this shim is always active.

+ +

Alternatively, you can use nsIWebProgressListener in the content process.

+ +

Observadores no processo de chrome

+ +

Depending on the topic, you need to register observers in either the chrome process or in a frame script.

+ +

For most topics you need to register observers in the chrome process.

+ +

However, you must listen to content-document-global-created and document-element-inserted in a frame script. Observers for these topics get content objects as the aSubject argument to observe(), so notifications are not sent to the chrome process.

+ +

There is a shim that will forward these two topics to the chrome process, sending CPOWs as the aSubject argument.

+ +

Pedidos de HTTP

+ +

You can't observe HTTP requests in the content process. If you do, you'll get an error.
+
+ If you do so in the chrome process, it will mostly work. The subject for the observer notification will be an nsIHttpChannel as you would expect.

+ +

A common pattern here is to use the notificationCallbacks property of the nsIHttpChannel to get the DOM window that initiated the load, like this:

+ +
observe: function (subject, topic, data) {
+  if (topic == "http-on-modify-request") {
+    var httpChannel = subject.QueryInterface(Ci.nsIHttpChannel);
+    var domWindow = httpChannel.notificationCallbacks.getInterface(Ci.nsIDOMWindow);
+  }
+}
+ +

Or this:

+ +
observe: function (subject, topic, data) {
+  if (topic == "http-on-modify-request") {
+    var httpChannel = subject.QueryInterface(Ci.nsIHttpChannel);
+    var domWindow = httpChannel.notificationCallbacks.getInterface(Ci.nsILoadContext).associatedWindow;
+  }
+}
+ +

In multiprocess Firefox these patterns will no longer work: the getInterface call will fail.

+ +

In multiprocess Firefox, notificationCallbacks is a special object that tries to emulate the single-process notificationsCallbacks object as best it can. It will return a dummy nsILoadContext when asked, but any attempt to get a window out of it will fail.
+
+ There is an outstanding bug (bug 1108827) to implement a shim here that will make notificationCallbacks a CPOW for the objects in the content process.

+ +

The correct way to access the DOM window is through a message manager. In an HTTP observer, you can get the browser message manager for the window using code like this:

+ +
observe: function (subject, topic, data) {
+  if (topic == "http-on-modify-request") {
+    var httpChannel = subject.QueryInterface(Ci.nsIHttpChannel);
+    var loadContext = httpChannel.notificationCallbacks.getInterface(Ci.nsILoadContext);
+    // topFrameElement is the <browser> element
+    var topFrameElement = loadContext.topFrameElement;
+    var browserMM = topFrameElement.messageManager;
+    console.log("browserMM: " + browserMM);
+  }
+}
+ +

However, before Firefox 38, this technique will not work if multiprocess Firefox is disabled: specifically, topFrameElement will be null. This means that if you need to write code that works before Firefox 38 and on both multiprocess and non-multiprocess variants, you need to implement both paths:

+ + + +

From Firefox 38 onwards, the topFrameElement approach always works.

+ +

Eventos DOM

+ +

Sem shim

+ +

In multiprocess Firefox, if you want to register an event listener on some content DOM node, that needs to happen in the content process.

+ +

It used to be that if you registered a listener on the XUL <browser>  or <tab> element that hosted some DOM content, then events in the content would bubble up to the XUL and you could handle them there. This no longer happens in multiprocess Firefox.

+ +

Com shim

+ +

The shim intercepts chrome process code that adds listeners to XUL elements and sets up listeners in the content process, relaying the result back to the chrome process. The Event object itself is relayed to the chrome process as a CPOW.

+ +

To make the shim unnecessary: register event listeners on the global object inside a frame script. For example:

+ +
addEventListener("load", handler, true) // for example
+ +
If you need to contact the chrome process when that happens, send it a message.
+ +
 
+ +

Sandboxes

+ +
You can create sandboxes in the chrome or the content process. Sandboxes are often used as a safe way to manipulate web content, and if that's your goal, create the sandbox in the content process.
+ +
 
+ +
There is a shim for sandboxes: if you make a sandbox in the chrome process and give it content principals (by passing a CPOW as the first argument to Components.utils.Sandbox) then we'll actually make it in the content process.
+ +
 
+ +
+

nsIAboutModule

+ +

By default, custom about: pages registered using nsIAboutModule are loaded in the chrome process. This means that you can't access their content from the content process (via XHR, for example).

+ +

You can change this default in the code you use to register the about: URI. See about: and chrome: URIs.

+
+ +

Módulos de código de JavaScript (JSMs)

+ +
In single-process Firefox, you can use JavaScript code modules (JSMs) to maintain global state. In multiprocess Firefox, a JSM loaded into one process does not share any state with the same JSM loaded into a different process: so you can't use a JSM to share state between the chrome and content processes.
+ +
 
+ +
If an add-on wants to use a JSM to share state in this way, it's best to load the JSM in the chrome process, and have frame scripts store and access the JSM's state by sending messages to the chrome process using the message manager.
+ +
 
+ +

nsIProtocolHandler

+ +
In multiprocess Firefox, code which registers a custom protocol using nsIProtocolHandler must register the custom protocol in the child content process.
+ +
If the custom protocol is registered only in the chrome process, no iframes or tabs will be able to load any resource from the custom procotol.
+ +
 
+ +
The solution is to register the custom protocol in the content process. You can do this by loading a frame script or, with the Add-on SDK, you can use remoteRequire() in the "remote/parent" module.
diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_frame_scripts/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_frame_scripts/index.html new file mode 100644 index 0000000000..999472c499 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_frame_scripts/index.html @@ -0,0 +1,103 @@ +--- +title: Limitações de frame scripts +slug: Mozilla/Firefox/Multiprocess_Firefox/Limitacoes_de_frame_scripts +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Limitations_of_frame_scripts +--- +
{{FirefoxSidebar}}

Frame scripts run with system privileges and have access to the Components object, enabling them to use XPCOM objects and JSMs. Many privileged APIs will just work in a content process. Anything that just manipulates data structures will just work. XHR and Workers will work. However, some APIs  that work in the chrome process will not work in a frame script. This article lists the most important of these APIs.

+ +

This is one of a pair of articles: the other one lists limitations of chrome scripts.

+ +

Restrições de Segurança no Acesso de Ficheiro

+ +

Processes that host remote content are isolated from the local system through a content security sandbox. One of the functions of the sandbox is to restrict access to the local file system by processes that host remote content. Since frame and process scripts often execute in remote content processes these scripts are subject to the same file access rules placed on remote content. Therefore frame scripts should not attempt to access the local file system directly, as these calls will fail.

+ +

Examples of APIs Add-on authors should avoid in frame scripts:

+ + + +

XUL e IU de navegador

+ +

Anything that tries to touch the browser UI or anything to do with XUL is likely to not work in the content process. For example:

+ + + +

Serviços

+ +

Some services will not work in frame scripts.

+ + + +

Janelas de Chrome

+ +

Anything that needs to use chrome windows will not work in the content process. For example:

+ + + +

Places API

+ +

A API de Places não pode ser utilizada dentro de uma frame script. Por exemplo:

+ + + +

Observadores no processo de conteúdo

+ +

As noted in Observers in the chrome process, most observers should be registered in the chrome process and will not work in the content process. The exceptions are:

+ + + +

These must be registered in the content process.

+ +

QI from content window to chrome window

+ +
There's a particular pattern often used to get from a content window to the associated chrome window. It looks something like this:
+ +
 
+ +
window.QueryInterface(Ci.nsIInterfaceRequestor)
+                         .getInterface(Ci.nsIWebNavigation)
+                         .QueryInterface(Ci.nsIDocShellTreeItem)
+                         .rootTreeItem
+                         .QueryInterface(Ci.nsIInterfaceRequestor)
+                         .getInterface(Ci.nsIDOMWindow);
+ +
This will no longer work. In the content process the root tree item is an nsITabChild, that cannot be converted to an nsIDOMWindow, so the second getInterface call here will fail.
+ +
 
+ +

If you want a chrome window: send a message from the content process using the message manager. The target property of the object passed into the message handler in the chrome process is the XUL <browser> receiving the message, and you can get the chrome window from that (Note: I'm not really sure how...).

+ +

nsIAboutModule

+ +

By default, custom about: pages registered using nsIAboutModule are loaded in the chrome process. This means that you can't access their content from the content process (via XHR, for example).

+ +

You can change this default in the code you use to register the about: URI. See about: and chrome: URIs.

+ +

Módulos de código de JavaScript (JSMs)

+ +
In multiprocess Firefox, a JSM loaded into the content process does not share any state with the same JSM loaded into the chrome process. See the entry in the Limitations on chrome scripts page.
diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/quais_os_uris_que_carregam_e_onde/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/quais_os_uris_que_carregam_e_onde/index.html new file mode 100644 index 0000000000..7a4ae7a993 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/multiprocess_firefox/quais_os_uris_que_carregam_e_onde/index.html @@ -0,0 +1,62 @@ +--- +title: Quais os URIs que carregam e onde +slug: Mozilla/Firefox/Multiprocess_Firefox/Quais_os_URIs_que_carregam_e_onde +tags: + - Processo de Chrome + - Processo de Conteúdo +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Which_URIs_load_where +--- +
{{FirefoxSidebar}}

Baseado inicialmente no esquema de URI da página, o navegador pode decidir se deseja carregar uma página no processo de chrome ou um processo de conteúdo. Para alguns esquemas, pode alterar o comportamento predefinido.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
EsquemaComportamento
about: +

By default, about: pages are always loaded in the chrome process. However, when you register a new about: page, you can change this default.

+ +

Two new flags are defined in nsIAboutModule:

+ +
    +
  • URI_CAN_LOAD_IN_CHILD: the page will be loaded in the same process as the browser that has loaded it.
    • +
  • URI_MUST_LOAD_IN_CHILD: the page will always be loaded in a child process.
    • +
+ +

To use one of these flags, return it from your implementation of getURIFlags in the code that registers the about: URI.

+ +

If you use these flags, you must register the about page in the framescript for each tab. If you do not set multiprocessCompatible to true in your install.rdf then shims will be used. But the e10s shims will be deprecated soon. Read more here - Bug 1257201.

+
chrome: +

By default, chrome: pages are always loaded in the chrome process. However, when you register a new chrome: page, you can change this default.

+ +

Two new flags are defined in the chrome.manifest file:

+ +
    +
  • remoteenabled: the page will be loaded in the same process as the browser that has loaded it.
    • +
  • remoterequired: the page will always be loaded in a child process.
    • +
+
file: +

Carregado sempre num processo de conteúdo.

+ +

Nota: This does not mean file: URIs can be used freely by code in content processes. Sandboxing may blacklist particular directories and future changes may restrict file: URIs to a separate content process, isolated from regular web content. See bug 1187099 how this can affect addons attempting to load files from the profile directory.

+
resource:Carregado sempre num processo de conteúdo.
diff --git "a/files/pt-pt/mozilla/firefox/multiprocess_firefox/resumo_t\303\251cnico/index.html" "b/files/pt-pt/mozilla/firefox/multiprocess_firefox/resumo_t\303\251cnico/index.html" new file mode 100644 index 0000000000..aa2613a58e --- /dev/null +++ "b/files/pt-pt/mozilla/firefox/multiprocess_firefox/resumo_t\303\251cnico/index.html" @@ -0,0 +1,164 @@ +--- +title: Resumo técnico +slug: Mozilla/Firefox/Multiprocess_Firefox/Resumo_técnico +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Technical_overview +--- +
{{FirefoxSidebar}}
+

This page is an edited extract from Bill McCloskey's blog post on multiprocess Firefox: http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/

+
+ +

At a very high level, multiprocess Firefox works as follows. The process that starts up when Firefox launches is called the parent process. Initially, this process works similarly to single-process Firefox: it opens a window displaying browser.xul, which contains all the principal UI elements for Firefox. Firefox has a flexible GUI toolkit called XUL that allows GUI elements to be declared and laid out declaratively, similar to web content. Just like web content, the Firefox UI has a window object, which has a document property, and this document contains all the XML elements from browser.xul. All the Firefox menus, toolbars, sidebars, and tabs are XML elements in this document. Each tab element contains a <browser> element to display web content.

+ +

The first place where multiprocess Firefox diverges from single-process Firefox is that each <browser> element has a remote="true" attribute. When such a browser element is added to the document, a new content process is started. This process is called a child process. An IPC channel is created that links the parent and child processes. Initially, the child displays about:blank, but the parent can send the child a command to navigate elsewhere.

+ +

Desenho

+ +

Somehow, displayed web content needs to get from the child process to the parent and then to the screen. Multiprocess Firefox depends on a new Firefox feature called off main thread compositing (OMTC). In brief, each Firefox window is broken into a series of layers, somewhat similar to layers in Photoshop. Each time Firefox draws, these layers are submitted to a compositor thread that clips and translates the layers and combines them together into a single image that is then drawn.

+ +

Layers are structured as a tree. The root layer of the tree is responsible for the entire Firefox window. This layer contains other layers, some of which are responsible for drawing the menus and tabs. One subtree displays all the web content. Web content itself may be broken into multiple layers, but they’re all rooted at a single “content” layer.

+ +

In multiprocess Firefox, the content layer subtree is actually a shim. Most of the time, it contains a placeholder node that simply keeps a reference to the IPC link with the child process. The content process retains the actual layer tree for web content. It builds and draws to this layer tree. When it’s done, it sends the structure of its layer tree to the parent process via IPC. Backing buffers are shared with the parent either through shared memory or GPU memory. References to this memory are sent as part of the layer tree. When the parent receives the layer tree, it removes its placeholder content node and replaces it with the actual tree from content. Then it composites and draws as normal. When it’s done, it puts the placeholder back.

+ +

The basic architecture of how OMTC works with multiple processes has existed for some time, since it is needed for Firefox OS. However, Matt Woodrow and David Anderson have done a lot of work to get everything working properly on Windows, Mac, and Linux. One of the big challenges for multiprocess Firefox will be getting OMTC enabled on all platforms. Right now, only Macs use it by default.

+ +

User input

+ +

Events in Firefox work the same way as they do on the web. Namely, there is a DOM tree for the entire window, and events are threaded through this tree in capture and bubbling phases. Imagine that the user clicks on a button on a web page. In single-process Firefox, the root DOM node of the Firefox window gets the first chance to process the event. Then, nodes lower down in the DOM tree get a chance. The event handling proceeds down through to the XUL <browser> element. At this point, nodes in the web page’s DOM tree are given a chance to handle the event, all the way down to the button. The bubble phase follows, running in the opposite order, all the way back up to the root node of the Firefox window.

+ +

With multiple processes, event handling works the same way until the <browser> element is hit. At that point, if the event hasn’t been handled yet, it gets sent to the child process by IPC, where handling starts at the root of the content DOM tree. The parent process then waits to run its bubbling phase until the content process has finished handling the event.

+ +

Inter-process communication

+ +

All IPC happens using the Chromium IPC libraries. Each child process has its own separate IPC link with the parent. Children cannot communicate directly with each other. To prevent deadlocks and to ensure responsiveness, the parent process is not allowed to sit around waiting for messages from the child. However, the child is allowed to block on messages from the parent.

+ +

Rather than directly sending packets of data over IPC as one might expect, we use code generation to make the process much nicer. The IPC protocol is defined in IPDL, which sort of stands for “inter-* protocol definition language”. A typical IPDL file is PNecko.ipdl. It defines a set messages and their parameters. Parameters are serialized and included in the message. To send a message M, C++ code just needs to call the method SendM. To receive the message, it implements the method RecvM.

+ +

IPDL is used in all the low-level C++ parts of Gecko where IPC is required. In many cases, IPC is just used to forward actions from the child to the parent. This is a common pattern in Gecko:

+ +
void AddHistoryEntry(param) {
+  if (XRE_GetProcessType() == GeckoProcessType_Content) {
+    // If we're in the child, ask the parent to do this for us.
+    SendAddHistoryEntry(param);
+    return;
+  }
+
+  // Actually add the history entry...
+}
+
+bool RecvAddHistoryEntry(param) {
+  // Got a message from the child. Do the work for it.
+  AddHistoryEntry(param);
+  return true;
+}
+
+ +

When AddHistoryEntry is called in the child, we detect that we’re inside the child process and send an IPC message to the parent. When the parent receives that message, it calls AddHistoryEntry on its side.

+ +

For a more realistic illustration, consider the Places database, which stores visited URLs for populating the awesome bar. Whenever the user visits a URL in the content process, we call this code. Notice the content process check followed by the SendVisitURI call and an immediate return. The message is received here; this code just calls VisitURI in the parent.

+ +

The code for IndexedDB, the places database, and HTTP connections all runs in the parent process, and they all use roughly the same proxying mechanism in the child.

+ +

Frame scripts

+ +

IPDL takes care of passing messages in C++, but much of Firefox is actually written in JavaScript. Instead of using IPDL directly, JavaScript code relies on the message manager to communicate between processes. To use the message manager in JS, you need to get hold of a message manager object. There is a global message manager, message managers for each Firefox window, and message managers for each <browser> element. A message manager can be used to load JS code into the child process and to exchange messages with it.

+ +

As a simple example, imagine that we want to be informed every time a load event triggers in web content. We’re not interested in any particular browser or window, so we use the global message manager. The basic process is as follows:

+ +
// Get the global message manager.
+let mm = Cc["@mozilla.org/globalmessagemanager;1"].
+         getService(Ci.nsIMessageListenerManager);
+
+// Wait for load event.
+mm.addMessageListener("GotLoadEvent", function (msg) {
+  dump("Received load event: " + msg.data.url + "\n");
+});
+
+// Load code into the child process to listen for the event.
+mm.loadFrameScript("chrome://content/content-script.js", true);
+
+ +

For this to work, we also need to have a file content-script.js:

+ +
// Listen for the load event.
+addEventListener("load", function (e) {
+  // Inform the parent process.
+  let docURL = content.document.documentURI;
+  sendAsyncMessage("GotLoadEvent", {url: docURL});
+}, false);
+
+ +

This file is called a frame script. When the loadFrameScript function call runs, the code for the script is run once for each <browser> element. This includes both remote browsers and regular ones. If we had used a per-window message manager, the code would only be run for the browser elements in that window. Any time a new browser element is added, the script is run automatically (this is the purpose of the true parameter to loadFrameScript). Since the script is run once per browser, it can access the browser’s window object and docshell via the content and docShell globals.

+ +

The great thing about frame scripts is that they work in both single-process and multiprocess Firefox. To learn more about the message manager, see the message manager guide.

+ +

Cross-process APIs

+ +

There are a lot of APIs in Firefox that cross between the parent and child processes. An example is the webNavigation property of XUL <browser> elements. The webNavigation property is an object that provides methods like loadURI, goBack, and goForward. These methods are called in the parent process, but the actions need to happen in the child. First I’ll cover how these methods work in single-process Firefox, and then I’ll describe how we adapted them for multiple processes.

+ +

The webNavigation property is defined using the XML Binding Language (XBL). XBL is a declarative language for customizing how XML elements work. Its syntax is a combination of XML and JavaScript. Firefox uses XBL extensively to customize XUL elements like <browser> and <tabbrowser>. The <browser> customizations reside in browser.xml. Here is how browser.webNavigation is defined:

+ +
<field name="_webNavigation">null</field>
+
+<property name="webNavigation" readonly="true">
+   <getter>
+   <![CDATA[
+     if (!this._webNavigation)
+       this._webNavigation = this.docShell.QueryInterface(Components.interfaces.nsIWebNavigation);
+     return this._webNavigation;
+   ]]>
+   </getter>
+</property>
+
+ +

This code is invoked whenever JavaScript code in Firefox accesses browser.webNavigation, where browser is some <browser> element. It checks if the result has already been cached in the browser._webNavigation field. If it hasn’t been cached, then it fetches the navigation object based off the browser’s docshell. The docshell is a Firefox-specific object that encapsulates a lot of functionality for loading new pages, navigating back and forth, and saving page history. In multiprocess Firefox, the docshell lives in the child process. Since the webNavigation accessor runs in the parent process, this.docShell above will just return null. As a consequence, this code will fail completely.

+ +

One way to fix this problem would be to create a fake docshell in C++ that could be returned. It would operate by sending IPDL messages to the real docshell in the child to get work done. We may eventually take this route in the future. We decided to do the message passing in JavaScript instead, since it’s easier and faster to prototype things there. Rather than change every docshell-using accessor to test if we’re using multiprocess browsing, we decided to create a new XBL binding that applies only to remote <browser> elements. It is called remote-browser.xml, and it extends the existing browser.xml binding.

+ +

The remote-browser.xml binding returns a JavaScript shim object whenever anyone uses browser.webNavigation or other similar objects. The shim object is implemented in its own JavaScript module. It uses the message manager to send messages like "WebNavigation:LoadURI" to a content script loaded by remote-browser.xml. The content script performs the actual action.

+ +

The shims we provide emulate their real counterparts imperfectly. They offer enough functionality to make Firefox work, but add-ons that use them may find them insufficient. I’ll discuss strategies for making add-ons work in more detail later.

+ +

Cross-process object wrappers

+ +

The message manager API does not allow the parent process to call sendSyncMessage; that is, the parent is not allowed to wait for a response from the child. It’s detrimental for the parent to wait on the child, since we don’t want the browser UI to be unresponsive because of slow content. However, converting Firefox code to be asynchronous (i.e., to use sendAsyncMessage instead) can sometimes be onerous. As an expedient, we’ve introduced a new primitive that allows code in the parent process to access objects in the child process synchronously.

+ +

These objects are called cross-process object wrappers, frequently abbreviated to CPOWs. They’re created using the message manager. Consider this example content script:

+ +
addEventListener("load", function (e) {
+  let doc = content.document;
+  sendAsyncMessage("GotLoadEvent", {}, {document: doc});
+}, false);
+
+ +

In this code, we want to be able to send a reference to the document to the parent process. We can’t use the second parameter to sendAsyncMessage to do this: that argument is converted to JSON before it is sent up. The optional third parameter allows us to send object references. Each property of this argument becomes accessible in the parent process as a CPOW. Here’s what the parent code might look like:

+ +
let mm = Cc["@mozilla.org/globalmessagemanager;1"].
+         getService(Ci.nsIMessageListenerManager);
+
+mm.addMessageListener("GotLoadEvent", function (msg) {
+  let uri = msg.objects.document.documentURI;
+  dump("Received load event: " + uri + "\n");
+});
+mm.loadFrameScript("chrome://content/content-script.js", true);
+
+ +

It’s important to realize that we’re send object references. The msg.objects.document object is only a wrapper. The access to its documentURI property sends a synchronous message down to the child asking for the value. The dump statement only happens after a reply has come back from the child.

+ +

Because every property access sends a message, CPOWs can be slow to use. There is no caching, so 1,000 accesses to the same property will send 1,000 messages.

+ +

Another problem with CPOWs is that they violate some assumptions people might have about message ordering. Consider this code:

+ +
mm.addMessageListener("GotLoadEvent", function (msg) {
+  mm.sendAsyncMessage("ChangeDocumentURI", {newURI: "hello.com"});
+  let uri = msg.objects.document.documentURI;
+  dump("Received load event: " + uri + "\n");
+});
+
+ +

This code sends a message asking the child to change the current document URI. Then it accesses the current document URI via a CPOW. You might expect the value of uri to come back as "hello.com". But it might not. In order to avoid deadlocks, CPOW messages can bypass normal messages and be processed first. It’s possible that the request for the documentURI property will be processed before the "ChangeDocumentURI" message, in which case uri will have some other value.

+ +

For this reason, it’s best not to mix CPOWs with normal message manager messages. It’s also a bad idea to use CPOWs for anything security-related, since you may not get results that are consistent with surrounding code that might use the message manager.

+ +

Despite these problems, we’ve found CPOWs to be useful for converting certain parts of Firefox to be multiprocess-compatible. It’s best to use them in cases where users are less likely to notice poor responsiveness. As an example, we use CPOWs to implement the context menu that pops up when users right-click on content elements. Whether this code is asynchronous or synchronous, the menu cannot be displayed until content has responded with data about the element that has been clicked. The user is unlikely to notice if, for example, tab animations don’t run while waiting for the menu to pop up. Their only concern is for the menu to come up as quickly as possible, which is entirely gated on the response time of the content process. For this reason, we chose to use CPOWs, since they’re easier than converting the code to be asynchronous.

+ +

It’s possible that CPOWs will be phased out in the future. Asynchronous messaging using the message manager gives a user experience that is at least as good as, and often strictly better than, CPOWs. We strongly recommend that people use the message manager over CPOWs when possible. Nevertheless, CPOWs are sometimes useful.

diff --git a/files/pt-pt/mozilla/firefox/releases/3/index.html b/files/pt-pt/mozilla/firefox/releases/3/index.html new file mode 100644 index 0000000000..129fa2fc1e --- /dev/null +++ b/files/pt-pt/mozilla/firefox/releases/3/index.html @@ -0,0 +1,298 @@ +--- +title: Firefox 3 for developers +slug: Mozilla/Firefox/Releases/3 +tags: + - Firefox 3 + - NeedsTranslation + - TopicStub +translation_of: Mozilla/Firefox/Releases/3 +--- +
{{FirefoxSidebar}}

If you're a developer trying to get a handle on all the new features in Firefox 3, this is the perfect place to start. This article provides a list of the new articles covering features added to Firefox 3. While it doesn't necessarily cover every little change, it will help you learn about the major improvements.

+

New developer features in Firefox 3

+

For web site and application developers

+
+
+ Updating web applications for Firefox 3
+
+ Provides information about changes you may need to make to your web site or web application to take advantage of new features in Firefox 3.
+
+
+
+ Online and offline events
+
+ Firefox 3 supports WHATWG online and offline events, which let applications and extensions detect whether or not there's an active Internet connection, as well as to detect when the connection goes up and down.
+
+
+
+ Web-based protocol handlers
+
+ You can now register web applications as protocol handlers using the navigator.registerProtocolHandler() method.
+
+
+
+ Drawing text using a canvas
+
+ You can now draw text in a canvas using a non-standardized API supported by Firefox 3.
+
+
+
+ Transform support for canvas
+
+ Firefox now supports the transform() and setTransform() methods on canvases.
+
+
+
+ Using microformats
+
+ Firefox now has APIs for working with microformats.
+
+
+
+ Drag and drop events
+
+ Firefox 3 supports new events that are sent to the source node for a drag operation when the drag begins and ends.
+
+
+
+ Focus management in HTML
+
+ The new HTML 5 activeElement and hasFocus attributes are supported.
+
+
+
+ Offline resources in Firefox
+
+ Firefox now lets web applications request that resources be cached to allow the application to be used while offline.
+
+
+
+ CSS improvements in Firefox 3
+
+ Firefox 3 features a number of improvements in its CSS support.
+
+
+
+ DOM improvements in Firefox 3
+
+ Firefox 3 offers a number of new features in Firefox 3's DOM implementation, including support for several Internet Explorer extensions to the DOM.
+
+
+
+ JavaScript 1.8 support
+
+ Firefox 3 offers JavaScript 1.8.
+
+
+
+ EXSLT support
+
+ Firefox 3 provides support for a substantial subset of the EXSLT extensions to XSLT.
+
+
+
+ SVG improvements in Firefox 3
+
+ SVG support in Firefox 3 has been upgraded significantly, with support for over two dozen new filters, several new elements and attributes, and other improvements.
+
+
+
+ Animated PNG graphics
+
+ Firefox 3 supports the animated PNG (APNG) image format.
+
+

For XUL and extension developers

+

Notable changes and improvements

+
+
+ Updating extensions for Firefox 3
+
+ Provides a guide to the things you'll need to do to update your extension to work with Firefox 3.
+
+
+
+ XUL improvements in Firefox 3
+
+ Firefox 3 offers a number of new XUL elements, including new sliding scales, the date and time pickers, and spin buttons.
+
+
+
+ Templates in Firefox 3
+
+ Templates have been significantly improved in Firefox 3. The key improvement allows the use of custom query processors to allow data sources other than RDF to be used.
+
+
+
+ Securing updates
+
+ In order to provide a more secure add-on upgrade path for users, add-ons are now required to provide a secure method for obtaining updates before they can be installed. Add-ons hosted at AMO automatically provide this. Any add-ons installed that do not provide a secure update method when the user upgrades to Firefox 3 will be automatically disabled. Firefox will however continue to check for updates to the extension over the insecure path and attempt to install any update offered (installation will fail if the update also fails to provide a secure update method).
+
+
+
+ Places migration guide
+
+ An article about how to update an existing extension to use the Places API.
+
+
+
+ Download Manager improvements in Firefox 3
+
+ The Firefox 3 Download Manager features new and improved APIs, including support for multiple progress listeners.
+
+
+
+ Using nsILoginManager
+
+ The Password Manager has been replaced by the new Login Manager.
+
+
+
+ Embedding XBL bindings
+
+ You can now use the data: URL scheme from chrome code to embed XBL bindings directly instead of having them in separate XML files.
+
+
+
+ Localizing extension descriptions
+
+ Firefox 3 offers a new method for localizing add-on metadata. This lets the localized details be available as soon as the add-on has been downloaded, as well as when the add-on is disabled.
+
+
+
+ Localization and Plurals
+
+ Firefox 3 adds the new PluralForm module, which provides tools to aid in correctly pluralizing words in multiple localizations.
+
+
+
+ Theme changes in Firefox 3
+
+ Notes and information of use to people who want to create themes for Firefox 3.
+
+

New components and functionality

+
+
+ FUEL Library
+
+ FUEL is about making it easier for extension developers to be productive, by minimizing some of the XPCOM formality and adding some "modern" JavaScript ideas.
+
+
+
+ Places
+
+ The history and bookmarks APIs have been completely replaced by the new Places API.
+
+
+
+ Idle service
+
+ Firefox 3 offers the new {{Interface("nsIIdleService")}} interface, which lets extensions determine how long it's been since the user last pressed a key or moved their mouse.
+
+
+
+ ZIP writer
+
+ The new {{Interface("nsIZipWriter")}} interface lets extensions create ZIP archives.
+
+
+
+ Full page zoom
+
+ Firefox 3 improves the user experience by offering full page zoom in addition to text-only zoom.
+
+
+
+ Interfacing with the XPCOM cycle collector
+
+ XPCOM code can now take advantage of the cycle collector, which helps ensure that unused memory gets released instead of leaking.
+
+
+
+ The Thread Manager
+
+ Firefox 3 provides the new {{Interface("nsIThreadManager")}} interface, along with new interfaces for threads and thread events, which provides a convenient way to create and manage threads in your code.
+
+
+
+ JavaScript modules
+
+ Firefox 3 now offers a new shared code module mechanism that lets you easily create modules in JavaScript that can be loaded by extensions and applications for use, much like shared libraries.
+
+
+
+ The nsIJSON interface
+
+ Firefox 3 offers the new {{Interface("nsIJSON")}} interface, which offers high-performance encoding and decoding of JSON strings.
+
+
+
+ The nsIParentalControlsService interface
+
+ Firefox 3 now supports the Microsoft Windows Vista parental controls feature, and allows code to interact with it.
+
+
+
+ Using content preferences
+
+ Firefox 3 includes a new service for getting and setting arbitrary site-specific preferences that extensions as well as core code can use to keep track of their users' preferences for individual sites.
+
+
+
+ Plug-in Monitoring
+
+ A new component of the plugin system is now available to measure how long it takes plugins (e.g., Macromedia Flash) to execute their calls.
+
+

Fixed bugs

+
+
+ Notable bugs fixed in Firefox 3
+
+ This article provides information about bugs that have been fixed in Firefox 3.
+
+

New features for end users

+

User experience

+ +

Security and privacy

+ +

Performance

+ +

See also

+ +
{{Firefox_for_developers('2')}}
diff --git a/files/pt-pt/mozilla/firefox/releases/70/index.html b/files/pt-pt/mozilla/firefox/releases/70/index.html new file mode 100644 index 0000000000..7b67fba949 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/releases/70/index.html @@ -0,0 +1,140 @@ +--- +title: Firefox 70 para programadores +slug: Mozilla/Firefox/Releases/70 +tags: + - '70' + - Firefox + - Lançamento + - Mozilla +translation_of: Mozilla/Firefox/Releases/70 +--- +

{{FirefoxSidebar}}{{Draft}}

+ +

Este artigo fornece informaçaõ acerca das alterações no Firefox 70 que irão afetar od programadores. O Firefox 70 é a versão Beta atual do Firefox, e irá ser distribuida no dia 22 de outubro de 2019.

+ +

Alterações para os programadores da Web

+ +

Ferramentas do programador

+ + + +

Removals

+ +

HTML

+ +

No changes.

+ +

 Removals

+ +

CSS

+ + + +

Removals

+ + + +

SVG

+ +

No changes.

+ +

Removals

+ +

JavaScript

+ + + +

Removals

+ +

APIs

+ + + +

Novas APIs

+ +

DOM

+ + + +

Eventos DOM

+ +

Service workers

+ +

Media, Web Audio, and WebRTC

+ +

Canvas and WebGL

+ + + +

Removals

+ +

Segurança

+ +

No changes.

+ +

Removals

+ +

Plug-ins

+ +

No changes.

+ +

Removals

+ +

Outros

+ +

No changes.

+ +

Removals

+ +

Alterações para os programadores de extras (add-on)

+ +

Alterações de API

+ +

Sem alterações.

+ +

Removals

+ +

Alfetarções de Manifest

+ +

Sem alterações.

+ +

Removals

+ +

Consultar também:

+ + + +

Versões antigas

+ +

{{Firefox_for_developers(69)}}

diff --git a/files/pt-pt/mozilla/firefox/releases/index.html b/files/pt-pt/mozilla/firefox/releases/index.html new file mode 100644 index 0000000000..68bc5d41e9 --- /dev/null +++ b/files/pt-pt/mozilla/firefox/releases/index.html @@ -0,0 +1,25 @@ +--- +title: Firefox - Notas de lançamento do programador +slug: Mozilla/Firefox/Releases +tags: + - Firefox + - Landing + - Lançamento + - Mozilla +translation_of: Mozilla/Firefox/Releases +--- +
{{FirefoxSidebar}}
+ +

Esta página fornece hiperligações para os artigos de "Firefox X para programadores" para cada lançamento do Firefox. Estas notas deixam-no ver quais as funcionalidades que foram adicionadas e os erros eliminados em cada versão do Firefox. Tudo escrito para dar aos programadores como você a informação de que eles mais precisam. Seja bem-vindo.

+ +
{{ListSubpages("",1,1,1)}}
+ +
 
+ +

Ufa! Isso é muito de Firefoxen!

+ +

Consultar também

+ + -- cgit v1.2.3-54-g00ecf