5 ms·

As somebody who works right now on a Firefox extension I can't agree more. The documentation is a mess. Right now there exist 3 different ways of developing yo

As somebody who works right now on a Firefox extension I can't agree more. The documentation is a mess. Right now there exist 3 different ways of developing your extensions. Even if you decide you are going to use the official Addon SDK it is not clear if you should be using the CFX tool like described in their main repository[1] or JPM[2] which according to this blog post[3] is now the official tool. If you decide to go with the new tool you will find out that there is no documentation how the import system works, except another blog post[4] that just says they are now using npm. Good luck with figuring out all the details. But I think the main problem with Firefox is that once the Addon is inside the browser there is no sandboxing. The Addon has the same privileges as the Firefox process, including the potential to modify other Addons at runtime. That's why the review process is taking such a long time, they basically need to hand check all of your source code to catch if you are doing something nasty. If you don't ask in Chrome for some permission you will just not have access to this API, but not in Firefox. No permissions, always full access. This is an enormous security risk, because it is impossible to check all corner cases of big Addons and be sure that the Addon will not get code from outside and just eval it. [1] https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk [2] https://github.com/mozilla/jpm https://github.com/mozilla/jpm [3] https://blog.mozilla.org/addons/2014/08/19/announcing-add-on-sdk-1-17/ https://blog.mozilla.org/addons/2014/08/19/announcing-add-on... [4] http://work.erikvold.com/jetpack/2014/08/07/cfx-to-jpm.html http://work.erikvold.com/jetpack/2014/08/07/cfx-to-jpm.html

gozala 12y ago
Statement that firefox Add-ons inside the broweser don't have a sandboxing is false. All the add-on SDK built add-ons load in sandboxed in a less privileged JS sandbox, although it is true that there is an escape hatch via `require("chrome")` as some add-ons just want to make modifications that are not even possible elsewhere. This is also reflected on reviews add-ons that do not use `require("chrome")` go through a faster review process while add-on's that do use `require("chrome")` get more thorough reviews. Your criticism in regards to tooling is valid, but it ignores a bigger picture. Two of the the three different ways of writing add-ons have existed long before chrome was even announced and made great add-ons like firebug possible. The fact that there is already a three different ways to write firefox add-ons is outcome of constant improvement of the firefox add-on platform. While this makes things little confusing for newcomers, it still necessary to keep old add-on systems in place, as this keeps people's add-on's alive and subsequently make users using those add-on happy. You also misreading blog posts about JPM, as it is not a new official tool yet, but we are working hard to get there. As of reason why, add-on SDK was designed with commonjs modules in mind as we saw it becoming de facto standard. Back then node was not announced yet, needles to mention npm and tons of packages published to it. There for toolchain named CFX was written in python. Now that node became a standard tool in the JS toolchain and npm is where js libraries get published we are working to refresh our toolchain and embrace all this, subsequently making thousands of packages available in npm available to an add-on authors.
- Padding 12y ago
  > While this makes things little confusing for newcomers, A "little confusing" is way off the mark here. If it weren't for Google Search working its magic, it would be practically insurmountable. > it still necessary to keep old add-on systems in place, I don't think anyone is asking to scrape the old APIs. Just clearly mark the APIs as depracated and link to the new corresponding bits of documentation .. that is after writing them first. As it stands, writing a Firefox extension is somewhat of an arcane art currently.

gozala 12y ago

Statement that firefox Add-ons inside the broweser don't have a sandboxing is false. All the add-on SDK built add-ons load in sandboxed in a less privileged JS sandbox, although it is true that there is an escape hatch via `require("chrome")` as some add-ons just want to make modifications that are not even possible elsewhere. This is also reflected on reviews add-ons that do not use `require("chrome")` go through a faster review process while add-on's that do use `require("chrome")` get more thorough reviews. Your criticism in regards to tooling is valid, but it ignores a bigger picture. Two of the the three different ways of writing add-ons have existed long before chrome was even announced and made great add-ons like firebug possible. The fact that there is already a three different ways to write firefox add-ons is outcome of constant improvement of the firefox add-on platform. While this makes things little confusing for newcomers, it still necessary to keep old add-on systems in place, as this keeps people's add-on's alive and subsequently make users using those add-on happy. You also misreading blog posts about JPM, as it is not a new official tool yet, but we are working hard to get there. As of reason why, add-on SDK was designed with commonjs modules in mind as we saw it becoming de facto standard. Back then node was not announced yet, needles to mention npm and tons of packages published to it. There for toolchain named CFX was written in python. Now that node became a standard tool in the JS toolchain and npm is where js libraries get published we are working to refresh our toolchain and embrace all this, subsequently making thousands of packages available in npm available to an add-on authors.

Padding 12y ago
> While this makes things little confusing for newcomers, A "little confusing" is way off the mark here. If it weren't for Google Search working its magic, it would be practically insurmountable. > it still necessary to keep old add-on systems in place, I don't think anyone is asking to scrape the old APIs. Just clearly mark the APIs as depracated and link to the new corresponding bits of documentation .. that is after writing them first. As it stands, writing a Firefox extension is somewhat of an arcane art currently.