Extension Developers – You Still Have Cross-Site XMLHttpRequest


One of the new XMLHttpRequest features in Firefox was cross-site requests. It was based on an W3C specification and would have allowed web content to make cross-site XMLHttpRequests. I say “was” and “would” because that feature was removed in Firefox 3.0b5 due to security concerns and some specification changes too close to the Firefox 3 release.

Extension developers have always been able to use cross-site XMLHttpRequests and this change will not affect your ability to keep making cross-site requests. It only affects web content.

Rest assured, cross-site XHR for web content will be back, just not in Firefox 3.

Shenanigans! on Webkit SMIL


I have always thought that SVG would be great for the Web (more the graphics part and less the sockets part). I also think SMIL would be a good to create nice and smooth animations. Having an animation system built natively into the browser would likely be better than using JavaScript and setTimeout.

With this in mind, I was hoping that Opera and, recently, Webkit support for SMIL would make a compelling case for adding the feature to Firefox. We have a bitrotted patch that has promise. But then I saw Jeff Schiller’s report on how well Webkit supports SMIL. A score of 5/116 isn’t very compelling, especially with Opera’s 110/116 score. Come on Webkit! I need you to support SMIL better than that!

Check out Jeff’s SVG support matrix for a better idea of how well browsers support SVG.

Extension Developers – Unbreaking News, Part 2


I love reporting “unbreaking news” and I have some report. I posted about a security change (bug 418356) to mozIJSSubScriptLoader that broke loading scripts from any non-chrome URI. An alternate fix has landed that allows file: and resource: URIs to be loaded by the subscript loader again.

Therefore, this will continue to work:

var obj = {};
var loader = Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
loader.loadSubScript("file:///blah.js", obj);

Unfortunately, data: URIs are harder to secure and will not work with the subscript loader. Fortunately, there are workarounds for data: URIs – you can save the script to a file and use file: or you can use evalInSandbox to evaluate the script.

Thanks to Boris Zbarsky and Johnny Stenbeck for the more robust fix.

Extension Developers – Better Background XMLHttpRequests


XMLHttpRequests (XHR) are used for lots of things these days. When running a background XHR, however, you might experience some common issues like authentication or bad SSL certificate dialogs popping up. Another problem was starting an XHR, then closing the window – the XHR is closed. To help get around these inconveniences, Manish Singh (of Flock) adding support for a background mode (bug 383430). The details:

  • Do not attach to a window’s load group, so requests aren’t cancelled if the window closes (often the window isn’t really associated with the request anyway)
  • Do not get an nsIAuthPrompt by default, since we don’t want authentication dialogs to pop up randomly.
  • Provide an nsIBadCertListener implementation, again to prevent bad certificate dialogs to pop up randomly.
var req = new XMLHttpRequest();
req.mozBackgroundRequest = true;
req.open("GET", someURI);

The magic is handled by mozBackgroundRequest and it’s only available to chrome, not for web content.

Global Extensions on Linux and Mac


Global extensions are extensions that are not installed into a profile. Therefore, the extensions is always available, even in a new profile. Yes, I am talking about extensions, not plugins. Plugins can also be global, there are a few ways to achieve this on the various platforms (Windows, Mac and Linux).

However, only Windows had the capability to install global extensions, using the Windows registry. Thanks to bug 311008 and bug 412449, global extensions are now possible on Linux and Mac too. The magic paths:


/usr/lib/mozilla/extensions/ (or /usr/lib64/mozilla/extensions/)


/Library/Application Support/Mozilla/Extensions/
~/Library/Application Support/Mozilla/Extensions/

Note that it is possible to limit the extensions to a specific user as well. The new MDC documentation goes into more detail. Hopefully, this makes deploying 3rd party extensions a bit easier.

Extension Developers – Breaking News, Part 2


If you have an extension that uses mozIJSSubScriptLoader (a mouthful, I know) then you should be aware of a recent change (bug 418356). The mozIJSSubScriptLoader interface can be used from JS to load and run JavaScript code from the given URL at run-time. Previously, the URL could be chrome:, file:, data: or resource:, but due to a security fix, the URL is now limited to chrome: only.

