Firefox 54: E10S-Multi, WebExtension APIs, CSS Clip-Path

At least for my case, I found that Firefox debugger would sometime hang for a bit. It was slowing me down. I'll definitely give it a shot on my next JavaScript heavy project.

The change in that benchmark was from https://bugzilla.mozilla.org/show_bug.cgi?id=1369140, as part of the Quantum Flow (https://wiki.mozilla.org/Quantum/Flow) effort.

That particular benchmark stresses DOM and layout performance, that test just programatically clicks all the delete buttons in the page under test.

There's been a steady march of performance improvements in Spidermonkey, though they haven't gotten very much press. They've been rearchitecting most of the inline caches so there's more sharing between the baseline and optimizing compiler and less in the way of performance cliffs. See https://bugzilla.mozilla.org/show_bug.cgi?id=1259927 and its dependencies (https://bugzilla.mozilla.org/showdependencytree.cgi?id=12599... for the dependency view). Things like https://bugzilla.mozilla.org/show_bug.cgi?id=1328140 led to significant improvements to the sort of megamorphic code you commonly see in frameworks (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1328140#c14 shows 25% improvements on Ember benchmarks).

This work has been ongoing; a bunch of it landed in 53, more in 54, and more has been landing since. What makes it a bit harder to advertise is that it's aiming at reducing performance cliffs and improving the chance that real-life code lands on fast paths, not on improving the performance of those already-fast paths. WebAssembly is where the "make the fast bits faster" action is, mostly.

There is a webextension version of ublock origin. I'm not entirely sure ff 54 supports all the needed APIs.

uBlock0.webext.xpi @ https://github.com/gorhill/uBlock/releases/tag/1.12.4

Edit: I've disabled the addon signing requirement and all seems to be working. Hopefully it gets on the AMO soon.

ublock will work fine with e10s. It's not a webextension yet, but it is e10s compatible already

Yep: https://addons.mozilla.org/en-US/firefox/tag/firefox57

You might want to install the Add-on Compatibility Reporter available from https://addons.mozilla.org/en-US/firefox/addon/add-on-compat...

Try out Firefox 55 (Beta or Developer Edition). It puts a big "Legacy" badge next to each add-on that is not a WebExtension in about:addons.

Car analogies (and generalizations in general) are not so useful.

I've seen many cases (and been frustrated) working in a corporation where high levels of caution end up creating much more total work to make changes incremental. And when you do finish, the code is often not is nice as if it had been all done at once (at which point it probably gets left as is as more important things than refactoring, in the eye of business people, come along).

Chrome is too, they only open the chromium core.

Try Brave then? FOSS, based on Chromium, created by Brendan Eich.

Wow, that is pretty gross, makes me wish chromium was GPL.

I've often read FF is faster, HN is one of the few places I see Chrome being called faster. Maybe it depends heavily on the number of tabs and which sites are loaded? For me FF, whenever I tried switching, was always way slower and prone to freezes. But then I have 32GB Ram, 5 tabs always open (pinned), between 3 to 20 extra tabs at the same time and quite the number of extensions.

I really wish I could agree.

