Extension Developers – Win Some / Lose Some

Good News

The extension breaking changes made to the Firefox 3 toolbar IDs has been reverted and patched to get the same result in a different way. Any extensions that broke in a nightly version of Firefox 3 should be working correctly now. We also made sure to get the fix into Firefox 3 beta 3. Big “thank you” goes out to Dave, Dão and Gavin for helping me get the patch right and to Connor and Beltzner for making this a critical enough to get into Beta 3.

Bad News

Scriptable IO is a new extension convenience library added to Firefox 3 (bug 380813). It has a lot of nice methods for doing IO without doing much XPCOM. Unfortunately, we found a problem which is related to Scriptable IO, but I haven’t figured out exactly how yet. To fix the problem, we had to backout Scriptable IO for now. We also had some other issues with the API that need to be worked through.

I know of at least one Firefox 3 compatible extension has been affected by this backout. The workarounds are to use the more verbose XPCOM versions of the features. Hopefully, we can take a look getting Scriptable IO back in the future.

New Datasources for XUL Templating [Part 3]

I have talked a bit about the new built-in datasources (XML and SQL) developers can use with XUL templating (guide and tutorial). I wanted to wrapup my little foray into XUL template datasources by also talking about custom datasources.

A generic framework for adding any kind of datasource (bug 321170) was created as part of the work to make the new XML and SQL datasources. Creating a custom datasource involves implementing 2 new XPCOM interfaces: nsIXULTemplateQueryProcessor and nsIXULTemplateResult.

With the help of Peter van Hardenberg (of Songbird), I got a simple JavaScript implementation working and available on MDC. The sample is fairly basic, but you could extend it to expose any kind of backend datasource.

Hello JS-CTYPES, Goodbye Binary Components

I have been working on a small project that ports Python’s ctypes functionality to Mozilla’s XPCOM system. For those unfamiliar with ctypes, its a Python module that allows developers to declare and call exported methods from binary/shared libraries. Developers can then wrap these binary calls in pure Python.

The JavaScript port, called js-ctypes, will give developers this same kind of functionality in Mozilla’s privileged JavaScript. The idea for the library came after helping many extension developers through the process of building binary (C++) XPCOM components. The story usually went something like this:

  1. Developer wants functionality not built into the Mozilla platform, but easily supported by the native OS.
  2. Developer wants to use a 3rd party library in an extension or xul app.
  3. Developer has methods in native code for performance reasons.

The usual answer to these problems is creating a binary (C++) component to act as a wrapper so the native features can be exposed to JavaScript via XPCOM. However, the process of building binary XPCOM components is significantly harder than JavaScript components. The macros and memory management rules of binary components are harder than JavaScript, but its really the compiler and linker flags, IDL, makefiles and SDK versions that make the process painful. The build process must be repeated for each platform too. For many cases, its just too much work.

The goal of js-ctypes is to allow developers to declare methods in binary libraries and then expose those methods as callable JavaScript functions. Developers can then create pure JavaScript library wrappers around binary libraries – without making binary XPCOM wrappers.

Here is a really simple example of using Window’s native MessageBox call from JavaScript:

