4 ms·

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-

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-firefox-57-compatibility-milestones/ https://blog.mozilla.org/addons/2017/02/16/the-road-to-firef...

throwanem 9y ago
For a more detailed, albeit less well organized, view of functionality yet to be added to the WebExtensions API, there's also the relevant Bugzilla whiteboard [1]. 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_whiteboard&o1=substring&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&v1=%5Bdesign-decision-approved%5D&component=WebExtensions%3A%20Android&component=WebExtensions%3A%20Compatibility&component=WebExtensions%3A%20Developer%20tools&component=WebExtensions%3A%20Experiments&component=WebExtensions%3A%20Frontend&component=WebExtensions%3A%20General&component=WebExtensions%3A%20Request%20Handling&component=WebExtensions%3A%20Untriaged&product=Toolkit&list_id=13631066 https://bugzilla.mozilla.org/buglist.cgi?f1=status_whiteboar...
- 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.
Chaebixi 9y ago
> AMO will continue to support listing and updating legacy add-ons after the release of 57 in order to have an easier transition. The exact cut-off time for this support hasn’t been determined yet. 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.
kretor 9y ago
A potential problem with the force-disabling in 57 is that the only way to hand over configuration from a legacy addon to its successor WebExtension is to preemptively for the legacy addon to convert their configuration. If you only irregularly use your Firefox, the configuration conversion is not guaranteed to run, as you would have to open your Firefox to trigger that.

throwanem 9y ago

For a more detailed, albeit less well organized, view of functionality yet to be added to the WebExtensions API, there's also the relevant Bugzilla whiteboard [1]. 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_whiteboard&o1=substring&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&v1=%5Bdesign-decision-approved%5D&component=WebExtensions%3A%20Android&component=WebExtensions%3A%20Compatibility&component=WebExtensions%3A%20Developer%20tools&component=WebExtensions%3A%20Experiments&component=WebExtensions%3A%20Frontend&component=WebExtensions%3A%20General&component=WebExtensions%3A%20Request%20Handling&component=WebExtensions%3A%20Untriaged&product=Toolkit&list_id=13631066 https://bugzilla.mozilla.org/buglist.cgi?f1=status_whiteboar...

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.

Chaebixi 9y ago

> AMO will continue to support listing and updating legacy add-ons after the release of 57 in order to have an easier transition. The exact cut-off time for this support hasn’t been determined yet. 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.

kretor 9y ago

A potential problem with the force-disabling in 57 is that the only way to hand over configuration from a legacy addon to its successor WebExtension is to preemptively for the legacy addon to convert their configuration. If you only irregularly use your Firefox, the configuration conversion is not guaranteed to run, as you would have to open your Firefox to trigger that.