In case you're wondering how this release affects legacy (non-WebExtension) add-ons, and what the roadmap looks like until Firefox 57 fully disables legacy add-ons:
https://blog.mozilla.org/addons/2017/02/16/the-road-to-firef...
The tl;dr: is that, compared to the XUL API, WebExtensions provide a very limited set of functionality, such that many existing XUL add-ons can't easily be reimplemented in or ported to the new API. On the other hand, it's early days yet, and there appears to be a reasonable amount of interest and developer support devoted to extending the new API so that it offers capabilities comparable to the old. I'd imagine it'll probably be next year this time, more or less, before the dust has largely settled.
[1] https://bugzilla.mozilla.org/buglist.cgi?f1=status_whiteboar...
Is there a config switch for enabling legacy extensions in 57+?
(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.
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.
I agree, but there's a bit of hindsight there. Several years ago, basically, Mozilla people looked at the explosion of Chrome extensions and thought "we are too slow, making an extension is too hard, we need easier onboarding". Hence the addon-sdk project, which itself had a few false starts iirc. It might have had to coordinate with work on FFOS, so that might be the reason it took too long to come to fruition. Whatever the reason might be, by the time the SDK was ready Chrome had run away, making WebExtensions a de-facto standard, so they had to start all over again.
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)
They have some feature overlap but also accomplish different things.
I'm not familiar with the release timelines, but I hope they keep that up at least until they stop supporting Firefox 52 ESR. I switched to it explicitly to keep my XUL add-ons working longer while the add-on makers/Mozilla catch up with the new API.