4 ms·

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 unsupport

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.

drdaeman 9y ago
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.
- kirillkh 9y ago
  I know it's not a good way out, but it's something we could at least in theory work with.
majewsky 9y ago
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).
- drdaeman 9y ago
  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.
Sylos 9y ago
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1347507

drdaeman 9y ago

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.

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

majewsky 9y ago

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).

drdaeman 9y ago
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.

Sylos 9y ago

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1347507