diff options
Diffstat (limited to 'files/pt-pt/mozilla/firefox')
11 files changed, 0 insertions, 1226 deletions
diff --git a/files/pt-pt/mozilla/firefox/edição_programador/index.html b/files/pt-pt/mozilla/firefox/edição_programador/index.html deleted file mode 100644 index 3f3e7d3c90..0000000000 --- a/files/pt-pt/mozilla/firefox/edição_programador/index.html +++ /dev/null @@ -1,36 +0,0 @@ ---- -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 ---- -<div>{{FirefoxSidebar}}</div> - -<p>A 'Edição do Programador' do Firefox é uma versão do Firefox que está preparada para os programadores da Web. Esta inclui:</p> - -<ul> - <li><strong>as funcionalidades mais recentes do Firefox</strong>: a Edição de Desenvolvimento do Firefox substitui o canal antigo Aurora. - - <ul> - <li>Cada nova versão inclui funcionalidades que foram estabilizadas por meio das compilações noturnas</li> - <li>As novas funcionalidades entram no canal do Firefox Beta seis semanas antes de serem lançadas</li> - <li>As novas funcionalidades são estáveis durente 12 semanas antes de aparecerem na versão lançada do Firefox</li> - </ul> - </li> - <li><strong>um perfil do programador separado</strong>: isto significa que pode executar facilmente a 'Edição de Desenvolvimento' com a sua versão Beta ou de lançamento do Firefox.</li> - <li><strong>ferramentas de desenvolvimento experimentais</strong>: nós iremos incluir as ferramentas experimentais que ainda não são prontas para produção. Por exemplo, a 'Edição de Desenvolvimento' inclui o <a href="/en-US/docs/Tools/Firefox_Tools_Adapter">Adaptador de Ferramentas do Firefox</a> (descontinuado), que permite-lhe ligar às <a href="/pt-PT/docs/Tools">Ferramentas de desenvolvimento do Firefox</a> para outros navegadores, tais como Safari no iOS e Chrome no Android.</li> - <li><strong>preferências adaptadas para os programadores da Web</strong>: nós definimos valores de preferência predefinidos personalizados para os programadores da Web. Por exemplo, chrome e a depuração remota estão ativados por predefinição na 'Edição de Desenvolvimento'.</li> - <li><strong>um tema distinto</strong>: isto inclui o acesso mais rápido às ferramentas de programador.</li> -</ul> - -<p><a href="/pt-PT/docs/Mozilla/Firefox/Releases" style="margin: 0 40px 20px 40px; padding: 10px; text-align: center; border-radius: 4px; display: inline-block; background-color: #81BC2E; white-space: nowrap; color: white; text-shadow: 0px 1px 0px rgba(0, 0, 0, 0.25); box-shadow: 0px 1px 0px 0px rgba(0, 0, 0, 0.2), 0px -1px 0px 0px rgba(0, 0, 0, 0.3) inset;">Novidades na Edição do Programador?</a></p> - -<p><a href="https://www.mozilla.org/pt-PT/firefox/developer/" style="float: right; margin: 0 30px 20px 30px; padding: 10px; text-align: center; border-radius: 4px; display: inline-block; background-color: #81BC2E; white-space: nowrap; color: white; text-shadow: 0px 1px 0px rgba(0, 0, 0, 0.25); box-shadow: 0px 1px 0px 0px rgba(0, 0, 0, 0.2), 0px -1px 0px 0px rgba(0, 0, 0, 0.3) inset;">Transferir a Edição do Programador</a></p> diff --git a/files/pt-pt/mozilla/firefox/multiple_profiles/index.html b/files/pt-pt/mozilla/firefox/multiple_profiles/index.html deleted file mode 100644 index b7935947d7..0000000000 --- a/files/pt-pt/mozilla/firefox/multiple_profiles/index.html +++ /dev/null @@ -1,244 +0,0 @@ ---- -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 ---- -<div>{{FirefoxSidebar}}</div> - -<p class="summary">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 <a href="https://support.mozilla.org/pt-PT/kb/perfis-onde-firefox-armazena-os-seus-marcadores">detalhes sobre os perfis</a> no site de apoio do utilizador final da Mozilla.</p> - -<h2 id="Razões_para_ter_múltiplos_profiles">Razões para ter múltiplos profiles</h2> - -<p>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.</p> - -<p>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.</p> - -<p>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.</p> - -<h2 id="Canais_de_desenvolvimento_do_navegador_disponíveis">Canais de desenvolvimento do navegador disponíveis</h2> - -<p>There are four available browser channels, each at a different level of stability and development. The four channels are <a class="link-https" href="https://www.mozilla.org/firefox/new/" title="Firefox Stable">Release</a>, <a class="link-https" href="https://www.mozilla.org/firefox/beta/" title="Firefox Beta">Beta</a>, <a href="https://www.mozilla.org/firefox/aurora/">Developer Edition</a>, and <a class="external" href="https://nightly.mozilla.org/" title="Firefox Nightly">Nightly</a>. 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.</p> - -<h2 id="Ferramentas_de_terceiros">Ferramentas de terceiros</h2> - -<p>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.</p> - -<div class="note"> -<p>This list is by no means exhaustive. Please add any helpful tools you discover to the list!</p> -</div> - -<h3 id="Mac_OS_X">Mac OS X</h3> - -<ul> - <li><a href="http://davemartorana.com/multifirefox/">Multifirefox</a> by Dave Martorana</li> -</ul> - -<h2 id="Gestão_de_perfis">Gestão de perfis</h2> - -<h3 id="Determining_the_profile_while_Firefox_is_running">Determining the profile while Firefox is running</h3> - -<p>To determine the profile of a currently-running Firefox instance in Windows, macOS or Linux,</p> - -<ol> - <li>Type about:profiles into the browser URL search bar.</li> - <li>The page presents a list of all of your profiles, each beginning with "Profile: " followed by its name.</li> - <li>The one being run by this Firefox instance will include the bold text "<strong>This is the profile in use</strong>" For example, if you find that text beneath the entry for "Profile: Suzie", then you are running in a profile named <em>Suzie</em>.</li> -</ol> - -<h3 id="Launching_Firefox_into_a_Desired_Profile">Launching Firefox into a Desired Profile</h3> - -<p id="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_exitquitterminate_all_running_instances_of_Firefox_FirefoxDeveloperEdition_or_Nightly._Then_follow_the_instructions_below_applicable_to_your_operating_system."><strong>You cannot change the profile while Firefox is running.</strong> 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 <em>Firefox</em>, <em>FirefoxDeveloperEdition</em> or <em>Nightly</em>. Then follow the instructions below, applicable to your operating system.</p> - -<h4 id="Windows">Windows</h4> - -<h5 id="Windows_XP">Windows XP</h5> - -<ol> - <li>Click the Start button.</li> - <li>Click "Run".</li> - <li> - <p>Type <code>firefox --ProfileManager</code>.</p> - </li> -</ol> - -<h5 id="Windows_Vista7">Windows Vista/7</h5> - -<ol> - <li>Click the Start button.</li> - <li>Click the search bar at the bottom.</li> - <li> - <p>Type <code>firefox --ProfileManager</code>.</p> - </li> -</ol> - -<h5 id="Windows_88.1">Windows 8/8.1</h5> - -<ol> - <li>Press "Windows + R" on your keyboard.</li> - <li>Type <code>firefox --ProfileManager</code>.</li> -</ol> - -<p>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.</p> - -<h4 id="Linux">Linux</h4> - -<p>If Firefox is already included in your Linux distribution, or if you have installed Firefox with the package manager of your Linux distribution:</p> - -<ol> - <li>At the top of the Firefox window, click on the File menu and select Quit.</li> - <li>In Terminal run <code>firefox --ProfileManager</code></li> -</ol> - -<p>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.</p> - -<h4 id="macOS">macOS</h4> - -<ol> - <li>Run the <em>Terminal</em> application, which is found in Applications/Utilities.</li> - <li>Type or paste in the path to Firefox, followed by <code>.app/Contents/MacOS/firefox</code>. For example, if Firefox is installed in the recommended location, you would enter <code>/Applications/Firefox.app/Contents/MacOS/firefox</code>.</li> - <li>If you have the path to your desired profile handy, enter a space character, followed by <code>-profile</code> 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 <code>--profilemanager</code>. This will present the Profile Manager window in which you can make your selection.</li> - <li>Hit <em>return.</em></li> -</ol> - -<p>Here is a complete example Terminal command from steps 2-3:</p> - -<pre>/Applications/Firefox.app/Contents/macOS/firefox -profile /Users/Suzie/Library/Application\ Support/Firefox/Profiles/r99d1z7c.default</pre> - -<p>If you want to do this frequently and more easily, you may wish to create an <em>Automator</em> application, as explained in <a href="http://sonnygill.net/mac/mac-multiple-firefox-profiles/">this tutorial</a>.</p> - -<h3 id="Criar_um_perfil">Criar um perfil</h3> - -<h4 id="Creating_a_profile_through_the_Profile_Manager">Creating a profile through the Profile Manager</h4> - -<p>These instructions should be the same for all operating systems.</p> - -<ol> - <li>To start the Create Profile Wizard, click "Create Profile..." in the Profile Manager.</li> - <li>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.</li> - <li>You can also choose where to store the profile on your computer. To select storage location, click Choose Folder....</li> - <li>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.</li> - <li>To create the new profile, click Finish.</li> -</ol> - -<h4 id="Creating_a_profile_through_the_Firefox_browser">Creating a profile through the Firefox browser</h4> - -<p>You can create a new Firefox profile directly from the browser.</p> - -<ol> - <li>Type about:profiles into the browser URL search bar</li> - <li>On the page, click Create a New Profile button</li> - <li>Read the introduction, and click Next</li> - <li>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.</li> - <li>Optionally, to change where the profile will be stored on your computer, click Choose Folder...</li> - <li>To create the new profile, click Finish.</li> -</ol> - -<h3 id="Eliminar_um_perfil">Eliminar um perfil</h3> - -<ol> - <li>In the Profile Manager, select the profile to remove, and click Delete Profile....</li> - <li>Confirm that you wish to delete the profile: - <ul> - <li>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.</li> - <li>Delete Files removes the profile and its files, including the profile bookmarks, settings, passwords, etc.<br> - <br> - {{ warning("If you use the \"Delete Files\" option, the profile folder, and files will be deleted. This action cannot be undone.") }}</li> - <li>Cancel interrupts the profile deletion.</li> - </ul> - </li> -</ol> - -<h3 id="Renomear_um_perfil">Renomear um perfil</h3> - -<ol> - <li>In the Profile Manager, select the profile you want to rename, and then click "Rename Profile".</li> - <li>Enter a new name for the profile and click on OK.</li> -</ol> - -<div class="note"> -<p>Nota: The folder containing the files for the profile is not renamed.</p> -</div> - -<h2 id="Opções">Opções</h2> - -<h3 id="Trabalhar_off-line">Trabalhar off-line</h3> - -<p>Choosing this option loads the selected profile, and starts Firefox offline. You can view previously viewed web pages, and experiment with your profile.</p> - -<h3 id="Não_perguntar_no_arranque">Não perguntar no arranque</h3> - -<p>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.</p> - -<div class="note"> -<p>Nota: To access other profiles after selecting this option, you must start the Profile Manager first.</p> -</div> - -<h2 id="Utilizar_os_perfis">Utilizar os perfis</h2> - -<h3 id="Windows_2">Windows</h3> - -<p>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:</p> - -<ol> - <li>Right-click the icon and choose "Properties".</li> - <li>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.</li> - <li>After the closing quote, add <code>-ProfileManager</code>.</li> - <li>Click Ok.</li> -</ol> - -<p>Now whenever you double click that icon, the profile manager should appear, allowing you to choose which profile you'd like to use.</p> - -<p>If you want individual icons to launch specific profiles, you will need to edit the "Target" of each icon. To do this:</p> - -<ol> - <li>Right-click the icon and choose "Properties".</li> - <li>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.</li> - <li>To permanently set a specific profile, add <code>-p PROFILE_NAME</code> to the target path, but outside of the quotes, replacing "PROFILE_NAME" with the actual profile name you chose.</li> - <li>If you would also like to allow multiple instances of Firefox to run at the same time, add <code>-no-remote</code> after the profile name.</li> -</ol> - -<p>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<code>.</code></p> - -<h3 id="Linux_2">Linux</h3> - -<p>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: <a class="external" href="https://blog.randell.ph/how-to-create-custom-application-launchers-in-gnome-3/" title="How to create custom application launchers in gnome 3">Gnome 3 Custom application launcher</a>. 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.</p> - -<p>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.</p> - -<ol> - <li>Set the "command" text field to target the executable file, likely "/usr/bin/firefox", and add the <code>-p</code> parameter.</li> -</ol> - -<p>If you want individual icons to launch specific profiles, you will need to set the command line for your new launcher. To do this:</p> - -<ol> - <li>Set the "command" text field to target the executable file, likely "/usr/bin/firefox", and add the <code>-p PROFILE_NAME</code> parameter, replacing "PROFILE_NAME" with the specific profile.</li> - <li>Repeat as necessary, for each additional profile you want to set.</li> - <li>If you would also like to allow multiple instances of Firefox to run at the same time, add "-no-remote" after the profile name.</li> -</ol> - -<h3 id="Mac_OS_X_2">Mac OS X</h3> - -<p>You can find a useful tutorial to set up custom launchers here: <a href="https://spf13.com/post/managing-multiple-firefox-profiles-in-os-x/" title="Managing Multiple Firefox Profiles in OSX">Managing Multiple Firefox Profiles in OSX</a>. 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.</p> - -<h2 id="Configurar_vários_perfis_para_diferentes_canais_do_Firefox">Configurar vários perfis para diferentes canais do Firefox</h2> - -<p>This section will be especially helpful if you are a developer, wanting to work with multiple channels, and each having their separate launcher.</p> - -<h3 id="Windows_3">Windows</h3> - -<p>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 <a href="#Windows">Windows Launcher</a>.</p> - -<h3 id="Linux_3">Linux</h3> - -<p>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 <a href="#Linux">here</a>. 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 <code>-no-remote</code> part to the end of the command field, so that you could run multiple instances at the same time.</p> - -<h3 id="Mac_OS_X_3">Mac OS X</h3> - -<p>You can find a useful tutorial to set up custom launchers here: <a href="https://spf13.com/post/managing-multiple-firefox-profiles-in-os-x/" title="Managing Multiple Firefox Profiles in OSX">Managing Multiple Firefox Profiles in OSX</a>. 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.</p> 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 deleted file mode 100644 index d6efcd07ea..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/cross_process_object_wrappers/index.html +++ /dev/null @@ -1,157 +0,0 @@ ---- -title: Cross Process Object Wrappers -slug: Mozilla/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers ---- -<div>{{FirefoxSidebar}}</div><div class="summary"> -<p>Este documento descreve <em>Cross Process Object Wrappers</em> (CPOWs), que permite ao código de <em>chrome </em>aceder sincronamente ao conteúdo no 'Multiprocessos do Firefox'.</p> -</div> - -<div class="warning"> -<p>Note that from Firefox 47 onwards, <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers#Safe_and_unsafe_CPOWs">unsafe CPOW usage</a> 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 <a href="/en-US/docs/Tools/Browser_Console">Browser Console</a>.</p> - -<p>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.</p> -</div> - -<p>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.</p> - -<p>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 <a href="/en-US/docs/The_message_manager">message manager</a>.</p> - -<p><strong>Chrome to content messaging must be asynchronous</strong>. 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.<br> - <br> - 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 <a href="/en-US/docs/Cross_Process_Object_Wrappers#Limitations_of_CPOWs">serious limitations and can cause responsiveness problems</a>, so should only be used when necessary and only as a migration aid.</p> - -<h2 id="Passagem_de_CPOWs_de_frame_scripts">Passagem de CPOWs de <em>frame scripts</em></h2> - -<p>Frame scripts can send messages to chrome using one of two global functions: <a href="/en-US/docs/The_message_manager#Content_to_chrome"><code>sendAsyncMessage()</code> or <code>sendSyncMessage()</code></a>. 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 <code>clicked</code> property of the third argument:</p> - -<pre class="brush: js">// frame script -addEventListener("click", function (event) { - sendAsyncMessage("my-e10s-extension-message", {}, { clicked : event.target }); -}, false);</pre> - -<p>In the chrome script, the DOM node is now accessible through a Cross Process Object Wrapper, as a property of the <code>objects</code> property of the message. The chrome script can get and set the wrapped object's properties and call its functions:</p> - -<pre class="brush: js">// 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"); -}</pre> - -<h2 id="CPOWs_gerados_automaticamente">CPOWs gerados automaticamente</h2> - -<p>Add-ons that have not declared themselves multiprocess compatible are set up with a number of <a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#Compatibility_shims">compatibility shims</a>. One of these shims provides the following behavior: whenever chrome code tries to access content directly (for example, through <a href="/en/docs/Working_with_windows_in_chrome_code#The_content_shortcut"><code>window.content</code></a> or <a href="/en-US/docs/Mozilla/Tech/XUL/browser#p-contentDocument"><code>browser.contentDocument</code></a>), it is given back a CPOW that wraps the content object. This means that examples like this will actually work, even in multiprocess Firefox:</p> - -<pre class="brush: js">gBrowser.selectedBrowser.contentDocument.body.innerHTML = "replaced by chrome code";</pre> - -<p>It's still important to keep in mind, though, that this is access through a CPOW and not direct access to content.</p> - -<h2 id="CPOWs_bidirecionais">CPOWs bidirecionais</h2> - -<p>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.</p> - -<p>This means you can write code like this:</p> - -<pre class="brush: js">// 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);</pre> - -<pre class="brush: js">// 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"); - }); - }); -</pre> - -<h2 id="Mapear_conteúdo_de_documentos_para_navegadores_XUL">Mapear conteúdo de documentos para navegadores XUL</h2> - -<p>A common pattern is to get the XUL <a href="/en-US/docs/XUL/browser"><code><browser></code></a> that corresponds to a content document. To enable this, <code>gBrowser.getBrowserForDocument</code> and <code>gBrowser.getBrowserForContentWindow</code> can be passed a CPOW for the content document and content window, respectively, and return the XUL <code><browser> </code>that these documents / windows belong to. Both return <code>null</code> if no such browser can be found.</p> - -<h2 id="Limitações_de_CPOWs">Limitações de CPOWs</h2> - -<p>Although CPOWs can be convenient they have several major limitations, which are listed below.</p> - -<h3 id="CPOWs_e_APIs_de_plataforma">CPOWs e APIs de plataforma</h3> - -<p>You can't pass CPOWs into platform APIs that expect to receive DOM objects. For example, you can't pass a CPOW into <a href="http://dxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIFocusManager.idl"><code>nsIFocusManager.setFocus()</code></a>.</p> - -<p>Also, from Firefox 47 onwards, browser code can no longer perform <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers#Safe_and_unsafe_CPOWs">unsafe CPOW operations</a>. This means that as an add-on developer, you should not pass CPOWs into browser APIs.</p> - -<h3 id="Reação_de_Chrome">Reação de <em>Chrome</em></h3> - -<p>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.</p> - -<p>Consulte em baixo <strong>CPOWs seguros e inseguros</strong> para mais sobre isto.</p> - -<h3 id="Desempenho">Desempenho</h3> - -<p>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.</p> - -<h3 id="Ordenação_de_mensagem">Ordenação de mensagem</h3> - -<p>CPOWs can violate assumptions you might make about message ordering. Consider this code:</p> - -<pre class="brush: js">mm.addMessageListener("GotLoadEvent", function (msg) { - mm.sendAsyncMessage("ChangeDocumentURI", {newURI: "hello.com"}); - let uri = msg.objects.document.documentURI; - dump("Received load event: " + uri + "\n"); -}); -</pre> - -<p>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 <code>uri</code> 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 <code>uri</code> will have its previous value.<br> - <br> - 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.</p> - -<h2 id="CPOWs_seguros_e_inseguros">CPOWs seguros e inseguros</h2> - -<p>The main reason CPOWs can be bad for responsiveness is that they make the chrome process block on the content process.</p> - -<p>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:</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/12485/unsafe-cpow.svg" style="display: block; height: 579px; margin-left: auto; margin-right: auto; width: 897px;"></p> - -<p>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.</p> - -<p>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:</p> - -<p><br> - <img alt="" src="https://mdn.mozillademos.org/files/12481/safe-cpow.svg" style="display: block; height: 472px; margin-left: auto; margin-right: auto; width: 640px;"></p> - -<p>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.</p> - -<p>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.</p> - -<p>This situation is thus called "safe CPOW usage". All other uses of CPOWs are called "unsafe CPOW usage".</p> - -<p>Consulyat também:</p> - -<ul> - <li><a href="https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/">https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/</a></li> - <li><a href="http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/">http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/</a></li> -</ul> - -<p> </p> - -<p> </p> 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 deleted file mode 100644 index 6f22e9a0b7..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/depuracao_de_frame_scripts/index.html +++ /dev/null @@ -1,56 +0,0 @@ ---- -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 ---- -<div>{{FirefoxSidebar}}</div><div class="geckoVersionNote"> -<p>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.</p> -</div> - -<p>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 <a href="/en-US/docs/Tools">Firefox Developer Tools</a> - specifically: the <a href="/en-US/docs/Web/API/Console">console</a>, the <a href="/en-US/docs/Tools/Debugger">JavaScript debugger</a>, and <a href="/en-US/docs/Tools/Scratchpad">Scratchpad</a> - but attaches them to the browser's content process. This means you can debug the frame scripts in your add-on.</p> - -<h2 id="Abrir_a_Caixa_de_Ferrmanetas_de_Conteúdo_de_Navegador">Abrir a Caixa de Ferrmanetas de Conteúdo de Navegador</h2> - -<p>{{EmbedYouTube("Cg6X_zIu7Xk")}}</p> - -<p>To open the Browser Content Toolbox, you'll need to:</p> - -<ul> - <li>be running Firefox Nightly</li> - <li>have multiprocess Firefox enabled: open the "Preferences" page, select "Enable E10S (multi-process)", and restart. As a visual indicator that you're running multiprocess Firefox, the titles of remote tabs are underlined.</li> - <li>enable the <a href="/en-US/docs/Tools/Tools_Toolbox#Settings">"chrome and add-on debugging" and "remote debugging" options in the Firefox Developer Toolbox Options</a></li> -</ul> - -<p>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:</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/9761/browser-content-toolbox.png" style="display: block; height: 854px; margin-left: auto; margin-right: auto; width: 723px;">If you've used the <a href="/en-US/docs/Tools/Tools_Toolbox">Firefox Developer Tools</a> before, this should look pretty familiar.</p> - -<p>Along the top is a row of tabs that you can use to switch the active tool. Currently, we only support the <a href="/en-US/docs/Web/API/Console">Console</a>, the <a href="/en-US/docs/Tools/Debugger">Debugger</a>, and <a href="/en-US/docs/Tools/Scratchpad">Scratchpad</a> in the Browser Content Toolbox. At the right of this row are three buttons that activate the <a href="/en-US/docs/Tools/Web_Console#The_split_console">split console</a>, open settings, and close the toolbox.</p> - -<p>The rest of the toolbox is taken up with the tool you've currently selected.</p> - -<h2 id="Utilização">Utilização</h2> - -<p>{{EmbedYouTube("XF0ULNnNOxg")}}</p> - -<h3 id="O_Depurador">O Depurador</h3> - -<p>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:</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/9771/browser-content-toolbox-listing.png" style="display: block; margin-left: auto; margin-right: auto; width: 723px;">You can set breakpoints, of course, and do all the other <a href="/en-US/docs/Tools/Debugger">things supported by the debugger</a>.</p> - -<h3 id="A_Consola">A Consola</h3> - -<p>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:</p> - -<ul> - <li>Set a breakpoint in your frame script.</li> - <li>When you hit the breakpoint, switch to the Console, or activate the <a href="/en-US/docs/Tools/Web_Console#The_split_console">split console</a> by pressing "Escape".</li> -</ul> - -<p>Now the console's scope is your frame script's scope, and you can interact directly with it:</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/9769/browser-content-toolbox-debugging.png" style="display: block; margin-left: auto; margin-right: auto; width: 839px;"></p> 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 deleted file mode 100644 index 88d8419e69..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/gestor_de_mensagens/index.html +++ /dev/null @@ -1,74 +0,0 @@ ---- -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 ---- -<div>{{FirefoxSidebar}}</div><p>Os gestores de mensagens fornecem uma maneira para o código de <em>JavaScript</em> <em>chrome</em>-privilegiado para comunicar através dos limites de processo. Eles são particularmente úteis para permitir que código do <em>chrome</em>, incluindo o código do navegador e o código de extensão, para aceder ao conteúdo da <em>Web </em>enquanto o navegador está a executar conteúdo da <em>Web</em> num processo separado</p> - -<p>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.</p> - -<p>These guides explain how to use message managers in multiprocess Firefox.</p> - -<p>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.</p> - -<hr> -<h2 id="Guias">Guias</h2> - -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Message_manager_overview">Message manager overview</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Frame_script_loading_and_lifetime">Frame script loading and lifetime</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Communicating_with_frame_scripts">Communicating with frame scripts</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Performance">Performance Best Practices</a></dt> - <dd> </dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Frame_script_environment">Frame script environment</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/_Limitations_of_frame_scripts">Limitations of frame scripts</a></dt> - <dd> </dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager/Process_scripts">Process scripts</a></dt> - <dd> </dd> -</dl> -</div> -</div> - -<hr> -<h2 id="Referência_de_API">Referência de API</h2> - -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIFrameScriptLoader">nsIFrameScriptLoader</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListenerManager">nsIMessageListenerManager</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageBroadcaster">nsIMessageBroadcaster</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageSender">nsIMessageSender</a></dt> - <dd> </dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsISyncMessageSender">nsISyncMessageSender</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentFrameMessageManager">nsIContentFrameMessageManager</a></dt> - <dd> </dd> - <dt><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProcessScriptLoader">nsIProcessScriptLoader</a></dt> - <dd> </dd> -</dl> -</div> -</div> diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/glossario/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/glossario/index.html deleted file mode 100644 index 22bb1b5b57..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/glossario/index.html +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Glossário -slug: Mozilla/Firefox/Multiprocess_Firefox/Glossario -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Glossary ---- -<div>{{FirefoxSidebar}}</div><div class="column-container"> -<div class="column-half"> -<dl> - <dt>Child-to-parent CPOWs</dt> - <dd>CPOWs that refer to objects in the parent (chrome) process.</dd> - <dt>Chrome process (also called the parent process)</dt> - <dd>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.</dd> - <dt>Content process (also called the child process)</dt> - <dd>The operating system process that runs web content, in multiprocess Firefox. Code for frame scripts runs in this process.</dd> - <dt>Content scripts</dt> - <dd>Deprecated term for frame scripts.</dd> - <dt>CPOWs</dt> - <dd>CPOW stands for Cross Process Object Wrapper. A CPOW gives chrome code synchronous access to content objects, as a migration aid. <a href="/en-US/docs/Cross_Process_Object_Wrappers">See more about CPOWs</a>.</dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt>Frame scripts</dt> - <dd>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.</dd> - <dt>Message manager</dt> - <dd>Message managers enable chrome code to load frame scripts into content processes, and communicate with them using a message-passing API. <a href="/en-US/docs/The_message_manager">See more about message managers</a>.</dd> - <dt>Parent-to-child CPOWs</dt> - <dd>CPOWs that refer to objects that live in the child (content) process.</dd> - <dt>Shim</dt> - <dd>...</dd> -</dl> -</div> -</div> - -<p> </p> diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/index.html deleted file mode 100644 index 8bf746e32a..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Multiprocessos do Firefox -slug: Mozilla/Firefox/Multiprocess_Firefox -tags: - - Firefox -translation_of: Mozilla/Firefox/Multiprocess_Firefox ---- -<div>{{FirefoxSidebar}}</div> - -<p>Nas versões antigas do Firefox para PC, todo o navegador era executado num único processo do sistema operativo. Em particular, o <em>JavaScript </em>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 <em>Web</em> (também conhecido como "conteúdo" ou "conteúdo da <em>Web</em>").<br> - <br> - As últimas versões do Firefox executam a IU do navegador num processo separado do conteúdo da <em>Web</em>. 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 <em> Electrolysis</em>, por vezes abreviado para <em>e10s</em>.</p> - -<p>As páginas da <em>Web</em> 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 <em>Web</em>.</p> - -<p>Em vez de aceder ao conteúdo da <em>web</em> diretamente, o código do <em>chrome</em> terá que utilizar o <a href="https://developer.mozilla.org/Firefox/Multiprocess_Firefox/Message_manager">gestor de mensagens</a>. Para ajudar a facilitar esta transição, nós implementamos <em><a href="https://developer.mozilla.org/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">Cross Process Object Wrappers</a></em> e alguns <a href="/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#Compatibility_shims"><em>shims</em> de compatibilidade para os programadores de extras</a>. Se é um programador de extras perguntando-se a si mesmo se está ou não afetado por esta alteração, consulte o <a href="/pt-PT/docs/Archive/Add-ons/Trabalhar_com_multiprocessos_Firefox">guia para trabalhar com multiprocessos do Firefox</a>.</p> - -<hr> -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/pt-PT/Firefox/Multiprocess_Firefox/Resumo_técnico">Resumo técnico</a></dt> - <dd>A very high-level view of how multiprocess Firefox is implemented.</dd> - <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Web_content_compatibility">Guia de compatibilidade do conteúdo da Web</a></dt> - <dd>Guidelines and details on potential Web site compatibility issues that may arise due to the transition. Tip: there aren't very many!</dd> - <dt><a href="/pt-PT/Firefox/Multiprocess_Firefox/Glossario">Glossário</a></dt> - <dd>Uma referência para o gíria utilizada em 'Multiprocessos do Firefox'.</dd> - <dt><a href="/Firefox/Multiprocess_Firefox/Message_Manager">Gestor de mensagens</a></dt> - <dd>Complete guide to the objects used to communicate between chrome and content.</dd> - <dt><a href="/en-US/Mozilla/Add-ons/SDK/Guides/Multiprocess_Firefox_and_the_SDK">Extras baseados em SDK</a></dt> - <dd>How to migrate add-ons developed using the Add-on SDK.</dd> - <dt><a href="/pt-PT/Firefox/Multiprocess_Firefox/Quais_os_URIs_que_carregam_e_onde">Quais os URIs que carregam e onde</a></dt> - <dd>A quick guide to which URIs - chrome:, about:, file:, resource: - are loaded into which process.</dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/Firefox/Multiprocess_Firefox/Motivation">Motivação</a></dt> - <dd>Why we are implementing multiprocess Firefox: performance, security, and stability.</dd> - <dt><a href="/Mozilla/Add-ons/Working_with_multiprocess_Firefox">Guia de migração de extras</a></dt> - <dd>If you are an add-on developer, find out if you are affected and how to update your code.</dd> - <dt><a href="/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">Cross Process Object Wrappers</a></dt> - <dd>Cross Process Object Wrappers are a migration aid, giving chrome code synchronous access to content.</dd> - <dt><a href="/pt-PT/Firefox/Multiprocess_Firefox/Depuracao_de_frame_scripts">Depuração de processos do conteúdo</a></dt> - <dd>How to debug code running in the content process, including frame and process scripts.</dd> - <dt><a href="/docs/Mozilla/Firefox/Multiprocess_Firefox/Tab_selection_in_multiprocess_Firefox">Seleção de separador nos multiprocessos do Firefox</a></dt> - <dd>How switching tabs works in multiprocess Firefox.</dd> -</dl> -</div> -</div> - -<hr> -<div class="column-container"> -<div class="column-half"> -<dl> - <dt><a href="/pt-PT/Firefox/Multiprocess_Firefox/Limitacoes_de_chrome_scripts">Limitações de chrome scripts</a></dt> - <dd>Práticas que já não irão funcionar no código de <em>chrome</em>, e como as fixar.</dd> -</dl> -</div> - -<div class="column-half"> -<dl> - <dt><a href="/pt-PT/Firefox/Multiprocess_Firefox/Limitacoes_de_frame_scripts">Limitações de frame scripts</a></dt> - <dd>Práticas que já não irão funcionar dentro de <em>frame scripts</em>, e o que fazer.</dd> -</dl> -</div> -</div> - -<hr> -<h2 id="Contacte-nos">Contacte-nos</h2> - -<p>Saiba mais sobre o projeto, participe, ou coloque as suas perguntas.</p> - -<ul> - <li><strong>Página do Projeto de Electrolysis</strong> (EN): <a href="https://wiki.mozilla.org/Electrolysis">https://wiki.mozilla.org/Electrolysis</a></li> - <li><strong>IRC</strong>: #e10s on <a href="https://wiki.mozilla.org/IRC">irc.mozilla.org</a></li> - <li><strong>Lista de endereços/discussão</strong>: <a href="https://groups.google.com/forum/#!forum/mozilla.dev.tech.electrolysis">dev.tech.electrolysis</a></li> -</ul> 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 deleted file mode 100644 index f761b2c6f7..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_chrome_scripts/index.html +++ /dev/null @@ -1,215 +0,0 @@ ---- -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 ---- -<div>{{FirefoxSidebar}}</div><p>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".</p> - -<p>This is one of a pair of articles: the other one lists <a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_frame_scripts">limitations of frame scripts</a>.</p> - -<h2 id="Compatibilidade_de_shims">Compatibilidade de <em>shims</em></h2> - -<p>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 <a href="https://developer.mozilla.org/en-US/docs/Cross_Process_Object_Wrappers">Cross Process Object Wrapper</a> that gives the chrome code synchronous access to the content.</p> - -<p>You'll get the shims for your add-on by default, unless you set the <a href="/en-US/Add-ons/Install_Manifests#multiprocessCompatible"><code>multiprocessCompatible</code> flag in your add-on's install manifest</a>.</p> - -<p>However, these shims are not a substitute for migrating extensions:</p> - -<ul> - <li>they are only a temporary measure, and will be removed eventually</li> - <li>they can have a bad effect on responsiveness</li> - <li>there are likely to be edge cases in which they don't work properly</li> -</ul> - -<p>You can see all the places where your add-on uses compatibility shims by setting the <span><code>dom.ipc.shims.enabledWarnings</code> preference and watching the browser console as you use the add-on.</span></p> - -<p>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:</p> - -<ul> - <li>whether a shim exists and what kind of behavior it provides</li> - <li>how to update your add-on so you don't need the shim</li> -</ul> - -<h2 id="gBrowser.contentWindow_window.content...">gBrowser.contentWindow, window.content...</h2> - -<h3 id="Sem_shim">Sem <em>shim</em></h3> - -<p>All APIs in the chrome process that provide direct access to content objects will no longer work. For example:</p> - -<pre class="brush: js">// chrome code - -gBrowser.contentWindow; // null - -gBrowser.contentDocument; // null - -gBrowser.selectedBrowser.contentWindow; // null - -window.content; // null - -content; // null -</pre> - -<p>As a special note, docshells live in the content process, so they are also inaccessible:</p> - -<pre>gBrowser.docShell; // null - -gBrowser.selectedBrowser.docShell; // null</pre> - -<h3 id="Com_shim">Com <em>shim</em></h3> - -<p>The shim will give you a <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOW</a> for the content object in these situations.</p> - -<p>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.</p> - -<p>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 <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">using the message manager</a>.</p> - -<h2 id="Limitações_de_CPOWs">Limitações de CPOWs</h2> - -<p><a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">Cross process object wrappers</a> (CPOWs) are a migration aid giving chrome code synchronous access to content objects. However, there are various <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers#Limitations_of_CPOWs">limitations on the kinds of things you can do with a CPOW</a>.</p> - -<div class="warning"> -<p>Note that from Firefox 47 onwards, <a href="https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers#Safe_and_unsafe_CPOWs">unsafe CPOW usage</a> 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 <a href="https://developer.mozilla.org/en-US/docs/Tools/Browser_Console">Browser Console</a>.</p> - -<p>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.</p> -</div> - -<h2 id="nsIContentPolicy">nsIContentPolicy</h2> - -<h3 id="Sem_shim_2">Sem <em>shim</em></h3> - -<p>In multiprocess Firefox, if you register the <code><a href="http://dxr.mozilla.org/mozilla-central/source/dom/base/nsIContentPolicy.idl">nsIContentPolicy</a></code> in the chrome process then it will never see any attempts to load web content, because they happen in the content process.</p> - -<h3 id="Com_shim_2">Com <em>shim</em></h3> - -<p>The shim enables you to add content policies in the chrome process. It transparently registers an <code>nsIContentPolicy</code> in the content process, whose <code>shouldLoad</code> just forwards to the chrome process. The content to check is forwarded as a <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOW</a>. 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.</p> - -<p>To make the shim unnecessary: define and register <code>nsIContentPolicy</code> in the content process. If you need to ensure that the policy is only registered once, use a <a href="/en-US/docs/User:wbamberg/Multiprocess_Firefox-2/Message_manager/Process_scripts">process script </a>to register the policy.</p> - -<h2 id="nsIWebProgressListener">nsIWebProgressListener</h2> - -<p>This API will work in the chrome process. There is a shim that gives you access to the <code>DOMWindow</code> property of the <a href="http://dxr.mozilla.org/mozilla-central/source/uriloader/base/nsIWebProgress.idl"><code>nsIWebProgress</code></a> object passed into <code>onStateChange</code>. However, the <code>DOMWindow</code> 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 <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1118880">bug 1118880</a>.</p> - -<p>Also note that unlike other shims, this shim is always active.</p> - -<p>Alternatively, you can use <code>nsIWebProgressListener</code> in the content process.</p> - -<h2 id="Observadores_no_processo_de_chrome">Observadores no processo de <em>chrome</em></h2> - -<p>Depending on the topic, you need to register observers in either the chrome process or in a frame script.</p> - -<p>For most topics you need to register observers in the chrome process.</p> - -<p>However, you must listen to <a href="/en/docs/Observer_Notifications#Documents"><code>content-document-global-created</code> and <code>document-element-inserted</code></a> in a frame script. <a href="http://dxr.mozilla.org/mozilla-central/source/xpcom/ds/nsIObserver.idl">Observers</a> for these topics get content objects as the <code>aSubject</code> argument to <code>observe()</code>, so notifications are not sent to the chrome process.</p> - -<p>There is a shim that will forward these two topics to the chrome process, sending <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOWs</a> as the <code>aSubject</code> argument.</p> - -<h3 id="Pedidos_de_HTTP">Pedidos de HTTP</h3> - -<p>You can't observe <a href="https://developer.mozilla.org/en/docs/Observer_Notifications#HTTP_requests">HTTP requests</a> in the content process. If you do, you'll get an error.<br> - <br> - If you do so in the chrome process, it will mostly work. The subject for the observer notification will be an <code><a href="http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsIHttpChannel.idl">nsIHttpChannel</a></code> as you would expect.</p> - -<p>A common pattern here is to use the <code>notificationCallbacks</code> property of the <code>nsIHttpChannel</code> to get the DOM window that initiated the load, like this:</p> - -<pre class="brush: js">observe: function (subject, topic, data) { - if (topic == "http-on-modify-request") { - var httpChannel = subject.QueryInterface(Ci.nsIHttpChannel); - var domWindow = httpChannel.notificationCallbacks.getInterface(Ci.nsIDOMWindow); - } -}</pre> - -<p>Or this:</p> - -<pre class="brush: js">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; - } -}</pre> - -<p>In multiprocess Firefox these patterns will no longer work: the <code>getInterface</code> call will fail.</p> - -<p>In multiprocess Firefox, <code>notificationCallbacks</code> is a special object that tries to emulate the single-process <code>notificationsCallbacks</code> object as best it can. It will return a dummy <code>nsILoadContext</code> when asked, but any attempt to get a window out of it will fail.<br> - <br> - There is an outstanding bug (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1108827">bug 1108827</a>) to implement a shim here that will make <code>notificationCallbacks</code> a <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOW</a> for the objects in the content process.</p> - -<p>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:</p> - -<pre class="brush: js">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); - } -}</pre> - -<p>However, before Firefox 38, this technique will not work if multiprocess Firefox is disabled: specifically, <code>topFrameElement</code> 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:</p> - -<ul> - <li>test whether <code>topFrameElement</code> is null</li> - <li>if it is, you're running in single-process Firefox, and should use the old way</li> - <li>if it isn't, you're running in multiprocess Firefox and should use the new way</li> -</ul> - -<p>From Firefox 38 onwards, the topFrameElement approach always works.</p> - -<h2 id="Eventos_DOM">Eventos DOM</h2> - -<h3 id="Sem_shim_3">Sem <em>shim</em></h3> - -<p>In multiprocess Firefox, if you want to register an event listener on some content DOM node, that needs to happen in the content process.</p> - -<p>It used to be that if you registered a listener on the <a href="/en-US/docs/XUL/browser">XUL <code><browser></code></a> or <a href="/en-US/docs/XUL/tab"><code><tab></code></a> 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.</p> - -<h3 id="Com_shim_3">Com <em>shim</em></h3> - -<p>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 <a href="/en-US/docs/Web/API/Event"><code>Event</code></a> object itself is relayed to the chrome process as a <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">CPOW</a>.</p> - -<p>To make the shim unnecessary: register event listeners on the global object inside a <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">frame script</a>. For example:</p> - -<pre class="brush: js">addEventListener("load", handler, true) // for example</pre> - -<div>If you need to contact the chrome process when that happens, send it a message.</div> - -<div> </div> - -<h2 id="Sandboxes"><em>Sandboxes</em></h2> - -<div>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.</div> - -<div> </div> - -<div>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 <a href="/en-US/docs/Components.utils.Sandbox">Components.utils.Sandbox</a>) then we'll actually make it in the content process.</div> - -<div> </div> - -<div> -<h2 id="nsIAboutModule">nsIAboutModule</h2> - -<p>By default, custom about: pages registered using <code><a href="/en-US/docs/XPCOM_Interface_Reference/nsIAboutModule">nsIAboutModule</a></code> are loaded in the chrome process. This means that you can't access their content from the content process (via XHR, for example).</p> - -<p>You can change this default in the code you use to register the about: URI. See <a href="/en-US/Firefox/Multiprocess_Firefox/about:_and_chrome:_URIs">about: and chrome: URIs</a>.</p> -</div> - -<h2 id="Módulos_de_código_de_JavaScript_(JSMs)">Módulos de código de <em>JavaScript </em>(JSMs)</h2> - -<div>In single-process Firefox, you can use <a href="/en-US/docs/Mozilla/JavaScript_code_modules">JavaScript code modules (JSMs)</a> 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.</div> - -<div> </div> - -<div>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.</div> - -<div> </div> - -<h2 id="nsIProtocolHandler">nsIProtocolHandler</h2> - -<div>In multiprocess Firefox, code which registers a custom protocol using <code><a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIProtocolHandler">nsIProtocolHandler</a></code> must register the custom protocol in the child content process.</div> - -<div>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.</div> - -<div> </div> - -<div>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 <a href="/en-US/Add-ons/SDK/Low-Level_APIs/remote_parent#Loading_modules_into_the_child_process"><code>remoteRequire()</code> in the "remote/parent" module</a>.</div> 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 deleted file mode 100644 index 999472c499..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/limitacoes_de_frame_scripts/index.html +++ /dev/null @@ -1,103 +0,0 @@ ---- -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 ---- -<div>{{FirefoxSidebar}}</div><p>Frame scripts run with <a href="/en-US/docs/Security_check_basics#Principals">system privileges</a> and have access to the <a href="/en-US/docs/Components_object">Components</a> object, enabling them to use <a href="/en-US/docs/Mozilla/Tech/XPCOM">XPCOM</a> objects and <a href="/en-US/docs/Mozilla/JavaScript_code_modules">JSMs</a>. 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.</p> - -<p>This is one of a pair of articles: the other one lists <a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts">limitations of chrome scripts</a>.</p> - -<h2 id="Restrições_de_Segurança_no_Acesso_de_Ficheiro">Restrições de Segurança no Acesso de Ficheiro</h2> - -<p>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.</p> - -<p>Examples of APIs Add-on authors should avoid in frame scripts:</p> - -<ul> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIFileStreams.idl"><code>nsIFileInputStream</code></a></li> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/netwerk/base/public/nsIFileStreams.idl"><code>nsIFileOutputStream</code></a></li> - <li><a href="/en-US/docs/Extensions/Using_the_DOM_File_API_in_chrome_code">Constructing a <code>File</code> from a string or <code>nsIFile</code></a> (but <code>File</code> objects can be sent via message manager)</li> - <li><code><a href="/en-US/docs/Web/API/HTMLInputElement/mozSetFileNameArray">HTMLInputElement.mozSetFileNameArray</a></code> (alternative: <code>mozSetFileArray</code>)</li> -</ul> - -<h2 id="XUL_e_IU_de_navegador">XUL e IU de navegador</h2> - -<p>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:</p> - -<ul> - <li><code><a href="http://dxr.mozilla.org/mozilla-central/source/embedding/components/windowwatcher/nsIPromptService.idl">nsIPromptService</a></code></li> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/widget/nsIFilePicker.idl"><code>nsIFilePicker</code></a></li> - <li><code>nsIXUL*</code></li> - <li><need more examples></li> -</ul> - -<h2 id="Serviços">Serviços</h2> - -<p>Some services will not work in frame scripts.</p> - -<ul> - <li>Services.search</li> - <li>Services.downloads</li> -</ul> - -<h2 id="Janelas_de_Chrome">Janelas de <em>Chrome</em></h2> - -<p>Anything that needs to use chrome windows will not work in the content process. For example:</p> - -<ul> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/mobile/android/components/SessionStore.idl"><code>nsISessionStore</code></a></li> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/xpfe/appshell/nsIWindowMediator.idl"><code>nsIWindowMediator</code></a></li> - <li><need more examples></li> -</ul> - -<h2 id="Places_API">Places API</h2> - -<p>A <a href="/pt-PT/docs/Mozilla/Tech/Places">API de Places</a> não pode ser utilizada dentro de uma <em>frame script</em>. Por exemplo:</p> - -<ul> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsINavHistoryService.idl"><code>nsINavHistoryService</code></a></li> - <li><a href="http://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsINavBookmarksService.idl"><code>nsINavBookmarksService</code></a></li> -</ul> - -<h2 id="Observadores_no_processo_de_conteúdo">Observadores no processo de conteúdo</h2> - -<p>As noted in <a href="https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#Observers_in_the_chrome_process">Observers in the chrome process</a>, most <a href="http://dxr.mozilla.org/mozilla-central/source/xpcom/ds/nsIObserver.idl">observers</a> should be registered in the chrome process and will not work in the content process. The exceptions are:</p> - -<ul> - <li><code><a href="https://developer.mozilla.org/en-US/docs/Observer_Notifications#Documents">content-document-global-created</a></code></li> - <li><a href="https://developer.mozilla.org/en-US/docs/Observer_Notifications#Documents"><code>document-element-inserted</code></a></li> - <li><a href="https://developer.mozilla.org/en-US/docs/Observer_Notifications#Windows"><code>outer-window-destroyed</code></a></li> - <li><a href="https://developer.mozilla.org/en-US/docs/Observer_Notifications#Windows"><code>inner-window-destroyed</code></a></li> - <li><a href="https://developer.mozilla.org/en-US/docs/Observer_Notifications#Windows"><code>dom-window-destroyed</code></a></li> -</ul> - -<p>These must be registered in the content process.</p> - -<h2 id="QI_from_content_window_to_chrome_window">QI from content window to chrome window</h2> - -<div>There's a particular pattern often used to get from a content window to the associated chrome window. It looks something like this:</div> - -<div> </div> - -<pre class="brush: js">window.QueryInterface(Ci.nsIInterfaceRequestor) - .getInterface(Ci.nsIWebNavigation) - .QueryInterface(Ci.nsIDocShellTreeItem) - .rootTreeItem - .QueryInterface(Ci.nsIInterfaceRequestor) - .getInterface(Ci.nsIDOMWindow);</pre> - -<div>This will no longer work. In the content process the root tree item is an <a href="http://dxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsITabChild.idl"><code>nsITabChild</code></a>, that cannot be converted to an <code>nsIDOMWindow</code>, so the second <code>getInterface</code> call here will fail.</div> - -<div> </div> - -<p>If you want a chrome window: send a message from the content process using the <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">message manager</a>. The <a href="/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIMessageListener#receiveMessage()"><code>target</code></a> property of the object passed into the message handler in the chrome process is the XUL <a href="/en-US/docs/XUL/browser"><code><browser></code></a> receiving the message, and you can get the chrome window from that (Note: I'm not really sure how...).</p> - -<h2 id="nsIAboutModule">nsIAboutModule</h2> - -<p>By default, custom <code>about:</code> pages registered using <a href="http://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/about/nsIAboutModule.idl"><code>nsIAboutModule</code></a> are loaded in the chrome process. This means that you can't access their content from the content process (via XHR, for example).</p> - -<p>You can change this default in the code you use to register the about: URI. See <a href="/en-US/Firefox/Multiprocess_Firefox/about:_and_chrome:_URIs">about: and chrome: URIs</a>.</p> - -<h2 id="Módulos_de_código_de_JavaScript_(JSMs)">Módulos de código de <em>JavaScript</em> (JSMs)</h2> - -<div>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 <a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#JavaScript_code_modules_%28JSMs%29">Limitations on chrome scripts</a> page.</div> 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 deleted file mode 100644 index 7a4ae7a993..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/quais_os_uris_que_carregam_e_onde/index.html +++ /dev/null @@ -1,62 +0,0 @@ ---- -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 ---- -<div>{{FirefoxSidebar}}</div><p>Baseado inicialmente no esquema de URI da página, o navegador pode decidir se deseja carregar uma página no processo de <em>chrome</em> ou um processo de conteúdo. Para alguns esquemas, pode alterar o comportamento predefinido.</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Esquema</th> - <th scope="col">Comportamento</th> - </tr> - </thead> - <tbody> - <tr> - <td><code>about:</code></td> - <td> - <p>By default, <code>about:</code> pages are always loaded in the chrome process. However, when you register a new <code>about:</code> page, you can change this default.</p> - - <p>Two new flags are defined in <code><a href="https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/about/nsIAboutModule.idl">nsIAboutModule</a></code>:</p> - - <ul> - <li><code>URI_CAN_LOAD_IN_CHILD</code>: the page will be loaded in the same process as the <code><a href="/en-US/docs/XUL/browser">browser</a></code> that has loaded it.</li> - <li><code>URI_MUST_LOAD_IN_CHILD</code>: the page will always be loaded in a child process.</li> - </ul> - - <p>To use one of these flags, return it from your implementation of <code>getURIFlags</code> in the <a href="/en-US/docs/Custom_about:_URLs">code that registers the <code>about:</code> URI</a>.</p> - - <p>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 - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1257201">Bug 1257201</a>.</p> - </td> - </tr> - <tr> - <td><code>chrome:</code></td> - <td> - <p>By default, <code>chrome:</code> pages are always loaded in the chrome process. However, when you register a new <code>chrome:</code> page, you can change this default.</p> - - <p>Two new flags are defined in the <a href="/en-US/docs/Chrome_Registration">chrome.manifest file</a>:</p> - - <ul> - <li>remoteenabled: the page will be loaded in the same process as the <code><a href="/en-US/docs/XUL/browser">browser</a></code> that has loaded it.</li> - <li>remoterequired: the page will always be loaded in a child process.</li> - </ul> - </td> - </tr> - <tr> - <td><code>file:</code></td> - <td> - <p>Carregado sempre num processo de conteúdo.</p> - - <p><strong>Nota:</strong> This does not mean <code>file:</code> URIs can be used freely by code in content processes. Sandboxing may blacklist particular directories and future changes may restrict <code>file:</code> URIs to a separate content process, isolated from regular web content. See <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1187099">bug 1187099</a> how this can affect addons attempting to load files from the profile directory.</p> - </td> - </tr> - <tr> - <td><code>resource:</code></td> - <td>Carregado sempre num processo de conteúdo.</td> - </tr> - </tbody> -</table> diff --git a/files/pt-pt/mozilla/firefox/multiprocess_firefox/resumo_técnico/index.html b/files/pt-pt/mozilla/firefox/multiprocess_firefox/resumo_técnico/index.html deleted file mode 100644 index aa2613a58e..0000000000 --- a/files/pt-pt/mozilla/firefox/multiprocess_firefox/resumo_técnico/index.html +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: Resumo técnico -slug: Mozilla/Firefox/Multiprocess_Firefox/Resumo_técnico -translation_of: Mozilla/Firefox/Multiprocess_Firefox/Technical_overview ---- -<div>{{FirefoxSidebar}}</div><div class="note"> -<p>This page is an edited extract from Bill McCloskey's blog post on multiprocess Firefox: <a class="external external-icon" href="http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/">http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/</a></p> -</div> - -<p>At a very high level, multiprocess Firefox works as follows. The process that starts up when Firefox launches is called the <em>parent process</em>. Initially, this process works similarly to single-process Firefox: it opens a window displaying <a href="http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.xul"><code>browser.xul</code></a>, 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 <code>window</code> object, which has a <code>document</code> property, and this document contains all the XML elements from <code>browser.xul</code>. All the Firefox menus, toolbars, sidebars, and tabs are XML elements in this document. Each tab element contains a <code><browser></code> element to display web content.</p> - -<p>The first place where multiprocess Firefox diverges from single-process Firefox is that each <code><browser></code> element has a <code>remote="true"</code> attribute. When such a browser element is added to the document, a new content process is started. This process is called a <em>child process</em>. An IPC channel is created that links the parent and child processes. Initially, the child displays <code>about:blank</code>, but the parent can send the child a command to navigate elsewhere.</p> - -<h2 id="Desenho"><strong id="drawing">Desenho</strong></h2> - -<p>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 <a href="http://benoitgirard.wordpress.com/2012/05/15/off-main-thread-compositing-omtc-and-why-it-matters/"><em>off main thread compositing</em></a> (OMTC). In brief, each Firefox window is broken into a series of <em>layers</em>, 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.</p> - -<p>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.</p> - -<p>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.</p> - -<p>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.</p> - -<h2 id="User_input"><strong id="input">User input</strong></h2> - -<p>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 <code><browser></code> 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.</p> - -<p>With multiple processes, event handling works the same way until the <code><browser></code> 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.</p> - -<h2 id="Inter-process_communication"><strong id="ipc">Inter-process communication</strong></h2> - -<p>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.</p> - -<p>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 <a href="https://wiki.mozilla.org/IPDL">IPDL</a>, which sort of stands for “inter-* protocol definition language”. A typical IPDL file is <code><a href="http://mxr.mozilla.org/mozilla-central/source/netwerk/ipc/PNecko.ipdl">PNecko.ipdl</a></code>. It defines a set messages and their parameters. Parameters are serialized and included in the message. To send a message <code>M</code>, C++ code just needs to call the method <code>SendM</code>. To receive the message, it implements the method <code>RecvM</code>.</p> - -<p>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:</p> - -<pre class="brush: cpp">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; -} -</pre> - -<p>When <code>AddHistoryEntry</code> 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 <code>AddHistoryEntry</code> on its side.</p> - -<p>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 <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/components/places/History.cpp?rev=8b9687f6c602#2326">this code</a>. Notice the content process check followed by the <code>SendVisitURI</code> call and an immediate return. The message is received <a href="http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp?rev=fecda5f4a0df#2666">here</a>; this code just calls <code>VisitURI</code> in the parent.</p> - -<p>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.</p> - -<h2 id="Frame_scripts"><strong id="contentscripts">Frame scripts</strong></h2> - -<p>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 <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">the message manager</a> 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 <code><browser></code> element. A message manager can be used to load JS code into the child process and to exchange messages with it.</p> - -<p>As a simple example, imagine that we want to be informed every time a <code>load</code> 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:</p> - -<pre class="brush: js">// Get the global message manager. -let mm = Cc["@<span class="skimlinks-unlinked">mozilla.org/globalmessagemanager;1</span>"]. - getService(Ci.nsIMessageListenerManager); - -// Wait for load event. -mm.addMessageListener("GotLoadEvent", function (msg) { - dump("Received load event: " + <span class="skimlinks-unlinked">msg.data.url</span> + "\n"); -}); - -// Load code into the child process to listen for the event. -mm.loadFrameScript("chrome://content/<span class="skimlinks-unlinked">content-script.js</span>", true); -</pre> - -<p>For this to work, we also need to have a file <code>content-script.js</code>:</p> - -<pre class="brush: js">// Listen for the load event. -addEventListener("load", function (e) { - // Inform the parent process. - let docURL = content.document.documentURI; - sendAsyncMessage("GotLoadEvent", {url: docURL}); -}, false); -</pre> - -<p>This file is called a <em>frame script</em>. When the <code>loadFrameScript</code> function call runs, the code for the script is run once for each <code><browser></code> 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 <code>true</code> parameter to <code>loadFrameScript</code>). Since the script is run once per browser, it can access the browser’s window object and docshell via the <code>content</code> and <code>docShell</code> globals.</p> - -<p>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 <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">message manager guide</a>.</p> - -<h2 id="Cross-process_APIs"><strong id="shims">Cross-process APIs</strong></h2> - -<p>There are a lot of APIs in Firefox that cross between the parent and child processes. An example is the <code>webNavigation</code> property of XUL <code><browser></code> elements. The <code>webNavigation</code> property is an object that provides methods like <code>loadURI</code>, <code>goBack</code>, and <code>goForward</code>. 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.</p> - -<p>The <code>webNavigation</code> 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 <code><browser></code> and <code><tabbrowser></code>. The <code><browser></code> customizations reside in <code><a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml?rev=754cf7fc84cd">browser.xml</a></code>. <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml?rev=754cf7fc84cd#262">Here</a> is how <code>browser.webNavigation</code> is defined:</p> - -<pre class="brush: xml"><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> -</pre> - -<p>This code is invoked whenever JavaScript code in Firefox accesses <code>browser.webNavigation</code>, where <code>browser</code> is some <code><browser></code> element. It checks if the result has already been cached in the <code>browser._webNavigation</code> field. If it hasn’t been cached, then it fetches the navigation object based off the browser’s <em>docshell</em>. 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 <code>webNavigation</code> accessor runs in the parent process, <code>this.docShell</code> above will just return null. As a consequence, this code will fail completely.</p> - -<p>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 <code><browser></code> elements. It is called <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/remote-browser.xml?rev=9583bd3099ae"><code>remote-browser.xml</code></a>, and it extends the existing <code>browser.xml</code> binding.</p> - -<p>The <code>remote-browser.xml</code> binding returns a JavaScript <em>shim object</em> whenever anyone uses <code>browser.webNavigation</code> or other similar objects. The shim object is implemented <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/modules/RemoteWebNavigation.jsm">in its own JavaScript module</a>. It uses the message manager to send messages like <code>"WebNavigation:LoadURI"</code> to <a href="http://mxr.mozilla.org/mozilla-central/source/toolkit/content/browser-child.js?rev=9583bd3099ae#107">a content script loaded by <code>remote-browser.xml</code></a>. The content script performs the actual action.</p> - -<p>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.</p> - -<h2 id="Cross-process_object_wrappers"><strong id="cpows">Cross-process object wrappers</strong></h2> - -<p>The message manager API does not allow the parent process to call <code>sendSyncMessage</code>; 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 <code>sendAsyncMessage</code> 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.</p> - -<p>These objects are called cross-process object wrappers, frequently abbreviated to CPOWs. They’re created using the message manager. Consider this example content script:</p> - -<pre class="brush: js">addEventListener("load", function (e) { - let doc = content.document; - sendAsyncMessage("GotLoadEvent", <strong>{}, {document: doc}</strong>); -}, false); -</pre> - -<p>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 <code>sendAsyncMessage</code> 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:</p> - -<pre class="brush: js">let mm = Cc["@<span class="skimlinks-unlinked">mozilla.org/globalmessagemanager;1</span>"]. - getService(Ci.nsIMessageListenerManager); - -mm.addMessageListener("GotLoadEvent", function (msg) { - let uri = <strong>msg.objects.document.documentURI</strong>; - dump("Received load event: " + uri + "\n"); -}); -mm.loadFrameScript("chrome://content/<span class="skimlinks-unlinked">content-script.js</span>", true); -</pre> - -<p>It’s important to realize that we’re send object <em>references</em>. The <code>msg.objects.document</code> object is only a wrapper. The access to its <code>documentURI</code> 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.</p> - -<p>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.</p> - -<p>Another problem with CPOWs is that they violate some assumptions people might have about message ordering. Consider this code:</p> - -<pre class="brush: js">mm.addMessageListener("GotLoadEvent", function (msg) { - mm.sendAsyncMessage("ChangeDocumentURI", {newURI: "<span class="skimlinks-unlinked">hello.com</span>"}); - let uri = <strong>msg.objects.document.documentURI</strong>; - dump("Received load event: " + uri + "\n"); -}); -</pre> - -<p>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 <code>uri</code> to come back as <code>"hello.com"</code>. 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 <code>documentURI</code> property will be processed before the <code>"ChangeDocumentURI"</code> message, in which case <code>uri</code> will have some other value.</p> - -<p>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.</p> - -<p>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.</p> - -<p>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.</p> |