Hacker News Reader

Comment by drdaeman | Hacker News Reader

Actually, it still does support legacy extensions and probably will do for a while. There are `browser/features/*.xpi` files in the browser install directory. Even in 57, they're all "legacy" extensions, and the only WebExtension there is `screenshots@mozilla.org.xpi` (even then, still a "legacy" install.rdf-type file, with embedded WE).

And I've just copied the legacy `https-everywhere@eff.org.xpi` non-WE addon there - and it worked ;)

I'm sure they're going to plug this "hole" shut, but it's still there. As well as patching omni.ja.

View on HN

If it keeps working in FF 57 and won't break after every minor update, I might upgrade. I was actually thinking that providing some kind of officially unsupported backdoor for determined users like us might be a way out of this situation.

The internal APIs will eventually change (break). They already did on major releases - one can find lots of "does not work on Firefox NN+ anymore, please update" comments all over AMO. (By design, this should be significantly rarer occasion with the WebExtensions)

Now there is no requirement to keep them stable even across the patch-level releases. Whenever things would break faster or at the same pace is unknown.

I know it's not a good way out, but it's something we could at least in theory work with.

I'm not involved in FF development, but I find it exceedingly unlikely that this will keep working for much longer than a few releases after 57. The whole purpose of all of this is to rip out all the XUL baggage to decrease maintenance cost and make it easier for the developers to focus on actual features and fixing bugs that actual people encounter (as opposed to keeping legacy code paths working where no one has a clue if they are even used anymore).

Ripping out XUL baggage is fine, it doesn't matter which language UI elements are described in. Yes, it would require to rewrite stuff, but that's manageable.

The important part is ability to replace (overlay) chrome resources, patching/extending the browser code. I hope that's going to stay for a while.

No, it is going to break after every minor update. Most legacy extensions already don't work anymore in Firefox Nightly, even if you tell it to load them [0], simply because Mozilla has very much already used their new freedom to throw out tons of legacy code [1] and to refactor what's left.

The Mozilla-supplied legacy extensions continue to function, because Mozilla is updating them as they make changes to the internals of Firefox. So, I imagine maintaining such a legacy extension is now as much work as it is to just directly contribute and maintain the feature in Firefox's codebase.

[0]: "extensions.legacy.enabled" in about:config. This won't be shipped in Stable, though, and will likely be taken out from Firefox Nightly soon or with the release of Firefox 57.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1347507

Reply on news.ycombinator.com