mozilla

Revision 66751 of Updating extensions for Firefox 4

  • Revision slug: Extensions/Updating_extensions_for_Firefox_4
  • Revision title: Updating extensions for Firefox 4
  • Revision id: 66751
  • Created:
  • Creator: khuey
  • Is current revision? No
  • Comment 2 words added, 1 words removed

Revision Content

{{ fx_minversion_header("4") }}

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

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.

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 {{ interface("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 {{ interface("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 HWNDs 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 HWNDs 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 HWNDs 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 HWNDs 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 HWNDs, 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 HWNDs you were using no longer exist.

Revision Source

<p>{{ fx_minversion_header("4") }}</p>
<p>This article offers details on changes in Firefox 4 that may impact existing extensions.</p>
<h2>XPCOM changes</h2>
<p>Several changes have been made that affect add-ons and applications that include XPCOM components. See <a href="/en/XPCOM/XPCOM_changes_in_Gecko_2.0" title="en/XPCOM/XPCOM changes in Gecko 2.0">XPCOM changes in Gecko 2</a> for details.</p>
<h2>XPI unpacking</h2>
<p>Firefox 4 <a class=" link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=533038" title="https://bugzilla.mozilla.org/show_bug.cgi?id=533038">no longer extracts XPIs</a> 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 <span class="nowiki"><a href="https://developer.mozilla.org/en/Install_Manifests#unpack" title="en/Install Manifests#unpack"><code>&lt;em:unpack&gt;</code></a></span> 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.</p>
<p>If your extension only contains these types of files then you do not need to make any changes:</p>
<ul> <li><code>install.rdf</code></li> <li><code>chrome.manifest</code></li> <li><code>chrome</code> (including <code>content</code>, <code>locale</code>, <code>skin</code>)</li> <li>default preferences</li> <li>XPCOM components written in JavaScript</li>
</ul>
<p>If your extension contains any of the following then you will need to include <code>&lt;em:unpack&gt;</code> in the install.rdf:</p>
<ul> <li>Binary XPCOM components</li> <li>Shared libraries loaded with ctypes</li> <li><code>searchplugins/</code> (which are supposed to be loaded automatically by Firefox)</li> <li><code>dictionaries/</code></li> <li>Window icons (might get <a class=" link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=595462" title="https://bugzilla.mozilla.org/show_bug.cgi?id=595462">fixed</a>)</li>
</ul>
<p>If your extension code accesses other files that you have packaged in the XPI then you will either need to include <code>&lt;em:unpack&gt;</code> 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 <code><a href="/en/Addons/Add-on_Manager/Addon#getResourceURI%28%29" title="https://developer.mozilla.org/en/Addons/Add-on_Manager/Addon#getResourceURI()">Addon.getResourceURI()</a></code>, it will return an {{ interface("nsIURI") }} pointing to the requested file. If the extension is unpacked then it will be a <code><span class="nowiki">file://</span></code> URI. If the extension is packed then it will be a <span class="nowiki"><code>jar://</code></span> URI. You can open streams to these URIs by opening a channel using the {{ interface("nsIIOService") }} which will allow you to load the files contents without any unpacking.</p>
<h2>Child HWNDs have been removed</h2>
<p>This should only affect a very small number of developers. In previous versions of Firefox, child <code>HWND</code>s were created on Windows for internal use. As a part of the work toward improving graphics performance, these are no longer created.</p>
<p>Unfortunately, a few extensions have been getting access to these <code>HWND</code>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.</p>
<p>If you maintain an extension that uses native components that rely on <code>HWND</code>s that no longer exist, you'll need to update your extension. There are two ways to do this.</p>
<p>The first, and better, solution is to stop accessing <code>HWND</code>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.</p>
<p>If you find that this doesn't work, and you still need to directly access <code>HWND</code>s, you may find that your only solution is to write an <a href="/en/NPAPI" title="en/NPAPI">NPAPI</a> 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 <code>HWND</code>s you were using no longer exist.</p>
Revert to this revision