Hacker News Reader

Comment by TekMol | Hacker News Reader

    we’ll be rolling out the first stage of Electrolysis to
    100% of Firefox desktop users over the next few months.

From my experiments with it, this still does not fix the problem that the javascript in all windows shares one core. A script running in one browser window still slows down the other windows.

A problem that Chrome has solved years ago. So I think this is not really a leap for the web. Just FireFox catching up a bit.

FireFox is my main browser. The way I deal with it is that I start multiple instances as different users. So they run inside their own process. This way I can have a resource hungry page open in one window (For example a dashboard with realtime data visualization) and still work smoothly in another.

View on HN

> So I think this is not really a leap for the web. Just FireFox catching up a bit.

To be clear, Project Quantum is the next phase of architecture, post-Electrolysis. We're also simultaneously working on multiple content processes (which is how Chrome often avoids inter-window jank), but not under the Quantum umbrella.

We think we can do better though, which is where Quantum comes in. The Quantum DOM project is designed to solve exactly the problem you're describing, while using fewer resources and scaling to more tabs. Stay tuned!

This sounds like it directly conflicts with sandboxing tabs, either for security or stability. Am I missing something?

Mozilla engineer Bill McCloskey describes how Quantum DOM will use both multiple OS processes and cooperatively-scheduled, user-space threads to preempt and throttle iframes and background tabs:

https://billmccloskey.wordpress.com/2016/10/27/mozillas-quan...

> this still does not fix the problem that the javascript in all windows shares one core

Yes, that's what makes it the "first stage".

The "leap" part is not Electrolysis; as you note that's just table stakes. The "leap" part is what we can work on now that the Electrolysis first stage, which was very labor-intensive, is done.

Servo has a solution for that: it runs all origins in separate threads. (Note that this goes further than Chrome does; Servo runs cross origin iframes off the main thread too, while Chrome does not.)

Gecko is solving this too, with Electrolysis and Quantum DOM. But because the architectures are so different at the DOM level (direct bindings vs. an XPCOM/direct binding hybrid, tracing vs. reference counting, off main thread layout vs. main thread layout, Rust serialization vs. IPDL, etc.) the Servo solution doesn't directly apply to Gecko. So Gecko and Servo are working on their own solutions mostly independently, rather than sharing code as in most of Quantum.

Parts of Quantum are addressing this, and also Electrolysis will also probably grow to fix this as well. You can already turn on multiple content processes in Firefox to get Chrome-like behavior (at the cost of some rough edges; there's a reason it's not currently the default). I think the setting is dom.ipc.process-count in about:config. I have mine set at 10.

Yes, I heard about it. For now, I disabled Electrolysis completely again, because I had pages freeze sometimes when I had it on. Maybe because it is incompatible with some plugin I use. My current solution to tun multiple instances as different users works best for me so far.

> A problem that Chrome has solved years ago.

The trade-off is the crazy amount of resources Chrome uses,even on a multicore machine. 20 process spawned and shit like this can bring down any computer. Chrome resource usage is excessive.

You can alleviate this problem by increasing dom.min_background_timeout_value.

Reply on news.ycombinator.com