Updating extensions for Firefox 3 - Mozilla

Updating extensions for Firefox 3
=================================

This article provides information that will be useful to developers that wish to update their extensions to work properly under Firefox 3.

Before going further, there's one helpful hint we can offer: if the only change your extension requires is a bump to the `maxVersion` field in its install manifest, and you host your extension at addons.mozilla.org, you don't actually need to upload a new version of your extension! Use the Developer Control Panel at AMO to adjust the `maxVersion`. You can avoid having to have your extension re-reviewed this way.

Step 1: Update the install manifest
-----------------------------------

The first step — and, for most extensions, the only one that will be needed — is to update the install manifest file, `install.rdf`, to indicate compatibility with Firefox 3.

Find the line indicating the maximum compatible version of Firefox (which, for Firefox 2, might look like this):

```xml
<em:maxVersion>2.0.*</em:maxVersion>
```

Change it to indicate compatibility with Firefox 3:

```xml
<em:maxVersion>3.0.*</em:maxVersion>
```

Then reinstall your extension.

Note that Firefox 3 does away with the extra ".0" in the version number, so instead of using "3.0.0.\*, you only need to use "3.0.\*".

There have been (and will continue to be) a number of API changes that will likely break some extensions. We're still working on compiling a complete list of these changes.

**Note:** If your extension still uses an `Install.js` script instead of an install manifest, you need to make the transition to an install manifest now. Firefox 3 no longer supports `install.js` scripts in XPI files.

### Add localizations to the install manifest

Firefox 3 supports new properties in the install manifest to specify localized descriptions. The old methods still work however the new allow Firefox to pick up the localizations even when the add-on is disabled and pending install. See Localizing extension descriptions for more details.

Step 2: Ensure you are providing secure updates
-----------------------------------------------

If you are hosting addons yourself and not on a secure add-on hosting provider like addons.mozilla.org then you must provide a secure method of updating your add-on. This will either involve hosting your updates on an SSL website, or using cryptographic keys to sign the update information. Read Securing Updates for more information.

Step 3: Deal with changed APIs
------------------------------

Several APIs have been changed in significant ways. The most significant of these, which will likely affect a large number of extensions, are:

### DOM

Nodes from external documents should be cloned using `document.importNode()` (or adopted using `document.adoptNode()`) before they can be inserted into the current document. For more on the `Node.ownerDocument` issues, see the W3C DOM FAQ.

Firefox doesn't currently enforce this rule (it did for a while during the development of Firefox 3, but too many sites break when this rule is enforced). We encourage Web developers to fix their code to follow this rule for improved future compatibility.

### Bookmarks & History

If your extension accesses bookmark or history data in any way, it will need substantial work to be compatible with Firefox 3. The old APIs for accessing this information have been replaced by the new Places architecture. See the Places migration guide for details on updating your existing extension to use the Places API.

### Download Manager

The Download Manager API has changed slightly due to the transition from an RDF data store to using the Storage API. This should be a pretty easy transition to make. In addition, the API for monitoring download progress has changed to support multiple download manager listeners. See `nsIDownloadManager`, `nsIDownloadProgressListener`, and Monitoring downloads for more information.

### Password Manager

If your extension accesses user login information using the Password Manager, it will need to be updated to use the new Login Manager API.

* The article Using nsILoginManager includes examples, including a demonstration of how to write your extension to work with both the Password Manager and the Login Manager, so it will work with both Firefox 3 and earlier versions.
* `nsILoginInfo`
* `nsILoginManager`

You can also override the built-in password manager storage if you want to provide your own password storage implementation in your extensions. See Creating a Login Manager storage module for details.

### Popups (Menus, Context Menus, Tooltips and Panels)

The XUL Popup system was heavily modified in Firefox 3. The Popup system includes main menus, context menus and popup panels. A guide to using Popups has been created, detailing how the system works. One thing to note is that `popup.showPopup` has been deprecated in favor of new `popup.openPopup` and `popup.openPopupAtScreen`.

### Autocomplete

The `nsIAutoCompleteController` interface's `handleEnter()` method has been changed to accept an argument that indicates whether the text was selected from the autocomplete popup or by the user pressing enter after typing text.

### DOMParser

* When a `DOMParser` is instantiated, it inherits the calling code's principal and the `documentURI` and `baseURI` of the window the constructor came from.
* If the caller has UniversalXPConnect privileges, it can pass parameters to `new DOMParser()`. If fewer than three parameters are passed, the remaining parameters will default to `null`.
    + The first parameter is the principal to use; this overrides the default principal normally inherited.
    + The second parameter is the `documentURI` to use.
    + The third parameter is the `baseURI` to use.
* If you initialize a `DOMParser` using a contract, such as by calling `createInstance()`, and you don't call the `DOMParser`'s `init()` method, attempting to initiate a parsing operation will automatically create and initialize the `DOMParser` with a null principal and `null` pointers for `documentURI` and `baseURI`.
### Stop using the internal string API

The internal string API is no longer exported; you must migrate to the external string API. See these articles for helpful information:

* Mozilla external string guide
* XPCOM Glue
* Migrating from Internal Linkage to Frozen Linkage
### Removed interfaces

The following interfaces were removed from Gecko 1.9, which drives Firefox 3. If your extension makes use of any of these, you'll need to update your code:

* `nsIDOMPaintListener`
* `nsIDOMScrollListener`
* `nsIDOMMutationListener`
* `nsIDOMPageTransitionListener`
* `nsICloseAllWindows` (see Firefox bug 386200)
Step 4: Check for relevant chrome changes
-----------------------------------------

There have been a few changes to chrome layout that may affect some extensions.

### New boxes

There has been a minor change to the chrome that may require changes in your code. A new `vbox` has been added, called "browser-bottombox", which encloses the find bar and status bar at the bottom of the browser window. Although this doesn't affect the appearance of the display, it may affect your extension if it overlays chrome relative to these elements.

For example, if you previously overlaid some chrome before the status bar, like this:

```xml
<window id="main-window">
  <something insertbefore="status-bar" />
</window>
```

You should now overlay it like this:

```xml
<vbox id="browser-bottombox">
  <something insertbefore="status-bar" />
</vbox>
```

Or use the following technique to make your overlay work on both Firefox 2 and Firefox 3:

```xml
<window id="main-window">
  <vbox id="browser-bottombox" insertbefore="status-bar">
    <something insertbefore="status-bar" />
  </vbox>
</window>
```

### Changed boxes

Extensions that attempt to overlay onto the "appcontent" box try to float chrome over document content will no longer display that material. You should update your extension to use the new `<xul:panel>` XUL element. If you wish to keep the panel from automatically disappearing after a delay, you can set the `noautohide` attribute to `true`.

Other changes
-------------

*Add simple changes you had to make while updating your extension to work with Firefox 3 here.*

* `chrome://browser/base/utilityOverlay.js` is no longer supported for security reasons. If you were previously using this, you should switch to `chrome://browser/content/utilityOverlay.js`.
* `nsIAboutModule` implementations are now required to support the `getURIFlags` method. See nsIAboutModule.idl for documentation. This affects extensions that provide new `about:` URIs. (Firefox bug 337746)
* The `<xul:tabbrowser>` element is no longer part of "toolkit" (Firefox bug 339964). This means this element is no longer available to XUL applications and extensions. It continues to be used in the main Firefox window (browser.xul).
* Changes to `nsISupports_proxies` and possibly to threading-related interfaces need to be documented.
* If you use XML processing instructions, such as `<?xml-stylesheet ?>` in your XUL files, be aware of the changes made in Firefox bug 319654:
    1. XML PIs are now added to a XUL document's DOM. This means `document.firstChild` is no longer guaranteed to be the root element. If you need to get the root document in your script, use `document.documentElement` instead.
    2. `<?xml-stylesheet ?>` and `<?xul-overlay ?>` processing instructions now have no effect outside the document prolog.
* `window.addEventListener("load", myFunc, true)` is not fired when loading web content (browser page loads). This is due to Firefox bug 296639 which changes the way inner and outer windows communicate. The simple fix here is to use `gBrowser.addEventListener("load", myFunc, true)` as described here and works in Firefox 2 as well.
* `content.window.getSelection()` gives an object (which can be converted to a string by `toString()`), unlike the now deprecated `content.document.getSelection()` which returns a string
* `event.preventBubble()` was deprecated in Firefox 2 and has been removed in Firefox 3. Use `event.stopPropagation()`, which works in Firefox 2 as well.
* Timers that are initiated using `setTimeout()` are now blocked by modal windows due to the fix made for Firefox bug 52209. You may use `nsITimer` instead.
* If your extension needs to allow an untrusted source (e.g., a website) to access the extension's chrome, then you must use the new `contentaccessible` flag.


Full page zoom - Mozilla

Full page zoom
==============

Full page zoom (or just fullZoom) is a new feature in Firefox 3.

### Example (XUL:browser)

The following example demonstrates the use for the current focused browser window. This is the typical usage for a Firefox extension.

```js
var zoom = ZoomManager.getZoomForBrowser(gBrowser.selectedBrowser);
ZoomManager.enlarge();
ZoomManager.setZoomForBrowser(gBrowser.selectedBrowser, ZoomManager.MIN);
```

### Example (XUL:iframe)

Note: This is probably out of date.

You may use the fullZoom feature for a `<XUL:iframe>` as well. However, because an iframe doesn't have a markupDocumentViewer property, we need to get that first:

```js
var zoom = 1.5;
var iframe = document.getElementById("authorFrame");
var contViewer = iframe.docShell.contentViewer;
var docViewer = contViewer.QueryInterface(
  Components.interfaces.nsIMarkupDocumentViewer,
);
docViewer.fullZoom = zoom;
```

### References

* Page zoom extension by Ted Mielczarek fullpagezoom.xpi for latest Firefox 3.0 nightlies
* The bugzilla bug about fullZoom.
* `nsIMarkupDocumentViewer` Interface documentation.


Notable bugs fixed in Firefox 3 - Mozilla

Notable bugs fixed in Firefox 3
===============================

This article offers a list of important bug fixes offered by Firefox 3 that are not necessarily obvious in the documentation.

* if an error occurs parsing an overlay, the overlay is not applied. Parse errors are logged to the error console. (Firefox bug 335755)
* bug fixed where `<menupopup>` elements can be placed inside a binding when attached to a menu or menu-like element. (Firefox bug 345896)
* the button's `dlgType` property now works properly. (Firefox bug 308591)
* the `canBubble` argument to `event.initEvent` now works properly so that events can be fired which don't bubble. (Firefox bug 330190)
* the `DOMAttrModified` event now handles namespaced attributes properly. (Firefox bug 362391)
* XML processing instructions, such as `<?xml-stylesheet ?>`, are now added to a XUL document's DOM. This means `document.firstChild` isn't guaranteed to be the root element, use `document.documentElement` instead. Also, `<?xml-stylesheet ?>` and `<?xul-overlay ?>` processing instructions now have no effect outside the document prolog. (Firefox bug 319654)
* `getElementsByAttributeNS()` functions have been added to XUL elements and documents. (Firefox bug 239976)
* event listeners are maintained when moving or removing an element from a XUL document. (Firefox bug 286619)
* mutation events are now fired for non-displayed documents. (Firefox bug 201236)
* various issues with elements drawing in the wrong order are fixed. (Firefox bug 317375)
* `getElementsByTagName()` has been fixed to work correctly on subtrees that have elements with namespace prefixes in their tag names (Firefox bug 206053).
* The `DOMNodeInserted` and `DOMNodeRemoved` events now properly apply to the correct nodes (Firefox bug 367164).
* `\d`, one of special characters in regular expressions, has been fixed to match only Basic Latin alphabet digits (equivalent to `[0-9]`). (Firefox bug 378738)
* The image-sniffing-services category allows for image decoders implemented as extensions to correctly decode images sent with incorrect mime-types. (Firefox bug 391667)
* Right-clicks on form controls no longer brings up a context menu by default (Firefox bug 404536. See Offering a context menu for form controls to learn how to enable this on a case-by-case basis.
### See also

* Firefox 3 for developers


Templates in Firefox 3 - Mozilla

Templates in Firefox 3
======================

Templates have been significantly improved in Firefox 3. The key improvement allows the use of custom query processors to handle other types of datasources besides RDF. A new query syntax makes this possible. Built-in support for SQL (mozStorage) and XML datasources is also provided. A full description of the new features available for templates is available. (Firefox bug 285631)

### Other template improvements

* Relational conditions have been added to allow for more precise control over what results match a rule. This allows, for example, matching of results that start or end with certain strings, or that are before or after other values.
* A flag, `dont-recurse`, has been added to prevent recursion from happening such that only one level of results are generated
* APIs have been added to the template builder to retrieve a result object representing an output item.
* The XUL sort service is more robust and sorts both content and non-content trees better. It also allows sorting of non-template built content. (Firefox bug 335122)
### See also

* Firefox 3 for developers


WAI ARIA Live Regions/API Support - Mozilla

WAI ARIA Live Regions/API Support
=================================

**Warning:** These notes are for developers of screen readers. Developers should use the ARIA live regions developer documentation.

Firefox 3 contains important improvements to the way the Mozilla engine exposes live changes in a document.

These features will help screen reader developers improve the quality and performance of live region support, both for pages that are marked up with ARIA live region markup, and for pages where the author did not add any additional markup.

As always, we're open to questions and suggestions for changes in community forums.

Events fired for web page mutations
-----------------------------------

| What changed in document? | ATK/AT-SPI event | IAccessible2 event |
| --- | --- | --- |
| Object about to be hidden or removed | children\_changed::remove (fired on the parent, with event data pointing to the child index of the accessible object to be removed) | EVENT\_OBJECT\_HIDE\* (fired on the actual accessible object about to go away) |
| Object shown or inserted | children\_changed::add (fired on the parent, with event data pointing to the child index of the inserted accessible object) | EVENT\_OBJECT\_SHOW\* (fired on the actual new accessible object) |
| Object replaced with different object (this happens especially if an object's interfaces or role changes) | children\_changed::remove followed immediately by children\_change::add | EVENT\_OBJECT\_HIDE followed immediately by EVENT\_OBJECT\_SHOW |
| Text removed | text\_changed::delete | IA2\_EVENT\_TEXT\_REMOVED (use IAccessibleText::get\_oldText to retrieve the offsets and removed text) |
| Text inserted | text\_changed::insert | IA2\_EVENT\_TEXT\_INSERTED (use IAccessibleText::get\_newText to retrieve the offsets and inserted text) |
| Text replaced | text\_changed::delete followed immediately by text\_changed::insert | IA2\_EVENT\_TEXT\_REMOVED followed immediately by IA2\_EVENT\_TEXT\_INSERTED |

\* We do not use MSAA's CREATE/DESTROY at the request of screen reader vendors, who avoid those events because they cause crashes on some important system — SHOW/HIDE are the equivalent of those events.

Retrieving author-supplied ARIA live region semantics from an event
-------------------------------------------------------------------

For any mutation event in a page, the author can get the following object attributes from the event object, if they are defined on some ancestor element (closest ancestor wins):

| Object attribute name | Possible values | Default value | ARIA markup if required | Meaning |
| --- | --- | --- | --- | --- |
| `container-live` | `"off" | "polite" | "assertive"` | `"off"` | `aria-live` on ancestor element | Interruption |
| `container-relevant` | `'additions'` `'removals'` `'text' | "all"` | `"additions text"` | `aria-relevant` on ancestor element | What types of mutations are possibly relevant? See section to match the type of event with this attribute's value, to determine whether the author believed the event should be presented to the user or not. |
| `container-busy` | `"true" | "false" | "error"` | `"false"` | `aria-busy` on ancestor element | The current changes are not yet complete. A state change event for the A11y API's BUSY state will be fired on the container object currently marked as BUSY, once it is no longer BUSY. This is especially important in atomic regions. The entire atomic region should be presented once when it is finally no longer BUSY. |
| `container-atomic` | `"true" | "false"` | `"false"` | `aria-atomic` on ancestor element | Is this change inside a region that should always be presented at once. If yes, member-of relation will point to the root of the region (see next section) |
| `member-of` | If `container-atomic=true`, points to an ancestor accessible object (thus it is actually an accessible relation, not object attribute) | Not in atomic region if not provided | `aria-atomic` on ancestor element | Points to the root of the atomic container that this object is in. This will always be an ancestor of the current object. |
| `event-from-input` | `"true" | "false"` (described more below) | Browser could not calculate this | Does not require author's cooperation. | Was the root cause of this event explicit user input? |

The "container-" prefix is so named because the attribute describes what the final computed property of similar name is for that node. This means that the AT does not need to traverse up the parent chain to get this information. At this time, for properties where the `container-`*name* attribute has not been set, the AT must have code to fall back on the default value as defined in the W3C spec.

Determining if event was from user input
----------------------------------------

All events will now provide information about whether the event was caused by user input, or was something that the web page caused. This information is retrieved differently on each platform, because some platforms use asynchronous events.

In IAccessible2, this is retrieved from the object attribute "event-from-input", which will be set to "true" or "false". If it is not present, then something went wrong and Mozilla was not able to provide this information. This information is available only for EVENT\_SHOW, EVENT\_HIDE, IA2\_EVENT\_TEXT\_INSERTED and IA2\_EVENT\_TEXT\_REMOVED.

For ATK/AT-SPI, this information is retrieved by checking the event name. If the event name has ":system" appended to it, then it is /not/ from user input. The ":system" string is calculated for children-changed and text-changed events.

Why is this useful? The majority of AJAX pages do not provide live region markup, but still need to be as usable as possible. It is difficult for a screen reader to decide when to interrupt a user with changes on a page. If the screen reader automatically reads too much, then the web page will be too annoying to use. If the screen reader doesn't read anything, then the user may miss important information.

It is believed this information will be useful for heuristics. Often, changes in a page that are directly caused by a user's keystrokes should be read. They are synchronous with what the user is doing and can thus likely be read without disorienting the user. Once the user presses the next key the speech will move on to echoing that key anyway. The screen reader may wish to take other factors into account, such as the type of change, the size of the change, where the change occurred, etc. This is a potential area for innovation in screen readers.

| Most recent occurrence | User input? |
| --- | --- |
| Key presses | Yes |
| Mouse clicks | Yes |
| Mouse hovers | No |
| Page load events | No |

Everything else, including focus changes, timer callbacks, XMLHttpRequest callbacks, etc. are neutral. They are only counted as user input if the original reason they happened was because of user input.

What Should Screen Readers Present?
-----------------------------------

Please read the live region section of the WAI-ARIA Screen Reader Implementor's Guide.


Updating add-ons for Firefox 9 - Mozilla

Updating add-ons for Firefox 9
==============================

Firefox 9 doesn't have a lot of changes that should be compatibility issues for add-on developers. However, there are a few possible items that might trip you up, so let's take a look.

Do you need to do anything at all?
----------------------------------

If your add-on is distributed on addons.mozilla.org (AMO), it's been checked by an automated compatibility verification tool. Add-ons that don't use APIs that changed in Firefox 8, and have no binary components (which need to be recompiled for every major Firefox release), have automatically been updated on AMO to indicate that they work in Firefox 9.

So you should start by visiting AMO and looking to see if your add-on needs any work done at all.

**Note:** You should still test your add-on on Firefox 9, even if it's been automatically upgraded. There are edge cases that may not be automatically detected.

Once you've confirmed that you need to make changes, come on back to this page and read on.

Bootstrapped add-ons can remove delayed-load scripts
----------------------------------------------------

If your add-on uses `nsIChromeFrameMessageManager.loadFrameScript()` with the delayed-load flag set, the script gets loaded into every frame created from that point on. This is great, except that until Firefox 9, there was no way to stop loading the script, so it would keep happening even after your add-on was shut down.

Starting in Firefox 9, you should call the new `nsIChromeFrameMessageManager.removeDelayedFrameScript()` method to stop loading your script in newly-created frames. You do this like this, for example:

```js
browser.messageManager.removeDelayedFrameScript(
  "chrome://myextension/content/somescript.js",
);
```

Interface changes
-----------------

* The `nsIURL` interface has been changed a bit. The `nsIURL.param` attribute was removed, and the `nsIURLParser.parsePath()` method has two fewer arguments than it did previously.
* Two methods have been removed from `nsIBrowserHistory`: `registerOpenPage()` and `unregisterOpenPage()`. These methods had been deprecated.
* The `nsIEditorSpellCheck.saveDefaultDictionary()` method has been removed as part of supporting per-site spell check settings. Also, `nsIEditorSpellCheck.updateCurrentDictionary()` no longer takes a parameter.
* The `nsIGlobalHistory3` interface has been removed. Its functionality was of limited (if any) use to add-ons, so this shouldn't affect anyone.
* Several specialized channels' properties attributes have been merged into the base `nsIChannel` interface. This shouldn't affect compatibility at all, since those interfaces inherit from `nsIChannel` anyway.
Preference changes
------------------

The `geo.wifi.*` preferences no longer have default values, although they're honored if they exist. If your code reads these without handling the case where they don't exist, you need to update your code to handle the exception that gets thrown when they're not present.

XPConnect changes
-----------------

`nodePrincipal` and `baseURIObject` have been moved from `nsDOMClassInfo` to `XrayWrapper`. This shouldn't affect many add-ons, since it would only be an issue if they try to access these properties on DOM `Node` objects from unprivileged script that have requested XPConnect privileges using `enablePrivilege()`.

DOM changes
-----------

* The long-obsolete method `Navigator.taintEnabled()` has been removed. This hasn't done anything useful in a very long time, but was often used in browser detection scripts, since it was Netscape-specific. Calling this method throws an exception starting in Firefox 9.
* Event handlers are now implemented as standard IDL interfaces. For most cases, this won't affect you, but there are exceptions.
Other changes that may affect binary compatibility
--------------------------------------------------

These changes are notable in that they may affect binary XPCOM components. These will need rebuilding anyway, since that's required for every major release of Firefox, but could introduce compile-time errors, so they're worth noting in particular.

* The `nsIDOMHTMLDocument` interface now has a new `scripts` attribute, which implements the `Document.scripts` attribute.
* The `nsIJumpListShortcut.iconImageUri()` method has been added, to make it possible to establish favicons on jump list URI entries on Windows.
Theme changes
-------------

The `pending` attribute has been added to the `<tab>` element. If this attribute is present, the tab is in the process of being restored by the session store service. You can use that to style the tab during the restore process. It's worth noting that if the user has turned on the "Don't load tabs until selected" preference, the `pending` attribute is set on tabs until they get loaded.

Similarly, tabs also now have an `unread` attribute; this property, if present, indicates that the tab has changed since the last time it was the active tab. You can use this to style tabs differently when they have changed since the last time the user looked at them. This is also present on tabs that have not yet been looked at during the current session.


Updating extensions for Firefox 4 - Mozilla

Updating extensions for Firefox 4
=================================

This article offers details on changes in Firefox 4 that may impact existing extensions.

User interface changes
----------------------

### The status bar

The status bar has been removed from Firefox 4, with a new add-on bar added in its place. See The add-on bar for details.

### Toolbars

#### Creating toolbars

If your add-on creates a new toolbar using an overlay, your toolbar may not show up. This happens when your `<toolbox>` element overlay is a child of the `<window>` element instead of a direct child of the overlay element. Move the toolbox out of the window element to fix this problem.

### The Firefox application menu

On Windows, the menu bar is now hidden by default. Instead, there's a single button that opens a simplified Firefox application menu. This menu includes the most used menu features, which makes the application easier to use. The menu bar can still be accessed by pressing the Alt key.

If your add-on is discoverable only through the menu bar, you'll want to overlay the application menu as well. There isn't a specific place to put extension menu items, so you should take a look at the menu and select the right place for your particular extension.

### Tabs

A number of changes were made to the `<tabbrowser>` element to help support app tabs and Panoramas, as well as to make the tab bar into a standard toolbar. Other changes that may break existing extensions include:

* The `TabClose`, `TabSelect`, and `TabOpen` events no longer bubble up to the `<tabbrowser>` element (`gBrowser`). Event listeners for those events should be added to `gBrowser.tabContainer` rather than to `gBrowser` directly.
* The tab context menu is no longer an anonymous child of the `<tabbrowser>`. It can therefore be overlaid directly with XUL overlays. It can also be accessed more directly in JavaScript via `gBrowser.tabContextMenu`. See this blog post for more details.
XPCOM changes
-------------

Several changes have been made that affect add-ons and applications that include XPCOM components. See XPCOM changes in Gecko 2 for details.

The Add-on Manager
------------------

The overhauled Add-on Manager is implemented as a tab instead of in a separate window. Among the changes that affect your browser from a user experience perspective is that your add-on's icon can be 64x64 pixels now instead of 32x32. While 32x32 pixel icons still work, obviously your add-on will look better if it provides a 64x64 pixel icon instead. Fortunately, 64x64 icons are backward compatible and scale down well, so you can just switch instead of needing both sizes.

In addition, the back-end of the Add-on Manager was redesigned. The `nsIExtensionManager` interface is gone, as is the old RDF-based storage it used. Add-on metadata is now stored in an SQLite database, and the Add-on Manager is now a JavaScript code module called AddonManager.

A key difference with the new API is that requesting add-on metadata is now asynchronous instead of synchronous; this applies to add-ons using FUEL as well, so all add-ons that request metadata about add-ons will need to be updated.

Threading
---------

You can no longer pass JavaScript objects between threads. This renders the Thread Manager mostly useless for add-on developers, unfortunately, and there aren't at this time many alternatives. It's possible that in the future the `ChromeWorker` will be improved to fill the void.

Network redirects
-----------------

The API for handling network redirects has been changed to be asynchronous; any add-ons registering in the "net-channel-event-sinks" category will need to be updated to use the new API `asyncOnChannelRedirect`.

XPI unpacking
-------------

Firefox 4 no longer extracts XPIs when installing extensions. It just places the XPI file in the user profile, and then reads the chrome files and others directly out of the XPI. A jar inside the XPI still works, but is no longer necessary, so that can make your development or build easier. This was done mainly for performance reasons on slow OSes, and allows better cache invalidation, which also helps developers. However, not all kinds of files can be read from within the XPI yet, so if your extension uses one of those, you need to specify `<em:unpack>` in your install.rdf to cause Firefox to still extract your XPI and use single files, otherwise your extension will fail when trying to access these files.

If your extension only contains these types of files then you do not need to make any changes:

* `install.rdf`
* `chrome.manifest`
* `chrome` (including `content`, `locale`, `skin`)
* default preferences
* XPCOM components written in JavaScript

If your extension contains any of the following then you will need to include `<em:unpack>` in the install.rdf:

* Binary XPCOM components
* Shared libraries loaded with ctypes
* `searchplugins/` (which are supposed to be loaded automatically by Firefox)
* `dictionaries/`
* Window icons (might get fixed)

If your extension code accesses other files that you have packaged in the XPI then you will either need to include `<em:unpack>` in the install.rdf or you may be able to support packed installation by making some changes to your code. Any code that used getInstallLocation() and nsIFile will either need em:unpack or needs to be changed. You can use the method `Addon.getResourceURI()`, it will return an `nsIURI` pointing to the requested file. If the extension is unpacked then it will be a `file://` URI. If the extension is packed then it will be a `jar://` URI. You can open streams to these URIs by opening a channel using the `nsIIOService` which will allow you to load the files contents without any unpacking.

Child HWNDs have been removed
-----------------------------

This should only affect a very small number of developers. In previous versions of Firefox, child `HWND`s were created on Windows for internal use. As a part of the work toward improving graphics performance, these are no longer created.

Unfortunately, a few extensions have been getting access to these `HWND`s and manipulating them directly; these extensions will no longer work in Firefox 4. We have put a few hacks in place to help certain pointing-device drivers and assistive technology software (screen readers, for example). However, we have decided against adding even more hacks to support extensions, which should never have been doing this in the first place.

If you maintain an extension that uses native components that rely on `HWND`s that no longer exist, you'll need to update your extension. There are two ways to do this.

The first, and better, solution is to stop accessing `HWND`s and instead use Web features or XUL to implement your extension. There are a lot of new features in Firefox 4 that make possible a lot of things that used to require native code, so you may no longer need to do this.

If you find that this doesn't work, and you still need to directly access `HWND`s, you may find that your only solution is to write an NPAPI plugin that does the work. This may be a lot of work, but it should work. Of course, this may not help you if the specific `HWND`s you were using no longer exist.

Development and testing tips
----------------------------

### Caching

Because Firefox now caches code and other resources more aggressively, you'll want to be sure to purge the caches when you start up Firefox 4. Otherwise you may be testing obsolete pieces of your add-on. To do this, run Firefox with the `-purgecaches` command line option.

### The Profile Manager

The old Profile Manager tool will be getting removed from Firefox 4, although it hasn't been yet. This tool hasn't been updated for a long time and is missing features. On top of that, its presence is slowing down application startup.

A replacement to the profile manager is available. (See also Firefox bug 539524). This new tool is independent of the browser itself, and more robust than the old Profile Manager.

### Installing extensions globally

The `-install-global-extension` and `-install-global-theme` command line options have been removed. Handling global installation has always been complicated, and discussions are in progress as to how to address the subject going forward. In the meantime, see Installing extensions for information on ways to automatically install add-ons.

See also
--------

* Making Your Add-on Compatible with Firefox 4 (blog post)


The add-on bar - Mozilla

The add-on bar
==============

Firefox 4 eliminates the status bar from the bottom of the browser window in favor of a new toolbar located at the bottom of the window. This new toolbar, with the ID "addon-bar", is a standard XUL `<toolbar>`; add-ons can insert content into it, and the user can drag buttons into it while customizing their toolbars. This is the primary difference between the add-on bar and the old status bar; you can now put any XUL element into it, since it's a standard toolbar.

**Note:** For the time being, there is a status bar shim included so that add-ons that expect the status bar to be present will still work.

Adding an element to the add-on bar
-----------------------------------

The add-on bar is an XUL toolbar with the ID "addon-bar". The code below locates the most-recently used window and adds a new item to the add-on bar that displays the text "Hello world!" using an XUL `<label>` element.

```js
// Find the most recently used window

var mediator = Components.classes[
  "@mozilla.org/appshell/window-mediator;1"
].getService(Components.interfaces.nsIWindowMediator);
var doc = mediator.getMostRecentWindow("navigator:browser").document;

// Get the add-on bar for that window

var addonBar = doc.getElementById("addon-bar");

// Construct the new toolbar item

var newItem = doc.createElement("toolbaritem");
var itemLabel = doc.createElement("label");

// Add the item to the toolbar and set its text label

newItem.appendChild(itemLabel);
addonBar.appendChild(newItem);
itemLabel.value = "Hello world!";
```

To add the button only once, create a bool pref to check if it is the first run. For example:

```js
var firstrun = Services.prefs.getBoolPref("extensions.YOUREXT.firstrun");

var curVersion = "0.0.0";

if (firstrun) {
  Services.prefs.setBoolPref("extensions.YOUREXT.firstrun", false);
  Services.prefs.setCharPref("extensions.YOUREXT.installedVersion", curVersion);
  /\* Code related to firstrun \*/
} else {
  try {
    var installedVersion = Services.prefs.getCharPref(
      "extensions.YOUREXT.installedVersion",
    );
    if (curVersion > installedVersion) {
      Services.prefs.setCharPref(
        "extensions.YOUREXT.installedVersion",
        curVersion,
      );
      /\* Code related to upgrade \*/
    }
  } catch (ex) {
    /\* Code related to a reinstall \*/
  }
}
```

How to use one overlay per Firefox version
------------------------------------------

Adding support for the add-on bar while staying compatible with Firefox 3.6 and older will require using two overlays. The chrome.manifest file can specify which file is used by which Firefox version by using manifest flags:
```

overlay chrome://browser/content/browser.xul chrome://myaddon/content/myaddon/overlayold.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384} appversion<4.0
overlay chrome://browser/content/browser.xul chrome://myaddon/content/myaddon/overlay.xul application={ec8030f7-c20a-464f-9b0e-13a3a9e97384} appversion>=4.0
```

Note: the appversion has to be at least 2 digits long or it won't work with versions of Gecko before 1.8.0.13 and 1.8.1.5.

### Adding a button by default

See: Adding a button by default

Appearance differences
----------------------

* Since the browser no longer occupies a large percentage of the bar with status information, the entire area is available for add-ons to use.
* The add-on bar is empty and hidden by default; the user must elect to make it visible.
* If a restartless add-on installs itself to the add-on bar directly and the bar is not already visible, the bar becomes visible automatically.
* If uninstalling a restartless add-on makes the number of items in the add-on bar become zero, the bar is hidden automatically.
See also
--------

* The Firefox 4 add-on bar for developers, by Mike Kaply


Updating plug-ins for Firefox 3.6 - Mozilla

Updating plug-ins for Firefox 3.6
=================================

Several changes were made in Gecko 1.9.2 that may impact plug-in developers in particular. This article provides a list of those changes.

Interface changes
-----------------

The `nsIPluginInstance` method `destroy()` has been removed, since it wasn't doing anything anyway.

Mac OS X specific changes
-------------------------

### CFM plug-ins no longer supported

Starting with Gecko 1.9.2, old-style CFM (Code Fragment Manager) binaries are no longer supported for plug-ins. CFM plug-ins have been deprecated since August, 2008.

### main() no longer a supported entry point

In August, 2008, plug-in developers were informed that `main()` would no longer be supported as an entry point. This change has taken effect in Gecko 1.9.2. Plug-ins need to be updated to use `NPN_GetEntryPoints()` instead.

See also
--------

* Firefox 3.6 for developers


Updating extensions for Firefox 3.6 - Mozilla

Updating extensions for Firefox 3.6
===================================

This article provides helpful information to extension developers trying to update their extensions to work properly in Firefox 3.6.

User interface changes
----------------------

Right-clicking on elements (including links and images) no longer offers a "Properties" menu item. The properties dialog box was not useful for most users and has been removed. If your extension interacts with that menu item in any way, you'll need to revise your code to add it yourself, or contribute your own context menu entry directly.

Add-on package changes
----------------------

In order to allow add-ons' icons to be displayed even when they're disabled, Gecko 1.9.2 added support for automatically detecting and using an icon named `icon.png`, located in the add-on's root directory. This is used if the add-on is disabled, or if the manifest is missing an `iconURL` entry.

HTML 5 compliance improvements
------------------------------

The DOM Level 2 views to HTML and XHTML documents are now unified per HTML 5.

* The `localName` DOM property now returns the name of HTML element nodes in lower case. Previously, in HTML documents, it returned it in upper case. (DOM Level 1 `tagName` continues to return in upper case in HTML documents.)
* The `namespaceURI` DOM property now returns `"http://www.w3.org/1999/xhtml"` on HTML element nodes. Previously, in HTML documents, it returned `null`.
* `document.createElementNS(null, "FOO")` no longer creates an HTML element node in HTML documents. `document.createElement("FOO")`
 or `document.createElementNS("http://www.w3.org/1999/xhtml", "foo")` continue
 to work in HTML documents.
* The `name` and the `local-name` functions in XPath returns the name of HTML elements in lower case. Previously, in HTML documents, they returned it in upper case.

The most probable upgrade problem is the pattern `if (elt.localName === "FOO")`.

### Example: Testing if an element is an HTML img element

#### Firefox 3.6, both text/html and application/xhtml+xml

`if (elt.localName === "img" && elt.namespaceURI === "http://www.w3.org/1999/xhtml")`

#### Firefox 3.5 and 3.6, only extension-supplied text/html without foreign (e.g. SVG) script-inserted elements

`if (elt.tagName === "IMG")`

#### Firefox 3.5 and 3.6, both text/html and application/xhtml+xml

`if (elt instanceof HTMLImageElement)`

contents.rdf no longer supported
--------------------------------

Support for the obsolete `contents.rdf` method for registering chrome has been removed in Gecko 1.9.2, and is no longer supported by Firefox 3.6. This means that add-ons that use contents.rdf can no longer be installed.

Make sure you include a chrome.manifest in your XPI.

**Note:** Add-ons that are already installed using the old contents.rdf method for registering chrome will continue to function if already installed. Make sure that you test your add-on by actually removing and reinstalling it to ensure that the install works after updating it to use an install manifest.


Updating themes for Firefox 3.6 - Mozilla

Updating themes for Firefox 3.6
===============================

This article intends to help theme authors update Firefox-3.5-compatible themes for Firefox 3.6 compatibility.

Chrome registration change
--------------------------

`contents.rdf` is not supported anymore, you need to use `chrome.manifest` instead.

Emptytext styling
-----------------

XUL textboxes don't have the `empty` attribute anymore, but `isempty` instead. So instead of `textbox[empty="true"]`, you need to use `textbox[isempty="true"]`.

Right-to-left UI support
------------------------

The `[chromedir="rtl"]` and `[chromedir="ltr"]` selectors have been obsoleted and won't work anymore on most elements. Instead, you need to use the new `:-moz-locale-dir_rtl` and `:-moz-locale-dir_ltr` selectors. See also: Making sure your theme works with RTL locales.

Cross-platform tabbed browser styling
-------------------------------------

The tabbed browser implementation no longer has a Mac-specific `tabs-closebutton-box`; instead, all platforms use the same names to identify the components of the tab strip.

Full Screen toolbar button
--------------------------

There's a new Full Screen toolbar button available from the Customize Toolbar dialog.

See also
--------

* MozillaZine forum: Mozilla 1.9.2 / Firefox 3.6 theme changes
* Themes
* Building a theme


Interfaces moved in Firefox 3.6 - Mozilla

Interfaces moved in Firefox 3.6
===============================

 These interfaces were moved to new locations in the tree in Gecko 1.9.2.
 This is generally only interesting to people doing development on Mozilla itself.

Moved DOM interfaces
--------------------

The following interfaces were moved from `dom/public/idl/base/` to `dom/interfaces/base/`:

| From | To |
| --- | --- |
| `nsIBrowserDOMWindow` | `nsIDOMBarProp` |
| `nsIDOMCRMFObject` | `nsIDOMChromeWindow` |
| `nsIDOMClientInformation` | `nsIDOMClientRect` |
| `nsIDOMClientRectList` | `nsIDOMConstructor` |
| `nsIDOMCrypto` | `nsIDOMHistory` |
| `nsIDOMJSWindow` | `nsIDOMLocation` |
| `nsIDOMMimeType` | `nsIDOMMimeTypeArray` |
| `nsIDOMModalContentWindow` | `nsIDOMNSFeatureFactory` |
| `nsIDOMNavigator` | `nsIDOMPkcs11` |
| `nsIDOMPlugin` | `nsIDOMPluginArray` |
| `nsIDOMScreen` | `nsIDOMWindow` |
| `nsIDOMWindow2` | `nsIDOMWindowCollection` |
| `nsIDOMWindowInternal` | `nsIDOMWindowUtils` |

The following interfaces moved from `dom/public/idl/core/` to `dom/interfaces/core/`:

| From | To |
| --- | --- |
| `nsIDOM3Attr` | `nsIDOM3Document` |
| `nsIDOM3Node` | `nsIDOM3Text` |
| `nsIDOM3TypeInfo` | `nsIDOMAttr` |
| `nsIDOMCDATASection` | `nsIDOMCharacterData` |
| `nsIDOMComment` | `nsIDOMDOMConfiguration` |
| `nsIDOMDOMError` | `nsIDOMDOMErrorHandler` |
| `nsIDOMDOMException` | `nsIDOMDOMImplementation` |
| `nsIDOMDOMLocator` | `nsIDOMDOMStringList` |
| `nsIDOMDocument` | `nsIDOMDocumentFragment` |
| `nsIDOMDocumentType` | `nsIDOMElement` |
| `nsIDOMEntity` | `nsIDOMEntityReference` |
| `nsIDOMNSDocument` | `nsIDOMNSEditableElement` |
| `nsIDOMNSElement` | `nsIDOMNameList` |
| `nsIDOMNamedNodeMap` | `nsIDOMNode` |
| `nsIDOMNodeList` | `nsIDOMNodeSelector` |
| `nsIDOMNotation` | `nsIDOMProcessingInstruction` |
| `nsIDOMText` | `nsIDOMUserDataHandler` |
| `nsIDOMXMLDocument` |  |

These interfaces moved from `dom/public/idl/css/` to `dom/interfaces/css/`:

| From | To |
| --- | --- |
| `nsIDOMCSS2Properties` | `nsIDOMCSSCharsetRule` |
| `nsIDOMCSSFontFaceRule` | `nsIDOMCSSImportRule` |
| `nsIDOMCSSMediaRule` | `nsIDOMCSSMozDocumentRule` |
| `nsIDOMCSSPageRule` | `nsIDOMCSSPrimitiveValue` |
| `nsIDOMCSSRule` | `nsIDOMCSSRuleList` |
| `nsIDOMCSSStyleDeclaration` | `nsIDOMCSSStyleRule` |
| `nsIDOMCSSStyleSheet` | `nsIDOMCSSUnknownRule` |
| `nsIDOMCSSValue` | `nsIDOMCSSValueList` |
| `nsIDOMCounter` | `nsIDOMDocumentCSS` |
| `nsIDOMElementCSSInlineStyle` | `nsIDOMNSCSS2Properties` |
| `nsIDOMNSRGBAColor` | `nsIDOMRGBColor` |
| `nsIDOMRect` | `nsIDOMViewCSS` |

The following interfaces moved from `dom/public/idl/events/` to `dom/interfaces/events/`:

| From | To |
| --- | --- |
| `nsIDOM3DocumentEvent` | `nsIDOM3EventTarget` |
| `nsIDOMBeforeUnloadEvent` | `nsIDOMCommandEvent` |
| `nsIDOMDataContainerEvent` | `nsIDOMDataTransfer` |
| `nsIDOMDocumentEvent` | `nsIDOMDragEvent` |
| `nsIDOMEvent` | `nsIDOMEventGroup` |
| `nsIDOMEventListener` | `nsIDOMEventTarget` |
| `nsIDOMKeyEvent` | `nsIDOMMessageEvent` |
| `nsIDOMMouseEvent` | `nsIDOMMouseScrollEvent` |
| `nsIDOMMutationEvent` | `nsIDOMNSEvent` |
| `nsIDOMNSEventTarget` | `nsIDOMNSMouseEvent` |
| `nsIDOMNSUIEvent` | `nsIDOMNotifyPaintEvent` |
| `nsIDOMPageTransitionEvent` | `nsIDOMPopupBlockedEvent` |
| `nsIDOMProgressEvent` | `nsIDOMSimpleGestureEvent` |
| `nsIDOMSmartCardEvent` | `nsIDOMUIEvent` |

These interfaces moved from `dom/public/idl/geolocation/` to `/dom/interfaces/geolocation/`:

| From | To |
| --- | --- |
| `nsIDOMGeoGeolocation` | `nsIDOMGeoPosition` |
| `nsIDOMGeoPositionCallback` | `nsIDOMGeoPositionCoords` |
| `nsIDOMGeoPositionError` | `nsIDOMGeoPositionErrorCallback` |
| `nsIDOMGeoPositionOptions` | `nsIDOMNavigatorGeolocation` |
| `nsIGeolocationProvider` | `nsIGeolocationProvider` |

These interfaces moved from `dom/public/idl/html/` to `/dom/interfaces/html/`:

| From | To |
| --- | --- |
| `nsIDOMHTMLAnchorElement` | `nsIDOMHTMLAppletElement` |
| `nsIDOMHTMLAreaElement` | `nsIDOMHTMLAudioElement` |
| `nsIDOMHTMLBRElement` | `nsIDOMHTMLBaseElement` |
| `nsIDOMHTMLBaseFontElement` | `nsIDOMHTMLBodyElement` |
| `nsIDOMHTMLButtonElement` | `nsIDOMHTMLByteRanges` |
| `nsIDOMHTMLCanvasElement` | `nsIDOMHTMLCollection` |
| `nsIDOMHTMLDListElement` | `nsIDOMHTMLDirectoryElement` |
| `nsIDOMHTMLDivElement` | `nsIDOMHTMLDocument` |
| `nsIDOMHTMLElement` | `nsIDOMHTMLEmbedElement` |
| `nsIDOMHTMLFieldSetElement` | `nsIDOMHTMLFontElement` |
| `nsIDOMHTMLFormElement` | `nsIDOMHTMLFrameElement` |
| `nsIDOMHTMLFrameSetElement` | `nsIDOMHTMLHRElement` |
| `nsIDOMHTMLHeadElement` | `nsIDOMHTMLHeadingElement` |
| `nsIDOMHTMLHtmlElement` | `nsIDOMHTMLIFrameElement` |
| `nsIDOMHTMLImageElement` | `nsIDOMHTMLInputElement` |
| `nsIDOMHTMLIsIndexElement` | `nsIDOMHTMLLIElement` |
| `nsIDOMHTMLLabelElement` | `nsIDOMHTMLLegendElement` |
| `nsIDOMHTMLLinkElement` | `nsIDOMHTMLMapElement` |
| `nsIDOMHTMLMediaElement` | `nsIDOMHTMLMediaError` |
| `nsIDOMHTMLMenuElement` | `nsIDOMHTMLMetaElement` |
| `nsIDOMHTMLModElement` | `nsIDOMHTMLOListElement` |
| `nsIDOMHTMLObjectElement` | `nsIDOMHTMLOptGroupElement` |
| `nsIDOMHTMLOptionElement` | `nsIDOMHTMLOptionsCollection` |
| `nsIDOMHTMLParagraphElement` | `nsIDOMHTMLParamElement` |
| `nsIDOMHTMLPreElement` | `nsIDOMHTMLQuoteElement` |
| `nsIDOMHTMLScriptElement` | `nsIDOMHTMLSelectElement` |
| `nsIDOMHTMLSourceElement` | `nsIDOMHTMLStyleElement` |
| `nsIDOMHTMLTableCaptionElem` | `nsIDOMHTMLTableCellElement` |
| `nsIDOMHTMLTableColElement` | `nsIDOMHTMLTableElement` |
| `nsIDOMHTMLTableRowElement` | `nsIDOMHTMLTableSectionElem` |
| `nsIDOMHTMLTextAreaElement` | `nsIDOMHTMLTimeRanges` |
| `nsIDOMHTMLTitleElement` | `nsIDOMHTMLUListElement` |
| `nsIDOMHTMLVideoElement` | `nsIDOMHTMLVoidCallback` |
| `nsIDOMNSHTMLAnchorElement` | `nsIDOMNSHTMLAnchorElement2` |
| `nsIDOMNSHTMLAreaElement` | `nsIDOMNSHTMLAreaElement2` |
| `nsIDOMNSHTMLButtonElement` | `nsIDOMNSHTMLDocument` |
| `nsIDOMNSHTMLElement` | `nsIDOMNSHTMLFormControlList` |
| `nsIDOMNSHTMLFormElement` | `nsIDOMNSHTMLFrameElement` |
| `nsIDOMNSHTMLHRElement` | `nsIDOMNSHTMLImageElement` |
| `nsIDOMNSHTMLInputElement` | `nsIDOMNSHTMLOptionCollectn` |
| `nsIDOMNSHTMLOptionElement` | `nsIDOMNSHTMLSelectElement` |
| `nsIDOMNSHTMLTextAreaElement` | `nsIDOMNSXBLFormControl` |

The following interfaces were moved from `dom/public/idl/json/` to `dom/interfaces/json/`:

| From | To |
| --- | --- |
| `nsIJSON` | `nsIJSON` |

The following interfaces were moved from `dom/public/idl/ls/` to `dom/interfaces/load-save/`:

| From | To |
| --- | --- |
| `nsIDOMDOMImplementationLS` | `nsIDOMLSException` |
| `nsIDOMLSInput` | `nsIDOMLSLoadEvent` |
| `nsIDOMLSOutput` | `nsIDOMLSParser` |
| `nsIDOMLSParserFilter` | `nsIDOMLSProgressEvent` |
| `nsIDOMLSResourceResolver` | `nsIDOMLSSerializer` |
| `nsIDOMLSSerializerFilter` | `nsIDOMLSSerializerFilter` |

The following interfaces moved from `dom/public/idl/offline/` to `dom/interfaces/offline/`:

| From | To |
| --- | --- |
| `nsIDOMLoadStatus` | `nsIDOMLoadStatusEvent` |
| `nsIDOMOfflineResourceList` | `nsIDOMOfflineResourceList` |

These interfaces moved from `dom/public/idl/range/` to `dom/interfaces/range/`:

| From | To |
| --- | --- |
| `nsIDOMDocumentRange` | `nsIDOMNSRange` |
| `nsIDOMRange` | `nsIDOMRangeException` |

This interface moved from `dom/public/idl/smil` to `dom/interfaces/smil/`:

| From | To |
| --- | --- |
| `nsIDOMElementTimeControl` | `nsIDOMElementTimeControl` |

The following interfaces moved from `dom/public/idl/storage/` to `dom/interfaces/storage/`:

| From | To |
| --- | --- |
| `nsIDOMStorage` | `nsIDOMStorageEvent` |
| `nsIDOMStorageItem` | `nsIDOMStorageList` |
| `nsIDOMStorageManager` | `nsIDOMStorageWindow` |
| `nsIDOMToString` | `nsIDOMToString` |

The following interfaces moved from `dom/public/idl/stylesheets/` to `dom/interfaces/stylesheets/`:

| From | To |
| --- | --- |
| `nsIDOMDocumentStyle` | `nsIDOMLinkStyle` |
| `nsIDOMMediaList` | `nsIDOMNSDocumentStyle` |
| `nsIDOMStyleSheet` | `nsIDOMStyleSheetList` |

The following interfaces moved from `dom/public/idl/svg/` to `dom/interfaces/svg/`:

| From | To |
| --- | --- |
| `nsIDOMGetSVGDocument` | `nsIDOMSVGAElement` |
| `nsIDOMSVGAngle` | `nsIDOMSVGAnimPresAspRatio` |
| `nsIDOMSVGAnimTransformList` | `nsIDOMSVGAnimateElement` |
| `nsIDOMSVGAnimateTransformElement` | `nsIDOMSVGAnimatedAngle` |
| `nsIDOMSVGAnimatedBoolean` | `nsIDOMSVGAnimatedEnum` |
| `nsIDOMSVGAnimatedInteger` | `nsIDOMSVGAnimatedLength` |
| `nsIDOMSVGAnimatedLengthList` | `nsIDOMSVGAnimatedNumber` |
| `nsIDOMSVGAnimatedNumberList` | `nsIDOMSVGAnimatedPathData` |
| `nsIDOMSVGAnimatedPoints` | `nsIDOMSVGAnimatedRect` |
| `nsIDOMSVGAnimatedString` | `nsIDOMSVGAnimationElement` |
| `nsIDOMSVGCircleElement` | `nsIDOMSVGClipPathElement` |
| `nsIDOMSVGDefsElement` | `nsIDOMSVGDescElement` |
| `nsIDOMSVGDocument` | `nsIDOMSVGElement` |
| `nsIDOMSVGEllipseElement` | `nsIDOMSVGEvent` |
| `nsIDOMSVGException` | `nsIDOMSVGFilterElement` |
| `nsIDOMSVGFilters` | `nsIDOMSVGFitToViewBox` |
| `nsIDOMSVGForeignObjectElem` | `nsIDOMSVGGElement` |
| `nsIDOMSVGGradientElement` | `nsIDOMSVGImageElement` |
| `nsIDOMSVGLength` | `nsIDOMSVGLengthList` |
| `nsIDOMSVGLineElement` | `nsIDOMSVGLocatable` |
| `nsIDOMSVGMarkerElement` | `nsIDOMSVGMaskElement` |
| `nsIDOMSVGMatrix` | `nsIDOMSVGMetadataElement` |
| `nsIDOMSVGNumber` | `nsIDOMSVGNumberList` |
| `nsIDOMSVGPathElement` | `nsIDOMSVGPathSeg` |
| `nsIDOMSVGPathSegList` | `nsIDOMSVGPatternElement` |
| `nsIDOMSVGPoint` | `nsIDOMSVGPointList` |
| `nsIDOMSVGPolygonElement` | `nsIDOMSVGPolylineElement` |
| `nsIDOMSVGPresAspectRatio` | `nsIDOMSVGRect` |
| `nsIDOMSVGRectElement` | `nsIDOMSVGSVGElement` |
| `nsIDOMSVGScriptElement` | `nsIDOMSVGSetElement` |
| `nsIDOMSVGStopElement` | `nsIDOMSVGStylable` |
| `nsIDOMSVGStyleElement` | `nsIDOMSVGSwitchElement` |
| `nsIDOMSVGSymbolElement` | `nsIDOMSVGTSpanElement` |
| `nsIDOMSVGTextContentElement` | `nsIDOMSVGTextElement` |
| `nsIDOMSVGTextPathElement` | `nsIDOMSVGTextPositionElem` |
| `nsIDOMSVGTitleElement` | `nsIDOMSVGTransform` |
| `nsIDOMSVGTransformList` | `nsIDOMSVGTransformable` |
| `nsIDOMSVGURIReference` | `nsIDOMSVGUnitTypes` |
| `nsIDOMSVGUseElement` | `nsIDOMSVGViewSpec` |
| `nsIDOMSVGZoomAndPan` | `nsIDOMSVGZoomEvent` |

The IDL files for DOM workers have moved as well, from `dom/public/idl/threads/` to `dom/interfaces/threads/`:

| From | To |
| --- | --- |
| `nsIDOMWorkers.idl` (contains multiple interfaces) | `nsIDOMWorkers.idl` |

The following IDL files have moved from `dom/public/idl/traversal/` to `dom/interfaces/traversal/`:

| From | To |
| --- | --- |
| `nsIDOMDocumentTraversal` | `nsIDOMNodeFilter` |
| `nsIDOMNodeIterator` | `nsIDOMTreeWalker` |

The following IDL files have moved from `dom/public/idl/views/` to `dom/interfaces/views/`:

| From | To |
| --- | --- |
| `nsIDOMAbstractView` | `nsIDOMDocumentView` |

The following IDL files have moved from `dom/public/idl/xbl/` to `dom/interfaces/xbl/`:

| From | To |
| --- | --- |
| `nsIDOMDocumentXBL` | `nsIDOMDocumentXBL` |

The following IDL files have moved from `dom/public/idl/xpath/` to `dom/interfaces/xpath/`:

| From | To |
| --- | --- |
| `nsIDOMNSXPathExpression` | `nsIDOMXPathEvaluator` |
| `nsIDOMXPathException` | `nsIDOMXPathExpression` |
| `nsIDOMXPathNSResolver` | `nsIDOMXPathNamespace` |
| `nsIDOMXPathResult` | `nsIDOMXPathResult` |

The following IDL files have moved from `dom/public/idl/xul/` to `dom/interfaces/xul/`:

| From | To |
| --- | --- |
| `nsIDOMXULButtonElement` | `nsIDOMXULCheckboxElement` |
| `nsIDOMXULCommandDispatcher` | `nsIDOMXULCommandEvent` |
| `nsIDOMXULContainerElement` | `nsIDOMXULControlElement` |
| `nsIDOMXULDescriptionElement` | `nsIDOMXULDocument` |
| `nsIDOMXULElement` | `nsIDOMXULImageElement` |
| `nsIDOMXULLabelElement` | `nsIDOMXULLabeledControlEl` |
| `nsIDOMXULMenuListElement` | `nsIDOMXULMultSelectCntrlEl` |
| `nsIDOMXULPopupElement` | `nsIDOMXULSelectCntrlEl` |
| `nsIDOMXULSelectCntrlItemEl` | `nsIDOMXULTextboxElement` |
| `nsIDOMXULTreeElement` | `nsIDOMXULTreeElement` |


Updating extensions for Firefox 7 - Mozilla

Updating extensions for Firefox 7
=================================

This article offers advice for add-on developers that want to update their extensions to work in Firefox 7. Fortunately, most of the changes are relatively minor in this release, and few add-ons should need significant changes to work in Firefox 7.

**Note:** For a complete list of developer-related changes in Firefox 7, see Firefox 7 for developers.

As always, you will need to recompile any binary components to make them compatible with Firefox 7.

XPCOM changes affecting compatibility
-------------------------------------

Most of the changes in this release are XPCOM interface removals, or removals of specific, obsolete APIs from interfaces.

### Removed interfaces

The following interfaces are the ones that were removed that will most likely impact extension developers:

* `nsIDOM3Node`
* `nsIDOM3TypeInfo`
* `schemaTypeInfo`
* `nsIDOMNSDocument`
* `nsIDOMDocumentStyle`

You can get a complete list of the removed interfaces in the Removed interfaces section of Firefox 7 for developers.

### Changed methods

A few interfaces have methods that have been changed:

`nsINavHistoryObserver` and `nsINavBookmarkObserver`

These have been changed to support Firefox Sync better by adding a new GUID parameter to several of their methods. JavaScript-based code shouldn't require any changes, since this is just the addition of a new, optional, parameter. However, binary components will need to be updated to take the new parameter into account.

`nsIDOMFile`

A number of non-standard methods have been removed from this interface. This affects the `File` object's `File.getDataAsUrl()` and `File.getAsBinary()` methods. However, this functionality can now be found in the standard `FileReader` object.

Other changes of note
---------------------

These changes won't affect compatibility (we weren't kidding when we said there weren't many changes that do in this release), but do add capabilities that are easy to take advantage of that might be of special use to you.

### Unloading JavaScript code modules

The new `Components.utils.unload()` method lets you unload JavaScript code modules previously loaded by calling `Components.utils.load()`. This can be particularly handy with restartless (bootstrapped) extensions, so that you can unload an old version of a code module when a new version of your add-on is installed.

### Inline preferences

You can now have preference options inline in the Add-on Manager window, which lets users configure your add-on without having to open a separate preference dialog box. There are limits to what types of configuration controls can be provided, but this is still very helpful — plus it works for restartless (bootstrapped) extensions.

See also
--------

* Firefox 7 for developers
* Add-ons Blog: Firefox 7 add-on compatibility
* XPCOM changes in Gecko 2.0


Updating extensions for Firefox 3.5 - Mozilla

Updating extensions for Firefox 3.5
===================================

This article provides helpful information to extension developers trying to update their extensions to work properly in Firefox 3.5.

Update basics
-------------

This section covers the basics of what you need to do whenever you update an extension for a new version of Firefox.

### Test your extension

Start by editing your extension's `install.rdf` file, updating `maxVersion` to 3.5b4 (if you're testing on Firefox 3.5 beta 4), and increase your extension's `version`.

Then create a new Firefox profile so that your testing doesn't risk your usual profile. Navigate to the directory containing Firefox, then issue the command:

```bash
firefox -createProfile testBeta4
```

On the Mac, you need to navigate all the way into the Firefox application bundle:

```bash
cd /Applications/Firefox.app/Contents/MacOS/
firefox -createProfile testBeta4
```

Launch Firefox using the new profile by issuing this command on the command line:

```bash
firefox -P testBeta4
```

Test your extension thoroughly. We suggest you set the following preferences to `true` in order to be alerted to any JavaScript warnings or exceptions:

* `javascript.options.strict`
* `javascript.options.showInConsole`
### Update your extension

If you run into any problems while testing, update your code to fix the issues. This article contains useful information about things that may require some work.

Once you've done that, try using your extension again, this time with your regular profile. This will help to ensure compatibility with any existing saved data.

### Update your extension on addons.mozilla.org

Finally, it's time to release your updated extension. If your extension didn't need any code changes you can log into the AMO dashboard and update the compatibility version there. Otherwise, you'll need to upload a new version to AMO.

See Submitting an add-on to AMO for additional information.

Accessing the Places database
-----------------------------

Prior to Firefox 3.5, accessing the Places database directly using the Storage API required a little bit of trickery:

```js
var places = Components.classes["@mozilla.org/file/directory\_service;1"]
  .getService(Components.interfaces.nsIProperties)
  .get("ProfD", Components.interfaces.nsIFile);
places.append("places.sqlite");
var db = Components.classes["@mozilla.org/storage/service;1"]
  .getService(Components.interfaces.mozIStorageService)
  .openDatabase(places);
```

This builds a path to the `places.sqlite` database file manually, then opens the file for Storage access.

Firefox 3.5 adds a dedicated service that offers a convenient way to access the Places database; the above technique does not work in Firefox 3.5 or later.

```js
var db = Components.classes[
  "@mozilla.org/browser/nav-history-service;1"
].getService(Components.interfaces.nsPIPlacesDatabase).DBConnection;
```

Search textboxes
----------------

The `textbox` type `timed` is deprecated; instead, you should use `search`.

In Firefox 3, you might have used:

```xml
<textbox type="timed" timeout="1000" oncommand="alert(this.value);"/>
```

In Firefox 3.5, you should change this to:

```xml
<textbox type="search" timeout="1000" oncommand="alert(this.value);"/>
```

JSON
----

The JSON.jsm JavaScript module was dropped in Firefox 3.5 in favor of native JSON object support. For details, see Using JSON in Firefox and the article on JSON for a more general overview of JSON and how to use it in various versions of Firefox.

To ensure compatibility with both Firefox 3 and Firefox 3.5, you can do the following:

```js
if (typeof JSON === "undefined") {
  Components.utils.import("resource://gre/modules/JSON.jsm");
  JSON.parse = JSON.fromString;
  JSON.stringify = JSON.toString;
}
```

This works by importing the JSON.jsm JavaScript module if JSON isn't supported natively, then mapping the methods provided by that module to the ones used by native JSON, so that the same calls work.

You can also bypass this issue by using the `nsIJSON` interface directly.

Changes to context menus
------------------------

In order to support the new audio and video features added in Gecko 1.9.1, the `nsContextMenu` class has renamed the `imageURL` getter to `mediaURL`; however, `imageURL` was added back in on June 9, 2009.

Changes to chrome registration
------------------------------

Firefox 3.5 closes a security hole that made it possible to use remote chrome. This will affect any add-on that includes a resource in their `chrome.manifest` file that references a website, data or resource URLs. See Security changes in Firefox 3.5 for details.

Getting a load context from a request
-------------------------------------

Previously, it was possible to get a load context from a request by querying various docShell APIs. In particular, it was a common practice to use `notificationCallbacks.getInterface(nsIDOMWindow)` to get the window object associated with the load. While the older approach may work in some circumstances, it is not recommended to use it anymore (details).

This correct and reliable way to do this is to use an `nsILoadContext` (see the interface definition on mxr).

From JavaScript, you do it like this:

```js
var loadContext;
try {
  loadContext = aRequest
    .QueryInterface(Components.interfaces.nsIChannel) // aRequest is equivalent to aSubject from observe
    .notificationCallbacks.getInterface(Components.interfaces.nsILoadContext);
} catch (ex) {
  try {
    loadContext = aRequest.loadGroup.notificationCallbacks.getInterface(
      Components.interfaces.nsILoadContext,
    );
  } catch (ex) {
    loadContext = null;
  }
}
// you can now use |loadContext.associatedWindow| to get the Window object
```

Another JavaScript example if the above does not work:

```js
// SOURCE: http://stackoverflow.com/questions/10719606/is-it-possible-to-know-the-target-domwindow-for-an-httprequest

function getWindowForRequest(request) {
  if (request instanceof Components.interfaces.nsIRequest) {
    try {
      if (request.notificationCallbacks) {
        return request.notificationCallbacks.getInterface(
          Components.interfaces.nsILoadContext,
        ).associatedWindow;
      }
    } catch (e) {}
    try {
      if (request.loadGroup && request.loadGroup.notificationCallbacks) {
        return request.loadGroup.notificationCallbacks.getInterface(
          Components.interfaces.nsILoadContext,
        ).associatedWindow;
      }
    } catch (e) {}
  }
  return null;
}
```

From C++, you can do it like this:

```cpp
nsCOMPtr<nsILoadContext> loadContext;
nsCOMPtr<nsIChannel> channel = do\_QueryInterface(aRequest);
NS\_QueryNotificationCallbacks(channel, loadContext);
```

Customizable toolbars
---------------------

In Firefox 3.5, customizable toolbar behavior has changed such that the `<xul:toolbar/>` binding now removes toolbar items from its associated `<xul:toolbarpalette/>` and adds them to the toolbar, rather than cloning them and copying them to the toolbar. This means that the palette will now only contain items not present on the toolbar, as opposed to the previous behavior of containing all customizable elements whether or not they were displayed on the toolbar. This might cause trouble for addons that depend on being able to retrieve all customizable toolbar items from the `<xul:toolbarpalette/>`, or which attempt to dynamically insert items into the palette to make them available during toolbar customization. More information is available in Firefox bug 407725 and Webkit bug 467045.

XPCNativeWrapper
----------------

Starting in Firefox 3.5, you can no longer use `data:` bindings in chrome packages that get `XPCNativeWrapper` automation. This resolves a potential security issue.

XUL documents now get `XPCNativeWrapper` treatment, so you now need to use the `getAttribute()` method to fetch attribute values instead of reading them directly.

If your extension is using `xpcnativewrappers=no` (which it shouldn't be doing in the first place, since it's not safe to do so), XBL from that extension will not be applied to documents which are using `XPCNativeWrapper` automation starting in Firefox 3.5.

New capabilities of interest
----------------------------

### Listening to events on all tabs

Firefox 3.5 introduces support for adding and removing progress listeners that listen on all tabs. See Listening to events on all tabs for details.

For Theme developers
--------------------

* Check Theme changes in Firefox 3.1.
* Go to the Mozillazine forum Theme changes for FF3.1 to get an overview / listing of all changes between 3.0 and 3.1 that impact theme developers. This concerns new CSS features (like nth-child, -moz-box-shadow, etc.), changes to existing widgets, overall UI improvements, and new FF3.1 features (audio/video support, private browsing, extended session restore, box/window/text shadows).


Security changes in Firefox 3.5 - Mozilla

Security changes in Firefox 3.5
===============================

 This article covers security-related changes in Firefox 3.5.
Changes to chrome registration
------------------------------

A security hole was closed in order to prevent remote content to be used as chrome. This could impact any add-on that included a resource in their `chrome.manifest` file that referenced a file on the web.

Fixing this bug was accomplished by adding a new `URI_IS_LOCAL_RESOURCE` flag to the `nsIProtocolHandler` interface that indicates that the protocol is safe to register as chrome. Any add-on that creates its own protocol handler and tries to register it in its `chrome.manifest` file will have to use this flag in order to work correctly.

Private browsing
----------------

Firefox 3.5 implements private browsing, a mode in which cookies, history, and other potentially private information isn't saved permanently on the user's computer. Extensions and other add-ons may support the private browsing feature, detecting when it's in use so they can avoid saving private information while private browsing mode is enabled. See Supporting private browsing mode for details.

Plug-ins can detect whether or not private browsing mode is in effect by using the `NPN_GetValue()` function to check the current value of the `NPNVprivateModeBool` variable.

New certificate error handling
------------------------------

In previous versions of Firefox 3, SSL certificate errors resulted in the presentation of the standard network error page, `about:neterror`, in the browser window. Starting in Firefox 3.5, there is a new error page, `about:certerror`, which is displayed instead. The error URL is formatted like this:

`about:certerror?e=error&u=url&d=desc`

Embedders needing to provide custom certificate error pages can now do so by supplying their own `about:` page implementation, and setting the `security.alternate_certificate_error_page` preference to the appropriate page name (e.g. `"certerror`").

See also
--------

* Firefox 3.5 for developers


ICC color correction in Firefox - Mozilla

ICC color correction in Firefox
===============================

Although support for color correction was introduced in Firefox 3, it was disabled by default, requiring some tinkering about in the about:config window to enable it. Firefox 3.5 addresses the issues that caused it be disabled by default in the previous version, and now images with International Color Consortium (ICC) tagging are, by default, color corrected.

The image below is split into three sections. The top left corner shows the image as rendered by Firefox 2. The top right corner shows how the image renders in Firefox 3. The bottom shows the image rendered in Photoshop.

![A purple flower as rendered by Firefox 2, Firefox 3, and Photoshop.](/en-US/docs/Mozilla/Firefox/Releases/3.5/ICC_color_correction_in_Firefox/iccsample.jpg)

As you can see, Firefox 3 and Photoshop render the image identically, because both support the embedded color correction profile. Firefox 2 ignores the profile, resulting in mismatched color.

Configuring color correction
----------------------------

Color correction can be controlled by setting the value of the `gfx.color_management.mode` preference, as follows:

|  |  |
| --- | --- |
| Value | Description |
| 0 | Color management disabled. **(Default in Firefox 3.)** |
| 1 | Full color management. |
| 2 |
 Color management applied only to tagged image.
 **(Default in Firefox 3.5.)** |

Full color management means that everything rendered by Firefox, with the exception of plugins, has its colors corrected.

### Specifying a color profile

You can also specify a specific color profile to use for your hardware by setting the value of the `gfx.color_management.display_profile` preference to be the path to a color profile to use.

If no path is specified for the color profile, Firefox queries the operating system and uses its configured color profile.

### Specifying a default rendering intent

In addition, you can choose to set the value of the `gfx.color_management.rendering_intent` preference to specify a default rendering intent. By default, the intent specified by images is ignored, unless you specify -1 for this value.

The following table lists the possible values.

|  |  |
| --- | --- |
| Value | Description |
| -1 |
 Use embedded intent. By default, the embedded intent on images is
 ignored.
  |
| 0 |
 Perceptual. Directs Firefox to render the image to preserve detail
 throughout the tonal range of the image. Useful for general purpose
 display of images in typical cases, especially for photographs and other
 pictures.
  |
| 1 |
 Media-relative colorimetric. This rescales the color spectrum so that
 the white point of the rendering medium (such as the display screen) is
 mapped to the white point of the reference medium. This is most useful
 for colors that have been mapped to a medium with a smaller gamut than
 the reference medium.
  |
| 2 |
 Saturation. This preserves vividness of color at the expense of
 preservation of precision of hue. This is particularly useful for charts
 and diagrams, and other media whose colors should "pop" while precise
 duplication of hue is less important.
  |
| 3 |
 ICC-Absolute colorimetric. This is most useful for spot color and when
 simulating one medium on another, as it doesn't alter in-gamut colors.
  |

**Note:** In Firefox 3.5, perceptual, media-relative, and saturation intents all render the same way.

### Caveats

The new QCMS color management system introduced in Firefox 3.5 currently only supports ICC version 2 color profiles, not version 4. This may result in images being too dark. See bug 488800 and the ICC version 4 profile test.

See also
--------

* So Many Colors (blog post)
* Color Profiles in Firefox 3 (blog post)
* International Color Consortium


Updating add-ons for Firefox 10 - Mozilla

Updating add-ons for Firefox 10
===============================

Although a lot of things have changed in Firefox 10 that, in theory, can cause add-on compatibility breakage, most of them are relatively obscure, so they're not very likely to affect you. This article will help guide you as you update your add-on.

Compatible by default
---------------------

The first and most important thing to note is that starting in Firefox 10, add-ons are assumed to be compatible by default. Unless you use the `<em:strictCompatibility>` flag in your manifest, Firefox will no longer mark your add-on as incompatible after an upgrade to Firefox 10 or later. You can use that flag to ensure that an add-on that is likely to break will not try to run in updated copies of Firefox. It's worth noting that add-ons that have binary components will always be strictly checked for compatibility, since binary components always need to be recompiled for each major Firefox release.

**Note:** You should still test your add-on on Firefox 10, even in the world of compatibility by default. Read over the rest of this article to see if there's anything you need to change.

DOM changes
-----------

Some obsolete APIs have been removed from the DOM:

`Node.isSameNode()`

This is the removal that has the most likelihood to affect add-on developers, as it was fairly commonly used. You can now use the JavaScript `===` operator to compare nodes instead of this obsolete method. This method was made obsolete by the DOM4 specification.

`text.isElementContentWhitespace`
`text.replaceWholeText()`

These APIs were rendered obsolete by the DOM4 specification.

`Document.xmlEncoding``Document.xmlStandalone``Document.xmlVersion`

All of these APIs were rendered obsolete by the DOM4 specification. They were most frequently being used to detect whether the document being displayed was HTML or XML. See the article for `Document.xmlVersion` for a recommended way to test for this going forward.

XPCOM and interface changes
---------------------------

The most significant change is that everywhere that previously used the `PRBool` data type now uses the standard C++ `bool` type instead.

### Removed interfaces

The following interfaces have been removed:

`nsIDOMNSHTMLFrameElement`

This interface has been merged into the `nsIDOMHTMLFrameElement` interface.

`nsIDOMNSHTMLElement`

This interface has been merged into `nsIDOMHTMLElement`.

`nsIDocumentViewer`

This interface has been merged into `nsIContentViewer`

### Other interface changes

* `nsNavHistory` no longer implements the `nsICharsetResolver` interface. **Note that `nsICharsetResolver` is no longer used and is being removed in Firefox 11.0**.
* The `mozISpellCheckingEngine` and `nsIEditorSpellCheck` interfaces have been updated to let restartless add-ons add dictionaries to the spell checker. See Using an external spell checker for details (note this article has not yet been updated, but will be soon).
* The `nsIBrowserHistory.lastPageVisited` attribute has been removed, as it hasn't been supported for some time.
* Several IndexedDB internal interfaces have changed to support revised APIs. This shouldn't affect you but is worth noting on the off chance you were doing something unusual.
Other changes worth noting
--------------------------

* All binary components on Windows should be built with ASLR (address space layout randomization) support enabled. While this is not **yet** required, it may be in the future, and not enabling it results in a performance penalty.
* A bug in regular expression handling that was introduced in Firefox 7 has been fixed. This can change the result of some regular expressions, so be aware of it.
* You can now dynamically load and unload chrome.manifest files in bootstrapped add-ons.
* The `mouseenter` and `mouseleave` events are now supported.


Updating add-ons for Firefox 5 - Mozilla

Updating add-ons for Firefox 5
==============================

This article provides an overview of the changes you may need to make to your add-ons in order for them to work properly in Firefox 5. You can find a complete list of developer-related changes in Firefox 5 in Firefox 5 for developers.

Do you need to do anything at all?
----------------------------------

If your add-on is distributed on addons.mozilla.org (AMO), it's been checked by an automated compatibility verification tool. Add-ons that don't use APIs that changed in Firefox 5, and have no binary components (which need to be recompiled for every major Firefox release), have automatically been updated on AMO to indicate that they work in Firefox 5.

So you should start by visiting AMO and looking to see if your add-on needs any work done at all.

**Note:** You should still test your add-on on Firefox 5, even if it's been automatically upgraded. There are edge cases that may not be automatically detected.

Once you've confirmed that you need to make changes, come on back to this page and read on.

User interface related changes
------------------------------

Due to the short development cycle (even for our rapid release cycle; Firefox 5 was on an extra-short schedule for timing reasons), there are very few UI related changes in Firefox 5.

### Determining the UI language

In the past, the `window.navigator.language` DOM property reflected the language of Firefox's user interface. This is no longer the case; instead, it reflects the value of the `Accept-Language` header for the current document. If you need to detect the UI language, you should instead look at the value of the `general.useragent.locale` preference.

DOM changes
-----------

The behaviors of `setTimeout()` and `setInterval()` have changed; the minimum allowed time has changed, and varies depending on the situation. In addition, timeouts and intervals are clamped to one per second in inactive tabs (that is, tabs the user isn't currently looking at).

JavaScript changes
------------------

The following keywords are now reserved in JavaScript, even when you're not in strict mode:

* `class`
* `enum`
* `export`
* `extends`
* `import`
* `super`

Don't use those keywords anywhere in your code, even as object property names.

**Note:** This is one of those things that AMO's automatically upgrade tool may not always catch, so check your code for these if your add-on was automatically upgraded but is still not working properly.

Interface changes
-----------------

Instantiating certain services, including the `nsICertOverrideService`, at startup can make Firefox unusable (Firefox bug 650858. This happens only if you try to instantiate a service before the `load` event is fired.

To fix this, move your instantiation of these services into your `load` event handler:

```js
var MyObject = {
  comp: null,
  init() {
    this.comp = Components.classes["…"].getService(/\* … \*/);
  },
  // …
};
window.addEventListener(
  "load",
  function () {
    MyObject.init();
  },
  false,
);
```

An even better solution, of course, is to follow performance best practices and to not instantiate services until you need to use them.

See also
--------

* Firefox 5 for developers


Updating add-ons for Firefox 8 - Mozilla

Updating add-ons for Firefox 8
==============================

This article provides information on steps you need to take in order to update your existing add-on for compatibility with Firefox 8. See Firefox 8 for developers for a complete list of everything that changed in Firefox 8.

Do you need to do anything at all?
----------------------------------

If your add-on is distributed on addons.mozilla.org (AMO), it's been checked by an automated compatibility verification tool. Add-ons that don't use APIs that changed in Firefox 8, and have no binary components (which need to be recompiled for every major Firefox release), have automatically been updated on AMO to indicate that they work in Firefox 8.

So you should start by visiting AMO and looking to see if your add-on needs any work done at all.

**Note:** You should still test your add-on on Firefox 8, even if it's been automatically upgraded. There are edge cases that may not be automatically detected.

Once you've confirmed that you need to make changes, come on back to this page and read on.

Development process note
------------------------

It's worth noting that during startup, Firefox 8 now checks for third-party add-ons on its first startup, and presents a user interface letting users decide whether or not to enable them. If you drop your add-on into the profile directory in order to test it, Firefox won't enable it automatically on the first startup, but will show this interface instead.

You can avoid this by setting the preference `extensions.autoDisableScopes` to 14. This should only be done for development and testing purposes.

Interfaces have been merged
---------------------------

As part of our ongoing effort to streamline Gecko's internals, a few interfaces have been merged together:

* `nsIDOMWindowInternal` has been merged into `nsIDOMWindow`. The `nsIDOMWindowInternal` interface still exists, but is empty, and will be removed entirely in Firefox 9. You should update any code that relies on the existence of `nsIDOMWindowInternal` to look for `nsIDOMWindow` instead.
* All of the sub-interfaces of `nsISelection` have been merged into the base `nsISelection` interface. If by some chance you were previously looking for `nsISelection2` or `nsISelection3`, you should update your code.
Date handling improved
----------------------

Now that the JavaScript `Date` object can parse ISO 8601 dates, the `ISO8601DateUtils.jsm` code module has been removed. If you were using this code module, you should update your code to use the methods on `Date` instead.

DOM changes
-----------

There have been a couple of changes in the DOM that impact add-ons:

### Selection changes

In the past, `Document.getSelection()` was returning a stringified version of the selection instead of the `Selection` object itself. This was non-standard behavior, and has been corrected.

### Potential name conflicts

When the DOM File API was added, a new global called `File` was added; this can conflict with objects in your scripts. If you have any globals called `File`, you should rename them.

Similarly, a new global, `ChromeWorker`, was introduced to support allowing Workers to be used from chrome code. If by some chance you have any globals with this name, you should rename them.

Security changes
----------------

Support for SSL 2.0 has been removed. This shouldn't affect any current add-ons. However, for reference, some very old code was removed, as well as support for the preferences `security.enable_ssl2` (which is false by default), and all preferences starting with "`security.ssl2.`"

See also
--------

* Firefox 8 for developers


Security in Firefox 2 - Mozilla

Security in Firefox 2
=====================

This article discusses changes that affect security in Firefox 2.

Weak ciphers disabled by default
--------------------------------

Firefox 2 disables SSLv2 and the weak "export" cipher suites (those with key lengths less than 64 bits) by default, in favor of SSLv3. This provides improved security.

The preferred encryption methods are `TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA` and `TLS_RSA_WITH_3DES_EDE_CBC_SHA`. Some servers refer to these as `SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA` and `SSL_RSA_WITH_3DES_EDE_CBC_SHA`.

If SSLv2 support must be enabled, it can be by setting the appropriate `security.ssl2.*` user preferences to `true`.

New features
------------

* Firefox 2 supports Elliptic Curve Cryptography in TLS. Support is presently limited to curves of 256, 384, and 521 (yes, 521) bits.
* Firefox 2 supports the TLS server name indication extension to facilitate secure connections to servers hosting multiple virtual servers on a single underlying network address, as per RFC 3546.
* When Firefox 2 makes an OCSP request to validate a web server's certificate, it now uses the proxy that has been configured for normal HTTP traffic.
Determining what ciphers are available
--------------------------------------

As always, you can find out what ciphers are supported — and which are enabled or disabled — by going to about:config and searching on "ssl" or "tls".

Security improved for the jar: protocol
---------------------------------------

In order to correct a potential security problem when using the `jar:` protocol, it's now necessary to serve JAR files with the MIME type `application/java-archive`. See Security and the jar protocol for further details.


Updating extensions for Firefox 2 - Mozilla

Updating extensions for Firefox 2
=================================

This article provides information that will be useful to developers that wish to update their extensions to work properly under Firefox 2.

Step 1: Update the install manifest
-----------------------------------

The first step — and, for most extensions, the only one that will be needed — is to update the install manifest file, install.rdf, to indicate compatibility with Firefox 2.

Find the line indicating the maximum compatible version of Firefox (which, for Firefox 1.5, might look like this):

```bash
 <em:maxVersion>1.5.0.*</em:maxVersion>
```

Change it to indicate compatibility with Firefox 2:

```bash
 <em:maxVersion>2.0.0.*</em:maxVersion>
```

Then reinstall your extension.

Step 2: Update XUL overlays
---------------------------

Firefox 2 incorporates changes to the default skin. Additionally, some user interface elements have been changed or moved, and it's possible your extension may be affected by these, depending on what your XUL overlays do.

Look over the article Theme changes in Firefox 2 to learn what changes were made that may affect your extension's XUL overlays.

Step 3: Test
------------

Be sure to test your extension carefully on Firefox 2 before you release it to the public. The last thing you want is for the new version of your extension to be responsible for a rash of reports of problems with the just-released version of Firefox!

Step 4: Release
---------------

Update your extension's entry on http://addons.mozilla.org. This will ensure that users can find it.

In addition, if your extension provides an `updateURL` in the install manifest, be sure to update the update manifest so that the new version of your extension can be found automatically by Firefox. By doing this, the first time the user runs your extension after upgrading to Firefox 2, Firefox can offer to automatically install it for them.


Adding feed readers to Firefox - Mozilla

Adding feed readers to Firefox
==============================

Starting with Firefox 2, Firefox has support for selecting different RSS or Atom feed readers to use when you try to read a feed. This article provides information about how to add support for additional readers not supported by default.

Adding a new web-based feed reader
----------------------------------

### Adding a feed reader from a web application

Support for adding feed readers from the web was removed from the HTML5 spec, and Firefox support is scheduled for removal in Firefox 62.
Deprecated

In older versions, JavaScript code on the web can add a feed reader using the `navigator.registerContentHandler()` function, like this:

```js
navigator.registerContentHandler(
  "application/vnd.mozilla.maybe.feed",
  "https://www.example.com/?feed-feed=%s",
  "My Feed Reader",
);
```

Note that web content is limited to adding handler URLs which have the same origin as the page performing the call.

### Adding a new feed reader manually

Support for adding new feed readers was removed in Firefox 63.
Deprecated
.

Prior to Firefox 63, to add support for a new web-based feed reader, you would need to add three new preferences:

`browser.contentHandlers.types.number.title`

The name of the feed reader.

`browser.contentHandlers.types.number.type`

For a feed reader, this should be "application/vnd.mozilla.maybe.feed".

`browser.contentHandlers.types.number.uri`

The URI of the feed reader. Use "%s" where the URL of the feed should be inserted.

`number` should be replaced with the next highest unique number that hasn't already been used. For example, if you want to add a new feed reader called "Easy Reader", and there are already defined content handlers with numbers 0 through 4, you should use a `number` of 5, like this:

* `browser.contentHandlers.types.5.title`: `Easy Reader`
* `browser.contentHandlers.types.5.type`: `application/vnd.mozilla.maybe.feed`
* `browser.contentHandlers.types.5.uri`: `http://www.theeasyreaderurl.com?feed=%s`

You can add these preferences by hand, by visiting `about:config`.

### Adding a new feed reader application

The easiest way to do this is to use the provided user interface, by using the Feeds panel in the Preferences (or Options, depending on your platform) window.


Updating add-ons for Firefox 6 - Mozilla

Updating add-ons for Firefox 6
==============================

This article provides an overview of the changes you may need to make to your add-ons in order for them to work properly in Firefox 6. You can find a complete list of developer-related changes in Firefox 6 in Firefox 6 for developers.

Do you need to do anything at all?
----------------------------------

If your add-on is distributed on addons.mozilla.org (AMO), it's been checked by an automated compatibility verification tool. Add-ons that don't use APIs that changed in Firefox 6, and have no binary components (which need to be recompiled for every major Firefox release), have automatically been updated on AMO to indicate that they work in Firefox 6.

So you should start by visiting AMO and looking to see if your add-on needs any work done at all.

**Note:** You should still test your add-on on Firefox 6, even if it's been automatically upgraded. There are edge cases that may not be automatically detected.

Once you've confirmed that you need to make changes, come on back to this page and read on.

UI changes
----------

The addition of the new Web Developer sub-menu in the Tools menu means that overlays that rely on the items that have been moved there will work differently than they used to. Your overlays will continue to work, but your items will not wind up where you expect them to. You should update your overlays to ensure that menu items go where you intend them to go.

Similarly, the order of menu items in the History and Bookmarks menus may also affect your add-on's overlays.

Binary component compatibility
------------------------------

A bug in Firefox 5 meant that binary components were not properly being rejected if they were built for a different version of Gecko. This is fixed in Firefox 6; if your add-on's binary components don't load, check to be sure you've rebuilt them against the Gecko 6 SDK.

Preferences
-----------

The `app.update.timer` preference was removed; you need to use the `app.update.timerMinimumDelay` preference instead.

Also, site-specific privacy preferences have been added. This will only impact add-ons that expect privacy related preferences (privacy, remember passwords, and so forth) being in the main preference window.

DOM changes
-----------

The `window.top` property is now read only. This will affect your add-on if you have an undeclared variable named `top` in a chrome script.

URL handling
------------

`javascript:` and `data:` URLs entered into the location bar no longer inherit the principal of the currently loaded page. This probably won't affect many add-ons but if you run code that uses these URLs you may want to double check that everything is working as expected.

Firefox bug 658949 changed how the hash (#) symbol is treated in data Ls which may break CSS stylesheets which contain such symbol if it is not escaped.

Interfaces
----------

A few interfaces that were deprecated or implementation details have been removed. If you rely on any of them, you need to revise your code.


Browser extensions - Mozilla

Browser extensions
==================

Extensions, or add-ons, can modify and enhance the capability of a browser. Extensions for Firefox are built using the WebExtensions API cross-browser technology.

The technology for extensions in Firefox is, to a large extent, compatible with the extension API supported by Chromium-based browsers (such as Google Chrome, Microsoft Edge, Opera, Vivaldi). In most cases, extensions written for Chromium-based browsers run in Firefox with just a few changes.

Key resources
-------------

Guides

Whether you're just beginning or looking for more advanced advice, learn about how extensions work and use the WebExtensions API from our extensive range of tutorials and guides.

References

Get comprehensive details about the methods, properties, types, and events of the WebExtensions APIs and full details about the manifest keys.

Firefox workflow

Discover how to build and publish extensions for Firefox: get the lowdown on developer tools, publication and distribution, and porting on Extension Workshop.

**Note:** If you have ideas or questions or need help, you can reach us on the community forum or in the Add-ons Room on Matrix.

Get started
-----------

Discover what extensions can do before building your first extension. Learn about the anatomy of an extension and get an overview of the extension development and publication workflow, Firefox style. Explore a little deeper with a comprehensive selection of example extensions that you can run right in Firefox.

Concepts
--------

Get detailed information on the concept that underpin extensions from an overview of the JavaScript API, through content scripts, match patterns, working with files, internationalization, and content security policy, to more advanced subjects such as native messaging, using the devtools APIs, and native manifests.

User interface
--------------

Discover all the user interface components you can use in your extensions, with coding examples and tips.

How to
------

From patterns you'll regularly use such as work with the Tabs API and adding a button to the toolbar to more advanced topics such as intercepting HTTP requests and working with contextual identities, you'll find a range of tutorials to get you started.

Firefox workflow
----------------

When you are ready to create your extension for Firefox or port your Chrome extension, head over to Extension Workshop. It has details on:

* The Firefox workflow, such as temporarily installing extensions during development, debugging, request the right permissions, and more.
* The web-ext developer tool.
* Porting a Google Chrome extension, differences between desktop and Android, and more.
* Publishing and distribution overview, promoting your extension, the extension lifecycle best practices, and more.
Reference
---------

### JavaScript APIs

Get comprehensive details about the methods, properties, types, and events for all the JavaScript APIs. There is also detailed information about the compatibility of each API with the major browsers. Most reference pages also include coding examples and links to the extension examples that use the API.

### Manifest keys

Get full details about the manifest keys, including all their properties and settings. There's also detailed information on the compatibility of each key with the major browsers.