Sergey, the short and informal answer is that the move to webextensions and the deprecation of xul and sdk extensions are large pieces of an effort to limit the ability for folks to run unreviewed and out-of-tree code with full chrome privileges in Firefox. Here's a partial list of blog posts that explain why this is important: https://blog.mozilla.org/addons/2015/08/21/the-future- of-developing-firefox-add-ons/ https://blog.mozilla.org/addons/2016/03/14/webextensons-whats-in-it-for- developers/ http://www.mckay.pub/2016-04-17-addons-old/
There have also been a number of discussions on this topic on the dev-addons mailing list (which is probably a good place for follow-ups if you want to discuss this further). Although we're not planning to do everything that was proposed for native.js, we do have webextensions experiments: https://webextensions-experiments.readthedocs.io/en/latest/ Briefly, an experiment is an extension that exists just to implement a webextensions API to be used by regular webextensions. We're still relatively early with this project, but the basic idea is that if you want to write an extension that requires access to something that isn't currently exposed via a webextensions API, you create an experiment to expose the thing you need in a way that is consistent with the webextensions goals of safety, maintainability, etc. The experiment runs with chrome privileges so it requires a thorough review, but the bulk of your code can be written as a regular webextension, with all the benefits that come along with that. Then, if this new API is something that proves to be popular, it can uplifted into the browser. I'm happy to discuss this all further but like I mentioned above, the dev-addons mailing list would probably be more appropriate than dev-platform. Or you can come find is on IRC in #webextensions. -Andrew On Sat, Jan 28, 2017 at 4:55 PM, Sergey Rozhenko <serg...@gmail.com> wrote: > So far I haven't been able to find any piece of rationale behind > https://bugzilla.mozilla.org/show_bug.cgi?id=1199718 getting WONTFIXed. > And that's weird, because there has to be an enormous reason to justify its > scrapping. > WebExtensions made perfect sense to me until this happened: > - Most extensions won't use it, would be easy to sign and won't break with > FF updates. > - Small percentage of extensions will make use of it to do the special > things. > > Ability of addons to modify browser UI code is the defining feature of > FireFox. Considering that Mozilla evidently lags far behind Chrome in > manpower and resources, there's very little FF can do to compete if this > feature is lost. > It will lose most of "must-have" addons that power users of FF can't live > without and that make people use FF rather than Chrome, like those made by > Quicksaver: https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/ > > So, again, this is a "life and death" kind of issue for FireFox and there > must be a "life and death" reason for scrapping native.js. What is it? > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform