4 ms·

So, will extensions like pentadactyl or Tree Style Tabs be able to exist after "some point in 2017"? Ignoring rewrite time etc., will there be APIs available to

by hucker 10y ago

So, will extensions like pentadactyl or Tree Style Tabs be able to exist after "some point in 2017"? Ignoring rewrite time etc., will there be APIs available to do what they do today?

Yoric 10y ago
The WebExtensions team has been very proactive, attempting to get in touch with add-on developers across the spectrum. If the add-on developers have responded, there's a 99% chance that new APIs will be available for their add-ons.
- alphapapa 10y ago
  And what about extensions that have thousands upon thousands of users, still working fine, but haven't been updated in years because the author ran into real life? Is Mozilla going to dump those users on the street and then say, "Well, your author should have contacted us, we don't have time to implement your API now"?
  - cdmckay 10y ago
    I don't think that's unreasonable. They can't keep backwards compatibility forever because there might be some unmaintained extensions in the wild.
- tn123 10y ago
  Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs. So far, Firefox did not even manage to reach chrome parity, let alone bug parity. If you look at the Advisory Group meeting notes (in charge of new APIs AFAIK), there is almost nothing still: https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeut4zQiCkJbrMVpSEm5Lk/edit# https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeu... Sorry David, but you're kidding yourself here.
  - hackuser 10y ago
    From Giorgio Maone, developer of one of the most complex and most popular extensions, NoScript: Developers and users are also concerned about add-ons being prevented from exploring radically new concepts which would require those "super powers" apparently taken away by the WebExtensions API. I'd like to reassure them: Mozilla is investing a lot of resources to ensure that complex and innovative extensions can prosper also in the new Web-centric ecosystem. In fact, as mentioned by Bill McCloskey, at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API, which is going to be augmented and shaped around their needs and with their contributions. https://hackademix.net/2015/08/22/webextensions-api-noscript/ https://hackademix.net/2015/08/22/webextensions-api-noscript...
    - tn123 10y ago
      From Nils Maier, developer of some of the most complex and most popular extensions, DownThemAll! (+ MinTrayR): Read my comments That comment by Giorgio (nice guy btw, shared a room with him on at a couple of mozilla events) is over a year old by now and rather optimistic. So far, nothing of that happened, nor will it ever happened at a scale that actually accommodates most add-on developers.
      - hackuser 10y ago
        > So far, nothing of that happened He wrote that it was already happening a year ago: at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API I'm not an add-on developer but I've read about it happening in other places too, and I know for a fact that Giorgio is working on Firefox WebExtensions issues in Bugzilla.
  - Sylos 10y ago
    > Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs. I don't know how you come to this conclusion. They've been able to maintain XUL up until now and whatever they end up with in this new API, it'll be cheaper to maintain than the monstrosity that is XUL extensions. The specification and implementation are done in cooperation with the add-on developers. They can draw from the community here. And while they haven't reached Chrome parity yet, they do have already implemented some additional APIs. You're writing as if one thing would block the other.

by hucker 10y ago

So, will extensions like pentadactyl or Tree Style Tabs be able to exist after "some point in 2017"? Ignoring rewrite time etc., will there be APIs available to do what they do today?

Yoric 10y ago

The WebExtensions team has been very proactive, attempting to get in touch with add-on developers across the spectrum. If the add-on developers have responded, there's a 99% chance that new APIs will be available for their add-ons.

alphapapa 10y ago
And what about extensions that have thousands upon thousands of users, still working fine, but haven't been updated in years because the author ran into real life? Is Mozilla going to dump those users on the street and then say, "Well, your author should have contacted us, we don't have time to implement your API now"?
- cdmckay 10y ago
  I don't think that's unreasonable. They can't keep backwards compatibility forever because there might be some unmaintained extensions in the wild.
tn123 10y ago
Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs. So far, Firefox did not even manage to reach chrome parity, let alone bug parity. If you look at the Advisory Group meeting notes (in charge of new APIs AFAIK), there is almost nothing still: https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeut4zQiCkJbrMVpSEm5Lk/edit# https://docs.google.com/document/d/1qCIUX0LavYixkzwan8IcSYeu... Sorry David, but you're kidding yourself here.
- hackuser 10y ago
  From Giorgio Maone, developer of one of the most complex and most popular extensions, NoScript: Developers and users are also concerned about add-ons being prevented from exploring radically new concepts which would require those "super powers" apparently taken away by the WebExtensions API. I'd like to reassure them: Mozilla is investing a lot of resources to ensure that complex and innovative extensions can prosper also in the new Web-centric ecosystem. In fact, as mentioned by Bill McCloskey, at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API, which is going to be augmented and shaped around their needs and with their contributions. https://hackademix.net/2015/08/22/webextensions-api-noscript/ https://hackademix.net/2015/08/22/webextensions-api-noscript...
  - tn123 10y ago
    From Nils Maier, developer of some of the most complex and most popular extensions, DownThemAll! (+ MinTrayR): Read my comments That comment by Giorgio (nice guy btw, shared a room with him on at a couple of mozilla events) is over a year old by now and rather optimistic. So far, nothing of that happened, nor will it ever happened at a scale that actually accommodates most add-on developers.
    - hackuser 10y ago
      > So far, nothing of that happened He wrote that it was already happening a year ago: at this moment I'm working within Mozilla's Electrolysis team and with other add-on authors, involved in the design of mechanisms and processes helping developers experiment in directions not supported yet by the "official" the WebExtensions API I'm not an add-on developer but I've read about it happening in other places too, and I know for a fact that Giorgio is working on Firefox WebExtensions issues in Bugzilla.
- Sylos 10y ago
  > Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs. I don't know how you come to this conclusion. They've been able to maintain XUL up until now and whatever they end up with in this new API, it'll be cheaper to maintain than the monstrosity that is XUL extensions. The specification and implementation are done in cooperation with the add-on developers. They can draw from the community here. And while they haven't reached Chrome parity yet, they do have already implemented some additional APIs. You're writing as if one thing would block the other.