On a core i7 with 16GB and a completely fresh Windows 10 install that has never had Firefox on it (so we can't blame an old profile on the machine), Firefox with a single plugin (Keefox) is noticeably slower than Chrome. Just logging into my Google account I saw surprising amounts of basic UI stuttering. Something like Inbox (which is admittedly a pig) loads slowly and scrolls sluggishly.

Chrome, by comparison, is responsive and snappy.

I wish it were different. I really want to like Firefox, but on this machine, with some very basic tests it's clear that, for me, it simply does not compare...

As far as I'm aware, 57 won't include the XUL API at all, whether behind a config flag or otherwise. I'm not sure how updates from 56 will be handled - one hopes users on the Release channel, who have add-ons the update will break, won't just find themselves hosed by surprise. I haven't heard much of anything about how that actual process will be managed, though.

(Self-Destructing Cookies looks like it could be reimplemented on the WebExtensions API, but the dev doesn't seem to have any interest in doing so. That's a shame, but it doesn't mean no one else will do it.)

I don't blame Mozilla for pulling the trigger this way, though. Opening the roadmap for general community discussion and veto would result in endless bikeshedding, and users unwilling to abandon XUL add-ons in November have the option of sticking with 52 ESR or just not updating past 56 for a while. Conversely, waiting for feature parity with XUL would mean probably another three or so years before e10s hit stable, and Firefox is already three or more years behind in that regard - that much more delay might well not be survivable.

It's not a great situation to be in, but I can't see how Mozilla could've found a better option than the one they chose, and I say that as one who will lose some cherished add-ons in the transition - but if it's that or switch to Chrome because Firefox is too slow to be usable, I'll take the former, and I was strongly contemplating the latter before e10s became a thing. I doubt I was the only one.

I would strongly recommend dumping Firefox and switching to Pale Moon. Pale Moon is everything Firefox should have been.

It's not at all baffling seeing the recent history of firefox dealing with extensions.

Back in the day, when xul extensions were the way to go, things were great, for years the api was reasonably stable.

Then xul extensions were to be replaced by things created by the addon-sdk. To make things more interesting the addon sdk used a python based tool first, later to be replaced by node-js tooling. So (minor)rewrite needed, even though legacy xul extensions still worked as well.. But not for long, noo, for no good reason (because there was already talk of webextensions in firefox), extensions suddenly had to be signed and often MANUALLY reviewed, xul no longer allowed, perfectly fine extensions would not pass automatic review and would not be manually reviewed for no other reason than using legacy code that was hard to review.

So this meant extensions had to be rewritten to use the addon-sdk and jump through hoops to avoid using javascript libraries that caused the automatic review process to break. This all happened a good year ago.

Now, all these addon-sdk extension have to be rewritten once again, because webextensions.

This whole extension review process for addon-sdk, imho, should never have happened and should simply have been postponed till webextensions are ready (they aren't now, they are buggy as hell, yet currently extensions have to be webextensions in order to be published...). As a matter of fact, the whole addon-sdk should never have happened and mozilla should have moved to webextensions immediately.

To me firefox greatest strength was how moddable it was. Not only is this advantage lost by moving to webextensions, the horrid process from xul to addon-sdk to signing and broken review to webextensions must have cost them much goodwill from extension devs. And yes, it has tainted my view on mozilla, i think they honestly mean well, but they desperately need better management that doesn't jump on any hype laden bandwagon, right now they seem to be pushing out new toys that are watered down half functional versions of what used to available. Google might have a name to abandon their projects, i now have the same level of fate in the continuance of any mozilla project.

Agreed, using Firefox without Self Destructing Cookies after all those years would feel like swimming without water. It's going to make the browser way less appealing: having to explicitly logout or clear tracking cookies from any untrusted site (almost all of them) as if that couldn't be automated. Sigh.

Is there a similar extension for any other browser?

Edit: I googled and found https://addons.mozilla.org/en-US/firefox/addon/cookie-autode... which is compatible with FF 57+. Two gotchas: it doesn't work on FF Android yet and it doesn't clear LocalStorage (some issues opened on FF tracker)

I agree.

On the other hand, at least it doesn't take installing an extension, the way it apparently does in Chrome and Opera. (Safari, too? Webkit seems the common thread here.) Failing to surface it to the user is an odd decision, but perhaps still preferable to what's apparently the typical alternative.

The autoplay disabling isn't ready yet and that's why it's still behind an about:config flag.

Any plans now that Vista and IE9 are no longer supported? https://support.microsoft.com/en-us/help/22882/windows-vista...

I'm guessing that you can't test local sites with this tool? If so that'd be really cool!

I have five addons installed (uMatrix, Decentraleyes, vimFx, etc.), and none of them block multiprocess. If you read something like this in your about:support, you better start shopping for multiprocess-compatible alternatives (e.g. I replaced Vimperator with vimFx because Vimperator's architecture and scope is fundamentally incompatible with multiprocess from what I've heard).

Huh, maybe only the unprefixed version was rolled back. This is why I don't do frontend work. ...let me go ask my colleagues about this...

I have four addons that are apparently incompatible.

How do you force multiprocess without disabling these addons?

Why? You can change the number of processes to e.g. 1000 and you will basically get one process per tab until you reach 1000 tabs, and if you do, you will need really a large amount of memory.

one process per tab is specifically why I quit using chrome, it wasn't working even for small amount of tabs (100) it ate RAM like crazy. Mozillas approach is better, user can control how many processes are created - users have control.

Chrome doesn't do process per tab either.

>Please DO process-per-tab. I have a lot of memory. I want you to use it.

I hope that you ask them to add it as an option instead of replacing the current model. Firefox already uses my 8GB memory quite easily when I have many tabs open.

Go to about:config and change dom.ipc.processCount to a high number. You'll get the behaviour you want.

Four is a reasonable default, especially given that multi-process is so new. It's possible that the default number may increase in the future, but that will depend heavily on memory usage.

> I have a lot of memory

Not to do process-per-tab and 500 tabs. Each browser process is several tens of megabytes, somewhat unavoidably (that's assuming you do some sort of embryonic startup and then forking so const non-relocatable data can be shared; if you don't it's a lot more). So on pretty much any consumer hardware you would be constantly swapping at best.

Which is why there is not a single browser that does process-per-tab. Chrome certainly doesn't: once you have more than a few tabs they start multiplexing them across processes.

My counter-point. Please DON'T do process-per-tab! I don't have a lot of memory (just 8GB, of which a lot is consumed by other applications running concurrently). I don't want Firefox to become like Chrome (with several processes - not necessarily process-per-tab, as clarified by others) and become all sluggish and slow down the system just because I opened 50 tabs (I open many more tabs normally)! For me, Firefox has always excelled in handling tons of tabs compared to Chrome. I'm also sure that the Firefox team is aware of the trade-offs and has thought through this for a long, long time.

even chrome doesn't do one process per tab afaik, if I recall they do something closer to process per domain

Because a problematic upgrade could harm or brick every user it rolls out to.

Maybe because there's always the potential that a new version may contain an even bigger bombshell?

Patches for many of these issues have been public already for a few weeks, so waiting another day or two won't cause much additional harm. The CVEs do not contain test cases.

We have to weigh the potential risks against the potential benefits of a quick rollout and try to come to a balanced decision. If we see a problem from feedback from early installs, then we have a chance to quickly patch it and re-release, sometimes within one day. Staged rollout is fairly standard in the industry. (Speaking as a Firefox release manager)

Seems like Firefox OS should have been like Mint. Build on someone else's hard work (ubuntu or debian), tune it for an inexpensive platform (like the most popular netbook/chromebook/cheap laptop) and then work on on what makes it easy to use and useful. Things like a nice default desktop, integrate some cloud storage, automatic backups, user friendly tutorials, etc.

Generally being incompatible with whatever platforms applications (iOS, android, or debian/ubuntu) is a kiss of death. People need their apps and developers need aren't going to cater to a new minority platform with approximately zero users.

I get a lot of weird graphical glitches with Chrome on Windows 7, too - something about the way it draws its windows doesn't always play well with DWM, so they'll leave bits of themselves behind when dragged, or flicker weirdly when dragged across display boundaries, or otherwise uniquely misbehave. Even on machines where the display hardware sucks enough to make graphical oddities relatively common, Chrome stands out in the frequency with which they occur.