Therefore, this will no longer work:

var obj = {};
var loader = Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
loader.loadSubScript("file:///blah.js", obj)

Instead, try moving the JS file into a chrome area and use chrome: or you can try to refactor your code to use Components.utils.import and a resource: URL. Firefox 3 has new ways for extensions to define resource: aliases in chrome manifests, which will make the refactor easier.


Let me know if there is a reason this change or workaround is completely unacceptable to you.

Extension Developers – FUEL Change


For any extension developers out there using FUEL, I checked in a small, but breaking change (bug 421235). FUEL’s bookmark wrappers only supported bookmark items found on the bookmark menu, which was the only bookmark root available at the time. Things have changed and now bookmark roots exist for menu items, toolbar items, tags and unfiled items.

We updated FUEL to support the new roots, but this could cause existing code to break:

Before change:
Application.bookmarks => BookmarkFolder

After change:
Application.bookmarks => BookmarkRoots

So, code that does something like this:

Application.bookmarks.addBookmark("A cool bookmark", bookmarkURI);

Should now use:

Application.bookmarks.menu.addBookmark("A cool bookmark", bookmarkURI);

Of course, Application.bookmarks.toolbar, Application.bookmarks.tags and Application.bookmarks.unfiled can be used now too.

Prism 0.9 – Now as a Firefox Extension


Prism 0.9 has finally been released. Getting platform specific features to work on 3 platforms really is harder than it looks. A big thank you to Matt Gertner (plasticmillion) and Fredrik Larsson (nossralf) for all the work they did on this release.

The big news for this release is Prism for Firefox, a full blown Prism and a Firefox extension all in one. This means that you can now easily “make” web applications directly from Firefox. In addition, Prism now uses Firefox as its runtime, so you don’t need to download the XULRunner runtime. Yes, I have mentioned in the past that Firefox 3 will be able to run XUL applications. Here are some things the extension can do:

  • Allow you to manually convert a website into a Prism-ified web application.
  • Detect a web application bundle embedded on a website and prompt the user to install it.

The standalone version of Prism is still available. Download it from here: Windows (installer, archive), Mac and Linux.

Here is a quick list of Prism changes (extension and standalone):

  • We separated web applications into isolated processes, with isolated profile data.
  • Web application icon support via favicon or custom image. You can now choose the image used to represent a web application on the desktop.
  • We also added some platform specific features. Some, like “popup notifications” (all platforms) and “dock badging” (OS X) can be used via a custom webapp.js (more in a followup post). Others like “minimize to tray”, are not quite ready on all platforms. So we are holding off exposing those until the next release.
  • We fixed a lot of bugs and probably added a bunch different ones.

Now that we have a good foundation for platform features (and people who know more about Linux and OS X than me), we can start adding a few more goodies. Here are a list of things we are working on for the next release:

  • Minimize to tray support. The basics are in there now, but we have more work to do.
  • Context menu support for dock and tray. Again, we are close to having this working.
  • Support for a web content JS API so the web application itself can access some of the platform features. See bug 420661 for more information.
  • Simplified methods of embedding web application information into a website. Currently, the Prism extension uses a webapp bundle, but this can be made easier for web application authors. See bug 420878 for more information.

We are eager to hear more, so let us know what you think:

XULRunner Milestone Builds


Good news for developers who are building applications on the Mozilla platform, XULRunner in particular. The wheels are in motion to start creating XULRunner builds (runtime and SDK) that coincide with major Firefox milestones. I encourage interested developers to watch the bug to see how the discussion and plan evolves.

This is a big deal for developers building and embedding applications using the Mozilla platform. Currently, the only official Mozilla build of XULRunner is an out-of-date version. Builds based on snapshots of Firefox milestones will go a long way to creating a stable platform to build gecko-based applications.

As a platform Mozilla has a lot going for it: maturity, flexibility, standards & openness. At the same time, there is certainly more that could be done to make the platform approachable to new developers, maintainable to established Mozilla-based projects and suitable for a variety of application types. Your feedback is always appreciated. It’s ok if you just want to vent, but ideas for improving the situation are even better.