4 ms·

I get how a multi-process architecture is good for stability, but why is multi-process necessary for UI responsiveness? Surely the UI is already rendered on its

by 0xffff2 10y ago

I get how a multi-process architecture is good for stability, but why is multi-process necessary for UI responsiveness? Surely the UI is already rendered on its own thread; why would moving that thread to a separate process help anything?

fl0wenol 10y ago
Firefox has a UI that is rendered in web components and javascript just like the displayed pages in the tabs. This technology is called XUL. The Gecko layout engine renders both XUL and HTML styled with CSS. Traditionally this was all handled in one process. The tabs themselves are like fancier iframes. If javascript in a window did not yield, stuck in a tight loop, it could make the interactive elements of the UI non-responsive (menus, modal dialogs, right-click menu, etc.) To combat this, Firefox has a global timer in the whole-browser javascript that fires and interrupts long-running javascript to display that dialog box that says: "A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete." You might have even run into it. This lets you kill it which gives you the UI back, but may break the offending webpage. By making firefox multi-process, this hack is no longer needed. Also you can imagine that for a very javascript heavy web application like Google Docs, Slack, or Gmail, it fires so many JS events and runs so much code that when the tab is active on slower systems you find Firefox's own UI is lagging. This is because the web application is always doing something or doing it too frequently and Firefox is having a hard time getting a word in edgewise. Such heavy interactive pages will no longer negatively impact the browser, especially on multi-core systems.
bzbarsky 10y ago
Without e10s, the UI is in fact not rendered on its own thread. There was a lot of discussion about whether to try to move the UI to a separate thread or separate process, and the decision was that separate process has a _much_ lower risk of bugs due to racing memory accesses and whatnot. Basically, it removes a bunch of ways that you could accidentally shoot yourself in the foot while trying to retrofit threading onto a large existing C++ codebase....

by 0xffff2 10y ago

fl0wenol 10y ago

Firefox has a UI that is rendered in web components and javascript just like the displayed pages in the tabs. This technology is called XUL. The Gecko layout engine renders both XUL and HTML styled with CSS. Traditionally this was all handled in one process. The tabs themselves are like fancier iframes. If javascript in a window did not yield, stuck in a tight loop, it could make the interactive elements of the UI non-responsive (menus, modal dialogs, right-click menu, etc.) To combat this, Firefox has a global timer in the whole-browser javascript that fires and interrupts long-running javascript to display that dialog box that says: "A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete." You might have even run into it. This lets you kill it which gives you the UI back, but may break the offending webpage. By making firefox multi-process, this hack is no longer needed. Also you can imagine that for a very javascript heavy web application like Google Docs, Slack, or Gmail, it fires so many JS events and runs so much code that when the tab is active on slower systems you find Firefox's own UI is lagging. This is because the web application is always doing something or doing it too frequently and Firefox is having a hard time getting a word in edgewise. Such heavy interactive pages will no longer negatively impact the browser, especially on multi-core systems.

bzbarsky 10y ago

Without e10s, the UI is in fact not rendered on its own thread. There was a lot of discussion about whether to try to move the UI to a separate thread or separate process, and the decision was that separate process has a _much_ lower risk of bugs due to racing memory accesses and whatnot. Basically, it removes a bunch of ways that you could accidentally shoot yourself in the foot while trying to retrofit threading onto a large existing C++ codebase....