Live data from Hacker News

Multiprocess Firefox

billmccloskey.wordpress.com

81–90 of 126 posts

Re: Multiprocess Firefox

#81

> 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.

If someone's already written a perfectly good solution that's readily available you either - pridefully write your own - use theirs

it took a bit of time for me to take serious pride in using other people's work. it's been so much easier to deliver anything since then.

Re: Multiprocess Firefox

#82

> 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.

Mozilla is nearly entirely financed by Google, there isn't a sense of hate between the two organizations.

Re: Multiprocess Firefox

#83

Earlier quoted context omitted.

I'm curious, why does pride come into the equation?

If the existing implementation is perfectly good , writing your own is either pride, stupidity, or a learning exercise. I would take for granted that the Firefox developers aren't stupid, and that they have enough interesting work to do that they aren't going to spend time on it as a learning exercise.

Ah, okay. That feels a hyperbolic to be pride or stupidity, rather than just a poor analysis of the efficacy of an existing solution. Thank you for your response.

Re: Multiprocess Firefox

#84
Testing it out now, so far so good! I might make this my default profile, I would love not having rogue tabs freeze the entire system. It's very nearly my one remaining thing I prefer Chrome for, Firefox has really improved lately.

Re: Multiprocess Firefox

#85
post #56

Earlier quoted context omitted.

I'll admit I wasn't a fan of process-per-tab originally either. However, since ever browser leaks memory, the ability to close some windows and reclaim the memory that was lost has been very useful to me (I tend to have 50+ tabs open at most times, and for many days at a time). That being said, I'd also be ok with process-per-window, as that would give me the same basic ability.

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 tried solving this problem a while back - using a task based approach - where you create a meta-tab for a logical task and organize tabs under it. You can close, open, suspend, archive tasks. History, bookmarks and other browsing artifacts are associated with tasks. Sadly I couldn't take it beyond prototyping. I have made multiple attempts to - but failed.

* [A task based web browser - Conquering information overload](http://www.slideshare.net/mohanrajrm/a-taskfocused-approach-...)

* [A task-focused approach to support sharing and interruption recovery in web browsers](http://vimeo.com/9088447)

I am still waiting for a plugin which allows me to impose a efficient low-cost organisation layer over tabs (have made multiple feeble attempts to do a plugin which helps organize tabs using mind-maps, a org structure that is my personal favorite). I have tried almost all plugins over the years which could potentially solve this for me - but have not been successful in finding one that fits my needs.

Re: Multiprocess Firefox

#86

Earlier quoted context omitted.

Yet (P)NaCl can go to hell. Brendan pls. (I am aware that a fully sandboxed JIT is more complex to integrate than an IPC library)

The difference here is that we wanted to implement a multiprocess architecture. We don't want to implement (P)NaCl, since we don't think they're good for the web. We have no qualms with integrating code from other sources, we've done a lot of it. (Google Breakpad, WebRTC, numerous image and video decoding libraries, Freetype, libffi, ANGLE, the list goes on...)

As a further observation on this, Robert O'Callahan has a blog post [1] explaining Mozilla's stance on (not) implementing bad-for-the-web features; as an example to show this stance is long-lived, he mentions that engineers at Netscape/Mozilla implemented (in 1999) ActiveX support for Gecko, but kept it disabled by default on purpose despite a possible market share impact.

[1] http://robert.ocallahan.org/2010/01/activex-all-over-again_2...

Re: Multiprocess Firefox

#87

If you'd like to try this out on Windows without affecting your main Firefox profile, we just released portable packages of the Firefox Nightly and Aurora builds at PortableApps.com yesterday: http://portableapps.com/news/2013-12-04--firefox-aurora-27-a... They run self-contained in their own directory so you can quickly extract them to your Desktop or portable device. The installer downloads the latest build as you…

Works like a charm.

Re: Multiprocess Firefox

#88

> 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.

> 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.

That's what open source is about: collaboration instead competition. Why compete when you can pool your resources together.

Re: Multiprocess Firefox

#89
post #23

For those of you interested in parallelism in browsers, I suggest you keep an eye on Mozilla's experimental new browser engine, Servo.[1] The goal is to make use of a variety of concurrency strategies (such as a Chrome-esque process-per-tab design[2]) and Rust's built-in support for memory-safe concurrency abstractions (fork/join, lightweight tasks, SIMD, etc.) to produce a ludicrously parallel[3] web browser. And ev…

They did a talk about parallel rendering 4 months ago : https://air.mozilla.org/2013-intern-presentations-august-13/

Re: Multiprocess Firefox

#90
What about IPC embedding API? It already separates the UI from the heavy Gecko processing: https://wiki.mozilla.org/Embedding/IPCLiteAPI

I just hope Mozilla won't go extreme, and won't use a separate process for each tab like Chrome does. It produces memory bloat if you have many tabs open. While they say they'll mitigate memory issues, this should be balanced.

Post reply on HN