Sorry, I meant multiprocess. Firefox has, for as long as I remember, been multi thread. Basilisk is a fork of FF55 and will not use Electrolysis.
Edit:
The aim of Basilisk is to support all extensions, so they’re going to stagnate and not benefit from the speed increases in 57 onward.
Update on my test up above after doing a bit more normal browsing with my test set of tabs and leaving it for the night:
Firefox ram usage has dropped to 1.91G
Chrome ram usage has risen to 1.91G
…I’ll be honest, that was not the result I was expecting. Just to be sure, I went through on both browsers and checked each tab to be sure each was updated (getting new threads on open twitter feeds, this site, etc). After that step, Firefox was still holding steady, but Chrome had risen to 2.08G. It (very) slowly started to drop back downward when I left the browser alone.
It’s looking as though, on my configuration, for long-term browsing, there’s probably not a big difference between the two.
And starting over even fresher as I got reboot patch last night.
Now I’ve got just 3 tabs open: gmail inbox, this page, and the Washington Post front page. Firefox is using ~1.17GB and six tasks. Just for fun I printed the WashPost page to PDF, and also saved it as an HTM file. (I made sure to navigate to the bottom of the web page first, to load all the images.) The pdf file is 4 MB, and the HTM file is 241 KB.
So is Firefox prefetching things to make it faster? Is that what a lot of the memory is used for?
Welp, I saw that NoScript was finally available in FF57, so I upgraded. Mistake. I should have read the fine print… a couple of the other extensions that I thought had been ported already are only “in the process” and after looking at the API docs, it’s not going to be possible to port that functionality. Pity they couldn’t fix it, we had such high hopes for XUL back in the day. Trying out Waterfox now.
Do you have any links to the relevant info?
Anybody missing Tree Style Tabs, it’s been ported to Web Extensions.
https://hacks.mozilla.org/2017/12/webextension-tree-style-tab/
Can anyone explain what xul and webextension can do, and what xul did that webextension can’t do?
Because I’m going to need to know if Firefox 57+ can eventually meet my accessibility needs, or if one of the forks is a better bet, unless there’s another browser that can meet my needs-- such as not getting punched: fuck Opera, fuck Sleipnir, fuck Google Maps…
Unfortunately, only Firefox 56 contains any migration tools, Firefox 52 esr won’t contain migration tools for those of us who need to wait for adequate keep-sites-from-hammering-our-brains tools.
P.S. https://bugzilla.mozilla.org/show_bug.cgi?id=1422910
P.P.S. Not all my tools will work yet, but my user styles will. It’s just that the Stylish migration was screwed up. I transferred to Stylus instead, and they’re working. I think my user scripts are gone even in 52.
Is anyone on Firefox running Ad Nauseum?
Is is any good? The concept seems cool.
Marja,
As I understand it, the difference is essentially the following.
With XUL-based add-ons, you could do anything you wanted that Firefox’s own code could do itself, which was effectively unlimited, subject to passing through critical examination in the submissions queue before being posted to addons.mozilla.org. With an XUL add-on, the add-on’s code was mixed in with, interacted with and possibly partially replaced the code of Firefox’s own UI. The add-on had similar powers over the contents of web pages shown in tabs.
With WebExtensions-based add-ons, you (as the author of an add-on) can do nothing except that which is allowed through the WebExtensions API. Which is a lot, because it starts with (aiming for/achieving) parity with whatever Google Chrome can do, and adds some, namely whatever was needed by the people writing the most popular add-ons, in some priority order, limited by Mozilla developer time and added as they could get to it. But in general, the WebExtensions API allows doing things more to web pages and less to the Firefox UI, because that was one of the philosophical underpinnings of the new direction with WebExtensions.
By analogy with firewalls, which you’ve probably touched at some point: the policy with XUL add-ons was simply ALLOW, while the policy with WebExtensions is DENY,ALLOW, denying all operations then allowing some specific ones, the ones in the API.
I haven’t written any code with WebExtensions so I don’t know what’s in the API. This is just my general understanding based on what people have said and written about WebExtensions as it was coming onto the scene. It wouldn’t take many detailed questions about WebExtensions before I’d just be like ::shrug::. If anyone knows better, please clarify. But, if you don’t need to customize the Firefox UI much, but do need to customize what you see in web pages, there’s a good chance people could write add-ons doing what you want. It depends what you want.
I think that answers the first half of your question but not the second half.
An interesting limitation is that webextensions can’t affect Reader/Readable View.
P.S. Also they can’t create their own pages for editing, and Stylish/etc. and Greasemonkey/etc. can’t add lists of user styles and user scripts to about:addons. Stylus now keeps its list in its preferences. Greasemonkey now hides its list, only accessible by rummaging through Firefox’s libraries.