Update on Multi-Process Firefox

about:support shows you if multi-process is enabled " Multiprocess Windows".

i.e. Multiprocess Windows 1/1 (Enabled by default)

The two most notable are 1password and Self Destructing Cookies

If you're only using a few extensions (not parent), this could work very well for you.

So I'm happy with this progress even though it may seem slow to some people or that Firefox isn't keeping up with Chrome (the latter is meaningless for my use since Firefox and its extensions provide a lot more).

But in general I share your observation - runs very smooth.

Also multiprocess Firefox seems to struggle in GUI perf, it's jerky. Old firefox may be slow but it was a bit predictable. Here less.

But yeah, I'd love to see vimperator or pentadactyl supporting this, and no, I neither have the time nor the skillset to fix it myself.

If you are on an old version, check for the string "Multiprocess staged rollout". If it is true, you do have e10s enabled.

And for checking extension compatibility install this extension, https://addons.mozilla.org/en-US/firefox/addon/add-on-compat...

(you have to search the extension you want)

More seriously—it's somewhat sad to see Chrome get all the credit for this, when it's undoubtedly the case that both IE and Chrome were working on this at the same time.

(Disclaimer: user of Chromium,Chrome,FF,Midori,K-Meleon,various Operae,IE and "not-IE-whatever-it's-called",elinks and other stuff)

It's always been incredibly hackable, in the classic sense. That ability and the legacy of tools built on top of firefox was an important feature that they have largely maintained.

Chrome not only didn't have a legacy but still may break things for developers and sometimes just shrug off their complaints. It's a powerful browser, but it's focused on the needs of the parent company.

One process per tab since forever. (Well, more like one process per window, because there weren't tabs at first).

It was started, then put on hold for a couple of years because it seemed insurmountable, and then started again. It's taken a huge amount of work, and thus a huge amount of time. But it's mostly done now and the benefits are reaching users.

Trying to overhaul the entire architecture of a browser with a huge extension ecosystem (and over a decade's worth of baggage associated with that) is hard.

We need competition or we will suffer as end users.

Chrome's time will also come eventually. It's not a matter of if, but when. Vivaldi and Brave are growing and coming along very nicely. Brave is actually spearheaded by the ex CEO of Mozilla before he was fired for some nonsense.

https://brave.com/

I also just found this bit, that explains how some browsers might be over or under estimated, because of how their internals work[2]. So we really don't know what the market shares really are.

[0]http://gs.statcounter.com/#browser-ww-yearly-2008-2016

[1]https://www.w3counter.com/globalstats.php

[2]https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Ac...

I think Mozilla employees choose to continue working on Firefox for similar reasons, though with more idealism: they have an interest in the browser market not being dominated by commercial vendors.

Second, Mozilla is a non-profit, so the incentives are different that the usual ones. Basically Mozilla wants to help the open web. A 13.5% browser can do that in many ways: drive new standards, provide an alternative to browsers from profit-driven corporations, provide an alternative implementation so the web doesn't end up as a monoculture, etc. etc.

[1] http://gs.statcounter.com/

DDJ: You're well known for writing very good reference implementations for SGML and XML Standards. How important is it for these reference implementations to be good implementations as opposed to just something that works?

JC: Having a reference implementation that's too good can actually be a negative in some ways.

DDJ: Why is that?

JC: Well, because it discourages other people from implementing it. If you've got a standard, and you have only one real implementation, then you might as well not have bothered having a standard. You could have just defined the language by its implementation. The point of standards is that you can have multiple implementations, and they can all interoperate.

You want to make the standard sufficiently easy to implement so that it's not so much work to do an implementation that people are discouraged by the presence of a good reference implementation from doing their own implementation.

DDJ: Is that necessarily a bad thing? If you have a single implementation that's good enough so that other people don't feel like they have to write another implementation, don't you achieve what you want with a standard in that all implementations — in this case, there's only one of them — work the same?

JC: For any standard that's really useful, there are different kinds of usage scenarios and different classes of users, and you can't have one implementation that fits all. Take SGML, for example. Sometimes you want a really heavy-weight implementation that does validation and provides lots of information about a document. Sometimes you'd like a much lighter weight implementation that just runs as fast as possible, doesn't validate, and doesn't provide much information about a document apart from elements and attributes and data. But because it's so much work to write an SGML parser, you end up having one SGML parser that supports everything needed for a huge variety of applications, which makes it a lot more complicated. It would be much nicer if you had one SGML parser that is perfect for this application, and another SGML parser that is perfect for this other application. To make that possible, the standard has to be sufficiently simple that it makes sense to have multiple implementations.

[1] http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-o...