diff options
Diffstat (limited to 'files/pt-br/mozilla/firefox/multiprocess_firefox')
3 files changed, 178 insertions, 0 deletions
diff --git a/files/pt-br/mozilla/firefox/multiprocess_firefox/index.html b/files/pt-br/mozilla/firefox/multiprocess_firefox/index.html new file mode 100644 index 0000000000..2dd2134e60 --- /dev/null +++ b/files/pt-br/mozilla/firefox/multiprocess_firefox/index.html @@ -0,0 +1,75 @@ +--- +title: Multiprocess Firefox +slug: Mozilla/Firefox/Multiprocess_Firefox +tags: + - Português (do Brasil) tags +translation_of: Mozilla/Firefox/Multiprocess_Firefox +--- +<div>{{FirefoxSidebar}}</div><p>In current versions of desktop Firefox, the entire browser runs in a single operating system process. In particular, the JavaScript that runs the browser UI (also known as "chrome code") runs in the same process as the code in web pages (also known as "content" or "web content").<br> + <br> + Future versions of Firefox will run the browser UI in a separate process from web content. In the first iteration of this architecture all browser tabs will run in the same process, and the browser UI will run in a different process. In future iterations, we expect every browser tab to run in its own process. The project that's delivering multiprocess Firefox is called Electrolysis, sometimes abbreviated to e10s.</p> + +<p>Normal web pages are unaffected by multiprocess Firefox. People working on Firefox itself and Firefox add-on developers will be affected if their code relies on being able to access web content directly.</p> + +<p>Instead of accessing content directly, chrome JavaScript will have to use the <a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">message manager</a> to access content. To help ease the transition we've implemented <a href="/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers">Cross Process Object Wrappers</a> and some <a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#Compatibility_shims">compatibility shims for add-on developers</a>. If you're an add-on developer wondering whether you are affected, see the <a href="/en-US/Add-ons/Working_with_multiprocess_Firefox">guide to working with multiprocess Firefox</a>.</p> + +<p>Multiprocess Firefox is currently enabled by default in <a class="external external-icon" href="https://nightly.mozilla.org/">Nightly</a> builds. As a visual indicator that you're running multiprocess Firefox, the titles of remote tabs are underlined.</p> + +<hr> +<div class="column-container"> +<div class="column-half"> +<dl> + <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Technical_overview">Technical overview</a></dt> + <dd>A very high-level view of how multiprocess Firefox is implemented.</dd> + <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Glossary">Glossary</a></dt> + <dd>A reference for the jargon used in multiprocess Firefox.</dd> + <dt><a href="/en-US/Firefox/Multiprocess_Firefox/The_message_manager">The message manager</a></dt> + <dd>How to communicate between chrome and content.</dd> + <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Message_Manager_Interfaces">Message Manager interfaces</a></dt> + <dd>Includes links to the API reference for the message manager interfaces.</dd> + <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Frame_script_environment">Frame script environment</a></dt> + <dd>The environment frame scripts run in, and especially how it differs from the environment for chrome code.</dd> +</dl> +</div> + +<div class="column-half"> +<dl> + <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Motivation">Motivation</a></dt> + <dd>Why we're implementing multiprocess Firefox: performance, security, and stability.</dd> + <dt><a href="/en-US/Add-ons/Working_with_multiprocess_Firefox">Add-on migration guide</a></dt> + <dd>If you're an add-on developer, find out if you're affected and how to update your code.</dd> + <dt><a href="/en-US/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="/en-US/Firefox/Multiprocess_Firefox/Debugging_frame_scripts">Debugging frame scripts</a></dt> + <dd>Using the Browser Content Toolbox to debug frame scripts.</dd> +</dl> +</div> +</div> + +<hr> +<div class="column-container"> +<div class="column-half"> +<dl> + <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts">Limitations of chrome scripts</a></dt> + <dd>Practices that will no longer work in chrome code, and how to fix them.</dd> +</dl> +</div> + +<div class="column-half"> +<dl> + <dt><a href="/en-US/Firefox/Multiprocess_Firefox/Limitations_of_frame_scripts">Limitations of frame scripts</a></dt> + <dd>Practices that will not work inside frame scripts, and what to do instead.</dd> +</dl> +</div> +</div> + +<hr> +<h2 id="Contact_us">Contact us</h2> + +<p>Find out more about the project, get involved, or ask us your questions.</p> + +<ul> + <li><strong>Electrolysis project page</strong>: <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>Mailing list</strong>: <a href="https://groups.google.com/forum/#!forum/mozilla.dev.tech.electrolysis">dev.tech.electrolysis</a></li> +</ul> diff --git a/files/pt-br/mozilla/firefox/multiprocess_firefox/motivacao/index.html b/files/pt-br/mozilla/firefox/multiprocess_firefox/motivacao/index.html new file mode 100644 index 0000000000..8b3745c16c --- /dev/null +++ b/files/pt-br/mozilla/firefox/multiprocess_firefox/motivacao/index.html @@ -0,0 +1,44 @@ +--- +title: Motivação para o Multiprocesso do Firefox +slug: Mozilla/Firefox/Multiprocess_Firefox/Motivacao +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Motivation +--- +<div>{{FirefoxSidebar}}</div><p>Existem três principais razões para fazer o Firefox executar conteúdo em processos separados: desempenho, segurança e estabilidade.</p> + +<h2 id="Performance">Performance</h2> + +<p>A maioria dos trabalhos de performances na Mozilla nos últimos dois anos tem se concentrado na capacidade de resposta do navegador. O objetivo é reduzir "<a href="/en-US/docs/Glossary/Jank"> jank</a>" - esses momentos em que o navegador parece congelar brevemente ao carregar uma página grande, digitando uma forma, Ou rolagem. A capacidade de resposta tende a importar muito mais do que o rendimento na web hoje. Grande parte deste trabalho foi feito como parte do <a href="https://wiki.mozilla.org/Performance/Snappy"> projeto Snappy</a>. Os principais focos foram:</p> + +<ul> + <li>Moving long-running actions to a separate thread so that the main thread can continue to respond to the user.</li> + <li>Doing I/O asynchronously or on other threads so that the main thread isn’t blocked waiting for the disk.</li> + <li>Breaking long-running code into shorter pieces and running the event loop in between. Incremental garbage collection is an example of this.</li> +</ul> + +<p>Much of the low-hanging fruit in these areas has already been picked. The remaining issues are difficult to fix. For example, JavaScript execution and layout happen on the main thread, and they block the event loop. Running these components on a separate thread is difficult because they access data, like the DOM, that are not thread-safe. As an alternative, we’ve considered allowing the event loop to run in the middle of JavaScript execution, but doing so would break a lot of assumptions made by other parts of Firefox (not to mention add-ons).</p> + +<p>Running web content in a separate process is a nice alternative to these approaches. Like the threaded approach, Firefox is able to run its event loop while JavaScript and layout are running in a content process. But unlike threading, the UI code has no access to content DOM or or other content data structures, so there is no need for locking or thread-safety. The downside, of course, is that any code in the Firefox UI process that needs to access content data must do so explicitly through message passing.</p> + +<p>We feel this tradeoff makes sense for a few reasons:</p> + +<ul> + <li>It’s not all that common for Firefox code to access content DOM.</li> + <li>Code that is shared with Firefox OS already uses message passing.</li> + <li>In the multiprocess model, Firefox code that fails to use message passing to access content will fail in an obvious, consistent way. In the threaded model, code that accesses content without proper locking will fail in subtle ways that are difficult to debug.</li> +</ul> + +<h2 id="Security">Security</h2> + +<p>Right now, if someone discovers an exploitable bug in Firefox, they’re able to take over users’ computers. There are a lot of techniques to mitigate this problem, but one of the most powerful is <a href="http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29">sandboxing</a>. Technically, sandboxing doesn’t require multiple processes. However, a sandbox that covered single-process Firefox wouldn’t be very useful. Sandboxes are only able to prevent processes from performing actions that a well-behaved process would never do. Unfortunately, a well-behaved Firefox process (especially one with add-ons installed) needs access to much of the network and file system. Consequently, a sandbox for single-process Firefox couldn’t restrict much.</p> + +<p>In multiprocess Firefox, content processes will be sandboxed. A well-behaved content process won’t access the filesystem directly; it will have to ask the main process to perform the request. At that time, the main process can verify that the request is safe and that it makes sense. Consequently, the sandbox for content processes can be quite restrictive. Our hope is that this arrangement will make it much harder to craft exploitable security holes for Firefox.</p> + +<h2 id="Stability">Stability</h2> + +<p>Currently, a crash in the code running a web page will take down the entire browser. With multiprocess Firefox, only the content process that crashed will be killed.</p> + +<div class="note"> +<p>This page incorporates a lot of content from Bill McCloskey's blog post on multiprocess Firefox: <a href="http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/">http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/</a></p> +</div> + +<p> </p> diff --git a/files/pt-br/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html b/files/pt-br/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html new file mode 100644 index 0000000000..708c6b49f0 --- /dev/null +++ b/files/pt-br/mozilla/firefox/multiprocess_firefox/which_uris_load_where/index.html @@ -0,0 +1,59 @@ +--- +title: Aonde cada URI carrega +slug: Mozilla/Firefox/Multiprocess_Firefox/Which_URIs_load_where +translation_of: Mozilla/Firefox/Multiprocess_Firefox/Which_URIs_load_where +--- +<div>{{FirefoxSidebar}}</div><p>Com base inicialmente no esquema URI da página, o navegador pode decidir se carregar uma página no processo chrome ou um processo de conteúdo. Para alguns esquemas, você pode alterar o comportamento padrão.</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>Por padrão, as páginas <code> about: </code> são sempre carregadas no processo chrome. No entanto, quando você registra uma nova página <code> about:</code> você pode alterar esse padrão.</p> + + <p>Duas novas flags são definidas em <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>: A página será carregada no mesmo processo que carregou o <code> <a href="pt-BR/docs/Mozilla/Tech/XUL/Navegador"> navegador</a></code>.</li> + <li><code>URI_MUST_LOAD_IN_CHILD</code>: A página sempre será carregada em um processo filho.</li> + </ul> + + <p>Para usar um destes flags, retorne em sua implementação o <code>getURIFlags</code> no <a href="/en-US/docs/Custom_about:_URLs">código que registra o <code>about:</code> URI</a>.</p> + + <p>Se você usar essas flags, você deve registrar a página sobre um framescript para cada guia. Se você não configurar o multiprocesso Compatível com o verdadeiro no seu <code>install.rdf</code>, então serão usados os padrões. Mas os padrões dos e10s serão obsoletos em breve. Leia mais aqui - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1257201">Erro 1257201</a>.</p> + </td> + </tr> + <tr> + <td><code>chrome:</code></td> + <td> + <p>Por padrão, as páginas <code>chrome:</code> são sempre carregadas no processo chrome. No entanto, quando você registra uma nova página <code>chrome</code>, você pode alterar esse padrão.</p> + + <p>Duas novas flags são definidas no <a href="/en-US/docs/Chrome Registration">file chrome.manifest</a>:</p> + + <ul> + <li>remoteenabled: a página será carregada no mesmo processo que carregou o<code> <a href="pt-BR/docs/Mozilla/Tech/XUL/Navegador"> navegador</a></code>.</li> + <li>remoterequired: a página sempre será carregada em um processo filho.</li> + </ul> + </td> + </tr> + <tr> + <td><code>file:</code></td> + <td> + <p>Sempre carregado em um processo de conteúdo.</p> + + <p><strong>Nota:</strong> Isso não significa que o <code>file:</code> URIs podem ser usado livremente em código de processos de conteúdo. O Sandboxing pode incluir listas predefinidas de diretórios particulares e futuras alterações podem restringir os <code>files:</code> URIs a um processo de conteúdo separado, isolado do conteúdo da Web normal. Veja <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1187099">bug 1187099 </a> como isso pode afetar os addons tentando carregar arquivos no diretório do perfil.</p> + </td> + </tr> + <tr> + <td><code>resource:</code></td> + <td>Sempre carregado em um processo de conteúdo.</td> + </tr> + </tbody> +</table> |