const nsINativeType = Components.interfaces.nsINativeType;
function msgbox() {
  var library = Components.classes["@mozilla.org/js-ctypes;1"]
  library.open("user32.dll"); // Load the shared Windows DLL

  var messageBox = library.declare(
      "MessageBoxW",          // name of the exported method
      nsINativeType.INT32,    // return type
      nsINativeType.INT32,    // parent hwnd (its a Window's thing)
      nsINativeType.WSTRING,  // Unicode message string
      nsINativeType.WSTRING,  // Unicode title string
      nsINativeType.INT32     // bitflag for buttons to show

  var ret = messageBox(0, "This is the message", "Msg Title 1", 3);

  // You can reuse the method
  var ret = messageBox(0, "This is another message", "Msg Title 2", 3);

The js-ctypes code uses the same libffi library as the Python ctypes module. It is currently known to work on Windows and compiles on Linux, but I haven’t got around to testing it. We need to start the Mac implementation. We also need to add support for struct and more primitive types.

The code is in SVN here and we have a Bugzilla component too (see bugs, file bug).

Note: This functionality cannot be accessed from JavaScript used in web content. Only JavaScript that runs with chrome privileges (extensions and Firefox UI for example) can use js-ctypes.

ActiveState’s Open Komodo Project

Today ActiveState announced the Open Komodo Project, an initiative to create an open source platform for building developer environments. The project overview has lots of information on the details. Here is a good summary:

Open Komodo is not a product, but rather a code base upon which Integrated Development Environment (IDE) software packages can be developed. ActiveState’s Komodo Edit (free but not open source multi-platform, multi-language editor) and Komodo IDE (multi-platform, multi-language IDE for dynamic languages and Ajax technologies IDE) are existing, mature products that will use the Open Komodo platform.

In addition to the code base, the project will also start building a web development tool called SnapDragon:

The Open Komodo Project aims to create a full-featured web development tool for client-side web development integrated with Firefox©, Mozilla’s free, open source web browser, and based on the award-winning Komodo IDE. This new tool, codenamed Komodo Snapdragon, will be developed in collaboration with the open source community.

The project timeline gives information on how the project is expected to unfold. There seem to be many ways developers can participate in the project, including just lurking on the mailing list.

This project will provide some great open source code to the Mozilla platform for development tools. This is an area that many Mozilla developers feel is lacking and has been a much talked about issue for the new MozPad group as well. I look forward to a strong community forming around the project and using the code base to create many great developer tools.

Thanks ActiveState!

WebRunner 0.5 – Now With More Power

I am really impressed by how many people seem to be using WebRunner ([1] & [2]). Personally, I still use it everyday to run GMail and Zimbra. Along the way, I had noticed some small quirks and painful bugs. The download bug (click a download link and get a XUL error message) was the one I hated the most. The window title bug (multiple WebRunner instances would cause the window title to change) was a close second.

I finally got around to fixing those and got ready to make a small release. Then I get an email from Wladimir Palant (of Adblock Plus fame). Seems Wladimir has been using WebRunner too and he also had a list of fixes and features. So I rolled his changes in with mine and the result is WebRunner 0.5:

  • Downloads now work without the XUL error
  • Better window title tracking
  • Context menu enable/disable logic is better
  • Added simple Print support via context menu
  • Added About support via context menu – useful for checking XULRunner runtime version
  • Added web application profile support – parameters for a web app can be saved to an INI-style *.webapp file. Several profiles are included in the distributions. Parameters include:
    • uri – the uri/url of the web app (http://mail.google.com)
    • icon – the icon you want to use for the WebRunner window when running this web app
    • showstatus – turns the statusbar on or off for this web app
    • showlocation – turns the readonly location bar on or off for this web app
    • enablenavigation – turns the hotkey history navigation (ALT+LEFT, ALT+RIGHT and ALT+HOME) on or off for this web app

The installer can configure Windows to associate *.webapp files with WebRunner. This means that when you double-click or launch a *.webapp file, WebRunner is launched and automatically opens the web application. Pretty cool.

I am somewhat excited to see what can be done with WebRunner. I am thinking that we could turn on extension manager in WebRunner and use extensions to provide some web application customization. Also, I see WebRunner becoming more of a desktop platform for running web applications. What’s stopping WebRunner from doing what Adobe AIR does – only better and on Linux and with native code support and with extension support.

I am going to see if we can get WebRunner hosted in a Mozilla SVN repository as well. That would make it easier for people to contribute code.

Install: webrunner-0.5-win32.exe (4.9 MB)
Source: webrunner-0.5-src.zip

Tokyo Developer Conference – FUEL & XULRunner

I was a co-presenter for two sessions at the Tokyo developer conference held a few weeks ago:

  • FUEL & Chrome JavaScript Libraries (slides) : I presented with Gomita-san (picture), a Japanese extension developer who had a detailed presentation on the ways FUEL could help extension developers. We both handled a short Q&A session at the end.
  • Building Applications with XULRunner (slides) : I presented with Taro Matsuzawa (picture), a leader of the MozillaGumi community. Taro’s presentation was about localization issues with XULRunner applications. In the process, he showed how to convert an extension to a XULRunner application. It was a cool dashboard-style, transparent clock widget. We, also, did a short Q&A session at the end.

A couple things I came away with from the conference:

  • The Japanese Mozilla community is very strong, passionate and knowledgeable. Everyone appeared to have a lot of fun and the presenters certainly enjoyed showing off their extensions. I saw a developer build an extension in 3 minutes from scratch – with the help of some well planned editor keyboard macros.
  • Unsurprisingly, Japanese extension developers have the same wishlist for FUEL as any other extension developers: support in toolkit, support in Firefox 2 and support for files/streams, clipboard, … 🙂
  • XULRunner is relatively new to the Japanese scene. There have been some experiments and articles, but it definitely has some room to grow. With the strength and size of the extension development community, I would expect to see growth in Japanese XULRunner development.

Tokyo Developer Conference Wrapup


Mozilla-Japan (Chibi, Kaori, Gen and everyone else) did a great job putting together the developer conference. I think we had over 150 attendees and over 25 presenters.

It was the first time I attended a non-English conference. However, the translators did a great job. Even during my own presentations, the translators were doing simultaneous translation during the Q&A. It was incredible.

I really enjoyed the Extension Lightning Talks and the Extension Developer Environment sessions. The Japanese presenters were not only extremely talented developers, but they also did a great job making the presentations very entertaining. They were obviously trying to “one-up” each other during the presentations and did so with great flare, showmanship and the occasional practical joke. The translators could barely keep up! I want to talk more about the kinds of extensions presented and the extension developer community in a future post. Its a very rich and dedicated group of people.

I have had a great time in Tokyo. There has been lots to see and do and eat and drink. It’s a great city and 4 days was too short to explore. Thanks to Kaori and Gen for showing us around the city, it was a lot of fun.

XULRunner Wishlist

XULRunner provides a lot of core functionality, but if you’re writing an application that is not a web browser or email client, you might feel some pieces are missing or not supported as well as they could. You may even have a list. Here’s mine:

  • Interprocess Communication (bug 68702)
  • Window transparency on all platforms (bug 307204)
  • Hiding the main window menu on Macs
  • Adding application to the system tray or appropriate location for other platforms (bug 325353)
  • Allow extensions to be associated with the runtime and not only with applications (bug 299716)
  • XUL Templates based on XML or SQL (bug 321171 and bug 321172)

These features are not critical “must haves” in order to build a good desktop application. Some of them just make it easier. Others are nice to have in the toolkit and not in patches or code that results in a custom build of XULRunner.

While I’m at it, here’s a list of developer “features” I’d like to see:

  • Simple (not perl scripts) tool for MAR file generation so applications can upgrade themselves
  • Tools to generate scaffolding for new application projects
  • Venkman (or other debugger) added to the runtime so applications can be debugged easily (sort of bug 342590)
  • DOM and Event libraries for XUL
  • Packager to “build” applications from XUL & JS

Feel free to share yours. The Mozpad group is working on a list too.

XUL Explorer – 0.4 Finally

We’ve been pretty busy around here with various sorts of things, but we finally got enough time to get XUL Explorer (XE) 0.4 out the door. XE 0.4 has some neat features that we hope will help Mozilla platform developers (extensions and applications) be a little more productive. The highlights include:

  • DOM Inspector and Venkman (JS Debugger) extensions are integrated into XE. You don’t need to mess around trying to install them. They are pre-packaged for your debugging enjoyment.
  • Extension project wizard walks you through the process of creating a Firefox extension. The wizard has options for various types of extension UI’s so you can support toolbar, menu, sidebar and context menu overlays. The extension files are generated using a simple template system, so it should be easy to tweak and add more features.
  • Simple extension testing allows you to pick an extension source folder and quickly run/test the extension in Firefox. No need to manually package and install the extension.
  • A simple XML/XUL formatter helps cleanup your code and there are a few more links to online documentation at the Mozilla Developer Center.

The extension wizard and extension tester are definitely not finished (see roadmap). The extension tester has a few planned usability improvements. The extension wizard has some general improvements coming and many new features. One improvement is support for more targets, including Thunderbird and XUL Explorer. Only Firefox really works now. Another feature is stubbing out handlers for common events, such as when a page loads in the browser.

Once the template based stabilizes for extensions, wizards are planned for XPCOM components and XULRunner applications. We’re very much interested in your feedback as well. So if you can stand using alpha software, give XE a spin and let us know what you think. What’s good, what stinks, what would make a good feature – whatever.

Big thanks to Cesar Oliveria and Paul Medlock for pitching in. Also thanks to Ted Mielczarek for the head start.

Install (Windows): xulexplorer-0.4-win32.exe 5.2MB
Install (Linux): xulexplorer-0.4-linux.tar.gz 9MB
Install (Mac): coming soon
Source: SVN
Bugs: New or View

FUEL Project Status – 0.1 Lands

FUEL 0.1 landed on the trunk yesterday. Progress had slowed since the last update mainly due to John and I having so many other balls in the air. For those intrepid enough to play with 0.1, you can use the API on the wiki and the code in the unit tests as examples.

The wiki has the plans for 0.2, which should have more features for extension developers to use. The Browser and BrowserTab helpers alone should make life easier.