Labs/Jetpack/Release Notes/1.1
About
Add-on SDK is a software development kit that provides a set of tools and APIs for building, testing, and packaging Firefox add-ons.
The 1.1 release is the second stable release of the SDK. It's mostly a stabilization release, and does not include many major new features.
Installation
Obtain the SDK in your favorite compression format:
Then unpack the archive, open the addon-sdk-1.1/README.txt file, and follow its instructions.
Major Changes Since 1.0
Bug 663541: better transition/porting of modules that use "Components"
This change is intended to help developers porting traditional XUL/XPCOM add-ons to the SDK. It's only of interest to developers who use the Components object.
The change means that add-on code which uses the Components object will not generate errors, as long as the code has a require("chrome") line.
The bug summary has an excellent description of the change.
Bug 672199: the 'exports' object is now frozen
This change freezes the object returned by require, so the caller can't change its properties.
Bug 553434: SDK code declares "use strict"
All SDK code now uses strict mode. Note that this does not apply to add-on code.
Bug 668512: context-menu module now supports images
This change adds a new image property to the context-menu's Item and Menu objects: this is a URL pointing to an image to display in the menu.
Bug 658592: make --strip-xpi the default, add --no-strip-xpi
Bug 653256 added the --strip-xpi flag into SDK 1.0, which, if invoked, creates an XPI containing only the set of modules actually required.
In 1.1 we have made this the default behavior, deprecated --strip-xpi, and added a new option --no-strip-xpi, for those who want the old behavior.
Bug 666547: Add a mechanism to communicate between content scripts and scripts loaded by a page
Content scripts expect to be able to communicate with scripts loaded into web pages using window.postMessage(). However, because the global postMessage() in content scripts is used for sending messages to the main add-on code, you can't use it to send messages to page scripts.
Bug 666547 enables content scripts to use document.defaultView.postMessage() to send messages to page scripts. So given a page like:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang='en' xml:lang='en' xmlns="http://www.w3.org/1999/xhtml">
<head>
<script>
window.addEventListener("message", function(event) {
window.alert(event.data);
}, false);
</script>
</head>
<body>
</body>
</html>
You can send it messages using a content script like this:
var widgets = require("widget");
var tabs = require("tabs");
var widget = widgets.Widget({
id: "mozilla-link",
label: "Mozilla website",
contentURL: "http://www.mozilla.org/favicon.ico",
onClick: function() {
tabs.activeTab.attach({
contentScript: "document.defaultView.postMessage('hi there!', '*');"
});
}
});
Note that the global postMessage in content scripts is already deprecated. If and when it is removed entirely, we would be able to give window.postMessage the expected behavior.
Add overrideMimeType option to Request constructor
This change adds a new overrideMimeType option to the Request object's constructor, which enables you to specify the MIME type that should be used in place of that returned by the server.
Known Issues
See the complete list of known issues and requests for enhancement. We've listed some of the more important issues separately below.
If your add-on has a long name, and the path to your Firefox profile is long enough, then the XPI installation process will try to create an intermediate file with a name longer than the maximum supported length on some Windows systems. If that happens you may get an error like:
"<your add-on> could not be installed because Firefox cannot modify the needed file"
The main fix for this will be bug 638742, which is to stop unpacking the XPI completely. When that is done, none of the pathnames will matter: they'll all stay safely trapped inside the zipfile. At that point, the name of the XPI file and the length of the profile directory will be the only issues.
Until then, the best advice is to use shorter package names or install Firefox higher up the directory tree so the profile directory's absolute path is shorter.
The SDK automatically includes a dependency on the packages supplied with the SDK such as addon-kit and api-utils. This means that you can require() modules in the SDK such as widget without having to specify addon-kit as a dependency.
You can also use modules from other packages, such as the packages listed here, by including a reference to the package in your package.json file.
However, if you do add any dependencies to package.json, then the SDK will no longer add addon-kit or api-utils automatically, and you must add them manually if you want to include their modules.
The SDK will give an error if your package name contains spaces or Unicode characters.
If your add-on stores data using the simple-storage API, the data is not cleaned up when your add-on is uninstalled.
Some core JavaScript functions, such as btoa(), are not available to add-on code.
selection.text returns null instead of the selected text when the selection is in a text box or text area.
If an add-on is uninstalled while it's disabled, it's not notified of uninstall. If the add-on needs to do some special cleanup on uninstall, like removing persistent storage such as a file, this won't be possible if it has been disabled.
bin\activate fails to find 64-bit Python on 64-bit Windows environments, as it assumes Python is 32-bit.
On Windows, bin\activate sometimes gives the following error:
"Error: The system was unable to find the specified registry key or value"
This does not seem to affect the functioning of the SDK.
By default, widgets are placed on the add-on bar, and given a height to match the height of that bar. If the user moves the widget to a different toolbar, and that toolbar has a different height, the widget's height is not updated accordingly.
A widget containing HTML content gets no icon in the Customize Toolbar Window.
When a user removes a widget from the toolbar its detach event does not get sent.
Selection events for a page are not sent if the page did not fully load (for example, because the user stopped the page loading).
Bug 556562: mozrunner installation may break cfx test
If you have copy of mozrunner installed on your system, the cfx test command may not work correctly.
There is a workaround for this.
Feedback and Bug Reports
We'd love to hear any feedback you have regarding this release! You can post it to the discussion group or report a bug.
