Archive for XPCOM

Mozilla Platform, Wizards and FizzyPop

Building things with the Mozilla Platform usually involves dealing with some boilerplate. Extensions have install and chrome manifests and overlays. XULRunner applications have application and chrome manifests and default preferences. XPCOM, even the simpler JavaScript XPCOM, has modules, factories and categories. It’s more than enough to slow developers down, especially new-to-Mozilla developers.

That’s why I have always been thankful to Ted Mielczarek for his Extension Wizard and JS XPCOM Wizard. Those tools have been helpful to me and countless other Mozilla developers.

Because of their great utility, I started to think that Mozilla should host, develop and extend the tools. Turns out, this pleases Ted :) - Therefore, I’ve put together a plan for FizzyPop, a simple project to develop/extend tools that assist Mozilla developers.

I had done a similar project with XUL Explorer, template-driven wizards to create extensions and xul applications. Turns out the Web has a wider reach than a desktop tool, especially for these types of scaffolding projects. In any case, I am taking the templates I use in XUL Explorer and converting them for use in a PHP web application.

I plan to get an SVN repo, bugzilla support and a Mozilla hosted for the project. We want to turn this into a contributor-base project. I’ll let you know when the prototype is ready to start hacking.

Comments (16)

XULRunner 1.9 RC2

A while ago I posted about getting XULRunner builds to coincide with Firefox milestones. Work has been moving ahead on the goal. In fact, we have XULRunner 1.9 RC2 binary runtimes and SDKs available for testing. If you use XULRunner, or want to use XULRunner, you should grab these builds and give them a spin. Let us know (file bugs) if you see something wrong.

Another great addition for XULRunner developers - Microsoft symbol and source server support. Look here for information on Mozilla’s symbol and source server support. Just use http://symbols.mozilla.org/xulrunner instead of the Firefox URL. This is a huge deal for helping developers debug problems using the non-debug releases of XULRunner runtimes and SDKs.

If you haven’t tried using XULRunner yet, now is a great time to start. Use markup/JS/CSS to build real desktop applications using native OS look-n-feel, with complete access to custom and OS binary functionality.

Look for more cool XULRunner developer support coming soon.

Comments (4)

A Little XPCOM Magic - JavaScript Callbacks

XPCOM is, currently, a core Mozilla technology. Developers use XPCOM for a variety of reasons, many of which result in XPCOM components being accessed from JavaScript. XPCOM uses IDL to describe interfaces. This can make XPCOM components a bit rigid and not feel right in JavaScript. Recent support for optional parameters in IDL has helped a little. Another helpful concept is using JavaScript functions in place of an IDL callback interface. For example:


[scriptable, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

[scriptable, uuid(...)]
interface StringParser {
  void parse(string data);
  void addObserver(StringParserObserver observer);
};

In order to use this interface from JavaScript, you would have to implement the StringParserObserver using JavaScript. A nicer approach would be to allow someone to pass in a JavaScript function to use as the callback. The good news is you can! Better news is that it is a one line change to your IDL!

Just add the “function” attribute to the interface and XPCOM will handle the rest.


[scriptable,function, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

There is a new MDC article with more details here.

Comments (2)

Mozilla 2 - The Future of the Mozilla Platform

Firefox 3 is not even out the door, but work has started on the next refactoring of the Mozilla platform. Dubbed Mozilla 2 (FF3 is built on Mozilla 1.9), it is a chance to make lots of interesting, even scary, changes to the platform. For some background on Mozilla 2 go back and read Brendan’s post. Also, read the Mozilla 2 wiki pages.

Actually, lots of work has already been completed and lots more work is underway. Checkout the notes from the status meetings. You can call in every Wednesday to hear what’s happening. The work on ActionMonkey and XPCOMGC is pretty exciting stuff (for geeks, I know).

Another of the more exciting goals of Mozilla 2 is the move to use more JavaScript and less C++. Yes, C++ is great for those times you really need it (performance & native APIs), but JavaScript can handle many things better, easier and without a compiler. Mozilla 2 is adding a lot of improvements to JavaScript as well, making it faster too.

Less C++ is really part of the “Less Binary Code” theme of Mozilla 2. Another part of that theme is reducing our XPCOM footprint. Benjamin Smedberg recently posted some information about goals for XPCOM in Mozilla 2 to the Wiki and Newsgroup. See Benjamin’s older post on XPCOM changes too. I encourage any extension, embedders and XUL application developers who use binary code to go and read the information.

Comments (9)

Extension Developers - Native JSON Parsing

Firefox 3 is using JSON to store data in several places - such as bookmark backups, session restore, and offline manifests. Originally, JSON parsing was scattered through the code. Then it was consolidated to JSON.jsm, a JavaScript code module. Eventually, it was converted into nsIJSON.idl, a C++ XPCOM Component. What does this mean to extension and application developers? Well, you now have access to JSON encoding and decoding routines that can be a lot faster (more in a bit) than the JavaScript counterparts.

var testObj - { name: "Jimmy", age: 25, loves: ["XULRunner", "sunrises", "Mt Dew"] };

// encode to string using javascript implementation
Components.utils.import("resource://gre/modules/json.jsm");
var testJS = JSON.toString(testObj);

// encode to string using native implementation
var Ci = Components.interfaces;
var Cc = Components.classes;

var nativeJSON = Cc["@mozilla.org/dom/json;1"].createInstance(Ci.nsIJSON);
var testNative = nativeJSON.encode(testObj);

Of course, you can also encode to a string using the json2.js code at json.org

I put together a little benchmark (on bug 410890) to get a feel for the speed improvements that could be obtained using native JSON parsing. The code iterates over a fixed chunk of JSON (taken from Robert Sayre’s unit tests) multiple times. The number of iterations are on the x-axis while the milliseconds required are on the y-axis:

Encoding
json-object-encode.png

Decoding
json-object-decode.png

I found that John Resig did some JSON benchmarking last year, so I made a second benchmark script (same bug) that used his 1600 item array as the JSON source. This code takes the 1600 item array and breaks it into variable sized chunks, then sends those different sized chunks into the JSON parsers. The chunk size is on the x-axis while the milliseconds required are on the y-axis:

Encoding
json-array-encode.png

Decoding
json-array-decode.png

The tests show a very nice performance improvement for encoding JavaScript objects to JSON data. The performance improvements for decoding JSON data into JavaScript objects is smaller, but still very worthwhile. For the curious, the original native JSON code was further optimized to increase the improvements.

Note: Currently, native JSON is only available to privileged code with access to XPCOM. This means that web content JavaScript is not yet able to access the feature. Working is moving ahead in this bug to get these APIs exposed to web content as well. Exposing APIs to web content is something that needs to be thought out and perhaps standardized. There was a proposal to add JSON encoding/decoding to ES4, which seems to have been dropped. Maybe the WHAT WG will draft something.

Check out John Resig’s post on the State of JSON for lots more information on JSON, web content and standards.

Comments (2)

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.

Comments (1)

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.

Comments (7)

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"]
                          .createInstance(Components.interfaces.nsINativeLibrary);
  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);
  alert(ret);

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

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.

Comments (22)

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!

Comments (3)

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

Comments (49)

« Previous entries