4 ms·

It baffles me that they would force-disable legacy extensions without having supplied feature parity in the API. There are major extensions like Self-Destructin

by yborg 9y ago

It baffles me that they would force-disable legacy extensions without having supplied feature parity in the API. There are major extensions like Self-Destructing Cookies that are one of the reasons that I still use FF that don't have WebEx equivalents. Without these Firefox is Chrome with inferior performance. Is there a config switch for enabling legacy extensions in 57+?

throwanem 9y ago
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.
- oridecon 9y ago
  AFAIK there's no way to destroy localStorage data so that's a problem for extensions like SDC
  - throwanem 9y ago
    Content scripts can access the window object of the page in which they're injected, so that shouldn't be an issue, I don't believe - if the page in which a content script is running can remove data from localStorage, the content script itself can, too.
    - mook 9y ago
      One of the reasons I use that extension is that it deletes things a short while _after_ the last tab for a site is closed (so they undoing the close lets me keep going). In that case there's no content in which to run scripts.
      - oridecon 9y ago
        https://bugzilla.mozilla.org/show_bug.cgi?id=1340511 https://bugzilla.mozilla.org/show_bug.cgi?id=1340511
amyjess 9y ago
I would strongly recommend dumping Firefox and switching to Pale Moon. Pale Moon is everything Firefox should have been.
- majewsky 9y ago
  How does Pale Moon handle the increasing diff between itself and Firefox? Does it merge uncontroversial changes from Firefox?
MintsJohn 9y ago
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.
- toyg 9y ago
  > As a matter of fact, the whole addon-sdk should never have happened 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.
pmontra 9y ago
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-autodelete/ 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)
- majewsky 9y ago
  If tracking cookies are your concern, I can recommend uMatrix: It's basically a rule-based firewall for requests (like an adblocker on steroids). You can declare rules like "filter all third-party cookies, except $THIRD_PARTY_DOMAIN on $FIRST_PARTY_DOMAIN". It can also be used to block JS, XHR, frames, etc., but if you only need the cookie filtering, you can set the rules for those request types to "allow all". https://github.com/gorhill/uMatrix https://github.com/gorhill/uMatrix
  - ionised 9y ago
    I use both. They have some feature overlap but also accomplish different things.

by yborg 9y ago

throwanem 9y ago

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.

oridecon 9y ago
AFAIK there's no way to destroy localStorage data so that's a problem for extensions like SDC
- throwanem 9y ago
  Content scripts can access the window object of the page in which they're injected, so that shouldn't be an issue, I don't believe - if the page in which a content script is running can remove data from localStorage, the content script itself can, too.
  - mook 9y ago
    One of the reasons I use that extension is that it deletes things a short while _after_ the last tab for a site is closed (so they undoing the close lets me keep going). In that case there's no content in which to run scripts.
    - oridecon 9y ago
      https://bugzilla.mozilla.org/show_bug.cgi?id=1340511 https://bugzilla.mozilla.org/show_bug.cgi?id=1340511

amyjess 9y ago

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

majewsky 9y ago
How does Pale Moon handle the increasing diff between itself and Firefox? Does it merge uncontroversial changes from Firefox?

MintsJohn 9y ago

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.

toyg 9y ago
> As a matter of fact, the whole addon-sdk should never have happened 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.

pmontra 9y ago

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-autodelete/ 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)

majewsky 9y ago
If tracking cookies are your concern, I can recommend uMatrix: It's basically a rule-based firewall for requests (like an adblocker on steroids). You can declare rules like "filter all third-party cookies, except $THIRD_PARTY_DOMAIN on $FIRST_PARTY_DOMAIN". It can also be used to block JS, XHR, frames, etc., but if you only need the cookie filtering, you can set the rules for those request types to "allow all". https://github.com/gorhill/uMatrix https://github.com/gorhill/uMatrix
- ionised 9y ago
  I use both. They have some feature overlap but also accomplish different things.