That said, memory usage isn't my biggest concern, I generally have no shortage of memory, and don't particularly care if my browser is using 1GB of RAM. If this improves stability and performance (which seems to have gotten much worse recently on OS X in particular), then it's a fair trade off.
How do people get work done WITHOUT having 50 tabs open? It's a pretty regular occurrence for me, between having MSDN, the PostgreSQL handbook, documentation for a half dozen libraries, my "read later" list, etc., there's almost never a day I am not drowning in tabs. Thankfully, the Tree-Style Tabs extension saves the day here!
Basically, beforehand when you turned your scroll wheel, Firefox first sent a scroll event to the webpage, then the webpage could execute whatever it needed to execute on scroll, and then Firefox actually scrolled the page. With APZ, that's now handled in parallel, i.e. it already scrolls what's there and alters it at the same time with whatever the webpage wants to do on scroll.
This also applies for zooming the page, as you might have guessed from the name, and as far as I can tell also to resizing the window.
Other than that, all animations in the browser UI are a lot smoother, too. For example, I can now just hold down Ctrl+T (which opens new tabs) and it happily chugs through playing the tab-animation hundreds of times with seemingly the only limiting factor being my screen's refresh rate. (And that's on a below-average laptop.)
They also go on to say that "After that, we’ll be working on support for multiple content processes.", so I assume the plan is to have one perocess-per-tab eventually. I'm surprised they aren't there already though, considering this has been in the works for a few years now.
As for process-per-tab, I can't find anything official about it on the bug tracker. The problem with that option is it leads to quite high memory usage, and hides the existence of memory leaks (chrome really likes to eat my ram). We'll have to see how memory usage goes as they experiment with multiple content processes.
source: https://www.reddit.com/r/firefox/comments/4hmii4/firefoxs_ap...
They're first going to do two processes, probably for debugging without too many moving parts, then multiprocess. See https://wiki.mozilla.org/Electrolysis#Schedule_and_Status and https://wiki.mozilla.org/Electrolysis/Multiple_content_proce....
According to the wiki page you linked, it doesn't seem to be the goal for them:
"The (practically) unlimited process count is on some platforms not a realistic goal, and having a separate process for each open site instances or even sites does not seem like a reachable goal (for now at least). Which means using content processes as a security membrane cannot be a goal either."
If this is true, I don't see any advantages of e10s introduction.
It is a breeze. http://kb.mozillazine.org/Browser.sessionhistory.max_total_v...
https://it.slashdot.org/story/16/02/12/034206/pwn2own-2016-w...
Chrome is at best visible source – Google controls development, not the community – and the others are even fully proprietary
Great fucking world.
Which is hard to do when Google competes unfairly, even illegally – which they did, for example with using AdSense for Chrome ads everywhere, and not paying website owners where the ads were displayed the normal rates, or by adding fraudulent banners "Your browser (Firefox) is outdated, upgrade to Chrome now" to Google Search.
You could say that without many users, there won't enough real-world exposure, but at the same time, Firefox will also be targeted far less, so you wouldn't have to worry about security vulnerabilities as much.
And while yes, if at some point Chrome becomes Internet Explorer 2.0 and webpages target nothing else anymore, that could cause Firefox to be hardly usable, but that's then an entirely different nightmare and not anymore relevant to the current situation.
With no devs, you can’t implement those features or the security easily.
And especially for security you’ll want fulltime employees.
Also, you’ll have to pay more than Google pays their Chrome devs to ensure the people will keep working for you.
But maintaining a whole OS with a whole virtualization layer, a whole sandbox system, several supported scripting systems, its own scheduler, its own graphics stack, and support for compatibility with any bug a competing system has?
Modern browser are reaching complexities we’ve only seen in whole operating systems before. You don’t see a bunch of volunteers maintain everything from Linux to KDE at once, it’s hundredthousands of people working in a very different way.
To be able to compete against Google, be able to force them to implement features you pioneer, and force them to avoid implementing other features, to be able to keep up with them and reach better security than them, the current Firefox team is not enough.
Chromium is open source, Chrome is open core. Chromium may also be cathedral (rather thean bazaar) development model, but that's only distantly related to open source or not (bazaar is facilitated by open source, but not required for it.)
Google even openly discourages forks, or any contribution that doesn’t fit their ideals.
It’s only truly open if development is controlled by a democratic community, or if it’s easily possible to be forked and competed with.
Which isn’t the case.
And for users open development is a lot more important than open source: Being able to get their own changes into the browser, ensuring the browser is made by the users, for the users.
Google may discourage forks, but there's nothing they can do to prevent one, and forking Chromium is no more difficult than forking any other project its size.
... or any contribution that doesn’t fit their ideals.
That's one of an OSS project maintainer's more important jobs. I used to maintain some decent-sized open source projects, and part of my job was to say "no" when someone wanted to add something I didn't think belonged (for whatever reason).
Forking Chrome would be like fighting against Embrace, Extend, Extinguish after you’ve already lost (which we have with Chrome, compared to what KHTML used to be like)
Regardless, though, there's nothing that says the hypothetical developers of a Chromium fork couldn't devote some time to merging reasonable fixes & new features from upstream.
https://it.slashdot.org/comments.pl?sid=8737473&cid=51495357
No major changes means that there will also likely not be any new security vulnerabilities and therefore they would almost certainly not find anything new.
This does not mean that Firefox is less secure, it just means that Mozilla has not innovated much. And if you look at actual statistics, you'll see that Firefox is not behind at all.
You could maybe make a separate case that this will lead to bad security in the future, as some innovation is inevitably going to be necessary, but with addon signing, E10s, WebExtensions and Servo all up and coming, you'll have a hard time to actually defend that case.