Live data from Hacker News

Multiprocess Firefox

billmccloskey.wordpress.com

121–126 of 126 posts

Re: Multiprocess Firefox

#122
This 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 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

#123

To 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

I tried it, sadly FF nightly crashed completely (not just a tab) every about 30 seconds with just 3 tabs open. The crash recovery dialog sent a log to Mozilla everytime, so they can hopefully fix the bugs soon.

Re: Multiprocess Firefox

#124
post #56

Earlier 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…

As a Firefox user myself, with the same problem of having hundreds of tabs open all the time, I've noticed a neat little trick to "unload" all the tabs from RAM if you need to free some up.

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.

They also share NSS https://en.wikipedia.org/wiki/Network_Security_Services (originally created by Netscape/Mozilla) and, I think, a few other things.

Re: Multiprocess Firefox

#126

This 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…

LOL, I posted this same message on the blog comments and they deleted it. Nothing like censorship to stifle opposing opinions.
Post reply on HN