Mozilla Add-ons Community Blog
Categories: developers jetpack releases

Announcing Add-on SDK 1.0b1

12 responses

The Jetpack team is thrilled to announce the release of Add-on SDK 1.0b1, the first beta release of Mozilla’s new software development kit for building Firefox add-ons!

Add-on SDK 1.0b1, the culmination of months of hard work and nine alpha releases, is the best way to get started with building add-ons for the upcoming Firefox 4.

  • It combines tools for creating, testing, and packaging add-ons with a set of high-level APIs that make it simple to access pages, tabs, and other browser features.
  • With the SDK, all you need to know to build Firefox add-ons are common web technologies like HTML, JavaScript, and CSS.
  • Add-ons built with the SDK can be installed into Firefox without having to restart the browser afterwards, making them easier for users to acquire.
  • And the SDK’s APIs are designed to be compatible with anticipated future changes to Firefox (in particular, the Electrolysis project to display web pages using multiple processes), so you can write your add-on for Firefox 4 and run it on future versions of Firefox.

To get started building add-ons with the SDK, download it and then check out the tutorial! And try out these add-ons built with earlier versions of the SDK:

Note that this version of the SDK is not a feature-complete beta, as we intend to enhance existing high-level APIs and add new ones in future beta releases. But it is a feature-stable beta, which means that we don’t expect to make breaking changes to the existing set of high-level APIs in subsequent betas, and we will make such changes only for very good reasons.

But keep in mind that low-level APIs and functionality labeled experimental or internal in the SDK documentation are still subject to change in future releases.

If you tested alpha versions of the SDK, formerly known as Jetpack SDK, you’ll find that we have made a number of changes to its tools and APIs in preparation for this release. Check out the release notes and documentation for details about the changes and the current feature set along with Daniel Buchner’s State of the Add-on Developer Union blog post for a comparison of the APIs provided by the various browsers.

Questions? Complaints? Talk to us! Your participation is critical as we flesh out the existing APIs and add new ones in subsequent beta releases.

12 comments on “Announcing Add-on SDK 1.0b1”

  1. Dave wrote on

    Browse By Name by Ehsan Akhgari does not currently use the SDK. Version 1.0 was built using it, but after discovering that this led to 128KB of pointless bloat he rewrote it manually into a handful of lines, even while adding revert on disable, and ended up with something under 1KB in total. This is not an example you want to mention for promoting the SDK… :/

    1. myk wrote on

      Dave: Ah, sorry. The add-on is tagged with the “jetpack” tag, which is supposed to indicate that it is built using the Add-on SDK, but I guess the tag didn’t get cleared when the updated version that doesn’t use the SDK was submitted to AMO. I’ll look into clearing the tag.

      Incidentally, the point of the “pointless bloat” you reference is to simplify add-on development for developers who are unfamiliar with the traditional XUL extension platform and maintain add-on compatibility with future versions of Firefox that separate chrome, content, and add-on code into distinct processes.

      Nevertheless, we’re looking at ways to streamline SDK-based add-on packages so they only include the specific API implementations that the add-on is using.

  2. panzi wrote on

    So this is not compatible with Firefox 3.6.x? Please the next time when you make such a thing not compatible with the current stable release put a big red warning in the news message, because I just spent a lot of time porting my addon to this new version and debugging why it just doesn’t work anymore until I found that it is “not compatible”. So I have to rollback my changes and use jetpack 0.9.

    1. myk wrote on

      I’m sorry that we didn’t make it clearer! We actually decided to stop supporting Firefox 3.6 for the SDK 0.9 release, although 3.6 mostly worked with that release anyway. I’ll make this more obvious in the future.

  3. Johan Sundström wrote on

    My take-away on SDK add-ons from this week’s add-on-con is that the intent is that you upload+submit+release a final pre-FF4 version of your add-on at AMO, with a Firefox maxVersion < 4.0, then rewrite it once to use the SDK instead, and upload that to AMO, setting a minVersion of 4.0 on the new release, and then do as you please with continuing from there with updates and fixes for the pre-SDK version, alongside the main-line SDK version which you do your normal work on.

    I should say that it wasn't broadly boasted as The Way, or anything, but it seems to be the only one which is currently paved. Especially prior to FF4 launch, this is of course a less than tempting endeavor to embark on, but it'll at least work.

  4. Brett Zamir wrote on

    Hi,

    Although I know the point of Jetpack is to simplify Firefox development, has thought been given to designing the APIs at least with naming conventions which are generic enough that the same API could be used for building extensions in other browsers (even if the other browsers have a long way to go to offering the same platform functionality as Firefox)?

    While web standards are nice, having a standard, de facto, or at least adaptable API, for privileged extension code would sure also be nice, especially as other browsers dive into this realm.

    And while the cool extensions are still mostly in Firefox, it will also be nice to have those initiating extensions in other browsers be easily portable back to Firefox.

    Also, in order for those aware of the risks, or for those working in an intranet, to be able to use the very same API from regular websites (thus allowing not only HTML5 but the same APIs to be used in any environment), with web-based requests being enabled to ask user permission to gain privileged access. With enablePrivilege now going away, how about making an add-on at least which allows conditional access to such a potentially browser-neutral API: https://bugzilla.mozilla.org/show_bug.cgi?id=546848#c45

    1. myk wrote on

      Yes, we have thought about building APIs that are cross-browser compatible, and we’ve talked about it at the recent Add-on-Con and other events. At this point there are no plans to do that, but it’s certainly something we’d consider.

      We haven’t considered exposing the SDK’s APIs to web content, however. That’s an interesting idea, though, and I’d be interested to see more work around defining the specific use cases being addressed and how to deal with the security issues.

  5. SpeedGun wrote on

    Cool, good to see the SDK getting to such an advanced stage.

    I have been using it for a while (made this: https://addons.mozilla.org/en-US/firefox/addon/235804) and I can say it simplifies addon development quite a bit.

  6. saivert wrote on

    Didn’t Jetpack originally start out as a addon itself which allowed the loading of HTML+JS based addons. then later turned into a framework for compiling XUL based addons (it takes HTML+JS and compiles it into XUL) or am I confused as to what this python based cfx tool is really doing?

    1. myk wrote on

      That’s basically right.

      The original Jetpack Prototype was an extension that let you create add-ons using common web technologies like HTML, JS, and CSS. The SDK preserves that original goal of creating add-ons with common web technologies, but instead of creating a whole new add-on packaging format, it reuses the existing XPI format.

      Both the Prototype and the SDK “compile” HTML into XUL, however, in the sense that they let you create HTML interface elements like widgets and panels whose underlying implementations are XUL.

  7. R.G. wrote on

    I’m a newbie to extension development and I downloaded the SDK 1.0b1 yesterday, followed the tutorial docs and got to the programs section and converted it to an xpi. FF 4.0b8 says that the add-on is not compatible. Why? What am i missing? I posted the same question here: https://developer.mozilla.org/forums/viewtopic.php?f=6&t=145

    1. Myk Melez wrote on

      Firefox 4.0b8 was not released at the time we released Add-on SDK 1.0b1, so we didn’t mark it as compatible with add-ons built with the SDK (since we couldn’t know for sure that they were).

      Since then, Firefox 4.0b8 and b9 have both been released, and the Firefox team has said there will be no major breaking changes in add-on compatibility.

      Thus the next version of the SDK, 1.0b2, currently scheduled for release next week, will mark add-ons as compatible with Firefox 4.0.* (i.e. the stable final release of Firefox 4 and all minor security/stability updates).