Esta tradução está incompleta. Por favor, ajude a traduzir este artigo.
Existem três principais razões para fazer o Firefox executar conteúdo em processos separados: desempenho, segurança e estabilidade.
A maioria dos trabalhos de performances na Mozilla nos últimos dois anos tem se concentrado na capacidade de resposta do navegador. O objetivo é reduzir " jank" - esses momentos em que o navegador parece congelar brevemente ao carregar uma página grande, digitando uma forma, Ou rolagem. A capacidade de resposta tende a importar muito mais do que o rendimento na web hoje. Grande parte deste trabalho foi feito como parte do projeto Snappy. Os principais focos foram:
- Moving long-running actions to a separate thread so that the main thread can continue to respond to the user.
- Doing I/O asynchronously or on other threads so that the main thread isn’t blocked waiting for the disk.
- Breaking long-running code into shorter pieces and running the event loop in between. Incremental garbage collection is an example of this.
We feel this tradeoff makes sense for a few reasons:
- It’s not all that common for Firefox code to access content DOM.
- Code that is shared with Firefox OS already uses message passing.
- In the multiprocess model, Firefox code that fails to use message passing to access content will fail in an obvious, consistent way. In the threaded model, code that accesses content without proper locking will fail in subtle ways that are difficult to debug.
Right now, if someone discovers an exploitable bug in Firefox, they’re able to take over users’ computers. There are a lot of techniques to mitigate this problem, but one of the most powerful is sandboxing. Technically, sandboxing doesn’t require multiple processes. However, a sandbox that covered single-process Firefox wouldn’t be very useful. Sandboxes are only able to prevent processes from performing actions that a well-behaved process would never do. Unfortunately, a well-behaved Firefox process (especially one with add-ons installed) needs access to much of the network and file system. Consequently, a sandbox for single-process Firefox couldn’t restrict much.
In multiprocess Firefox, content processes will be sandboxed. A well-behaved content process won’t access the filesystem directly; it will have to ask the main process to perform the request. At that time, the main process can verify that the request is safe and that it makes sense. Consequently, the sandbox for content processes can be quite restrictive. Our hope is that this arrangement will make it much harder to craft exploitable security holes for Firefox.
Currently, a crash in the code running a web page will take down the entire browser. With multiprocess Firefox, only the content process that crashed will be killed.
This page incorporates a lot of content from Bill McCloskey's blog post on multiprocess Firefox: http://billmccloskey.wordpress.com/2013/12/05/multiprocess-firefox/