It has taken far too long for e10s.
Multiprocess Firefox
121–126 of 126 posts
Re: Multiprocess Firefox
#122Lets look at the reasons given as to why they want to do this.
>Performance. Most performance work at Mozilla over the last two years has focused on responsiveness of the browser. The goal is to reduce "jank"—those times when the browser seems to briefly freeze when loading a big page, typing in a form, or scrolling.
You can do all of this with proper threading and task delegation. Putting things in separate processes will not magically make things better. The answer to "jank" is proper coding, not over engineering. Last time I checked there was the same "jank" in IE and Chrome even though they use MPs.
>Security. Technically, sandboxing doesn’t require multiple processes. However, a sandbox that covered the current (single) Firefox process 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.
This is BS. You could have three processes and have FireFox sandboxed completely. Main process runs in a low integrity mode which limits it's resource access to a single directory. Second process is a download delegation process (takes a file after it is downloaded and moves it to the requested location while also promoting it's integrity) running in normal integrity mode. Third process is a network communication delegate/proxy running in normal or possibly even low integrity. These two delegate processes I mentioned will still be needed for the MP Firefox so it is no more work to create them.
>Stability
This is the only true benefit, but it is of very little value. Firefox almost never crashes and when it does, the session restore brings you back to were you left off in seconds.
Cons? More complexity means more bugs. This is a workaround for really fixing FireFox. I am going to have 150+ extra processes in my task manager now. More memory use. More context switches in the operating system eating up resources and causing more system latency and overall slowdown (context switches at the kernel level which will affect the whole OS).
Re: Multiprocess Firefox
#123To try Electrolysis (multiprocess) in Firefox Nightly: in about:config, toggle the browser.tabs.remote pref and restart (still work-in-progress, don't expect a fully working browser). Edit: you will lose your current session
Re: Multiprocess Firefox
#124Earlier quoted context omitted.
Hahaha, you and me and about 1% of the browser users (well on HN, probably more like 10%) have particular habits of keeping much larger numbers of tabs open than everyone else. Have you imagined an alternate scheme to tabs, where there are 100s of thousands of potential "tabs" which can be organized, called up in groups, moved in clumps together, and shared? Imagine each group of tabs like soldiers in a Command and C…
I also keep a lot of tabs open, that's why I'm using Firefox and not Chrome. Firefox is very memory-efficient recently, whereas Chrome is a memory hog and can't handle the number of tabs I keep open in Firefox. Firefox also does a neat thing with tabs that have been opened and not used in a long time, effectively unloading the website and reloading it once you visit the tab (for some reason it doesn't do so with tabs…
Just bring up the menu bar (or hit Alt), then go to File -> Exit, which should close all Firefox windows but save the current tab history. Then, simply restart Firefox, again go back to the menu, then do History -> Restore Previous Session.
Besides the few tabs that get auto-loaded (i.e. the ones you were viewing in each window), the remaining tabs should remain un-loaded until you manually re-visit that tab (at which point the page will be redownloaded or loaded from cache into RAM).
Re: Multiprocess Firefox
#125> All IPC happens using the Chromium IPC libraries Interesting that they chose to share code with Chrome. Since the two are competitors, I would have thought that they'd use completely separate implementations. It's interesting that open source makes this sharing possible.
Re: Multiprocess Firefox
#126This is a terrible idea. There is no justifiable reason to do this. The reasons given are weak, this is just more over engineering that will add an enormous amount of complexity and add no real value. Lets look at the reasons given as to why they want to do this. > Performance. Most performance work at Mozilla over the last two years has focused on responsiveness of the browser. The goal is to reduce "jank"—those tim…