This is a public service announcement for those people interested in the future of JavaXPCOM. JavaXPCOM has been disabled and will likely to removed from the Mozilla source tree in the future. See Benjamin Smedberg’s newsgroup post for more details.
Please follow up (add comments) to the newsgroup post.
If you’ve developed applications or extensions using the Mozilla platform, you know that there are tons of services and APIs available. We use those same capabilities when building Fennec. However, there are times when the default platform behavior is not desirable on mobile devices. When that happens, we could hack up our own system, or we could re-implement the platform APIs to suit our needs. We try to do the latter.
Here are some APIs that have been reimplemented in Fennec: nsIAlertsService, nsIPromptService, nsIDownloadManagerUI, and window.openDialog(). The primary reason all of these APIs have been reimplemented is that they open new XUL windows. We don’t like doing that in Fennec. Mostly because opening a XUL window is slow. But also because we love having tighter control over the look, feel and behavior of the UI elements.
Services
Since we re-implement the interfaces, nsIAlertsService, nsIPromptService and nsIDownloadManagerUI can be used just as they are on the desktop. The big difference is that none of them open new windows. The UI is embedded into the main window itself. It’s faster to display and easier to control and style the UI elements. In the case of the download manager, it’s designed to be embedded in the main window.
Dialogs
On the other hand, we couldn’t exactly match the way window.openDialog() worked, so we created a slightly different API: importDialog(). The big difference is that importDialog() actually merges the XUL dialog into the main window. It does not open a new XUL window.
importDialog(aSrc, aArguments);
aSrc: The chrome URL of the XUL dialog
aArguments: A JavaScript object used to pass data to the dialog
The XUL passed to importDialog() is very similar to XUL passed to window.openDialog(), with some limitations and caveats:
Only top level elements are permitted
Scripts are loaded via an attribute on the element, not via the tag
Here is an example:
The XUL is merged into the existing window, almost like a XUL overlay. Because of this, element ID and JavaScript conflicts are possible, just like overlays. So be careful!
Obviously, add-on developers should use these features. We are looking for feedback as well. Perhaps we could get importDialog() working more like window.openDialog().
The newest official XULRunner has been released. XULRunner 1.9.0.11 matches the Firefox 3.0.11 release. For XULRunner developers, most of the changes in 1.9.0.11 are related to security and stability fixes. SQLite was upgraded to version 3.6.7.
The coolest thing about this XULRunner release is how it was done. Mozilla’s Release Engineering group is now doing official XULRunner releases at the same time as Firefox releases. Previously, someone would manually file a bug, make a patch, spin the builds and push the bits. A big thank you to the release crew for adding this to their release process.
Want to get started building XULRunner applications? We have an article for that. It’s way better than the crappy XML UI framework you’re currently using π
Mozdev and Mozilla Europe have teamed up to create a Firefox Mobile (Fennec) Add-ons Challenge. The goal is to create or port add-ons to Fennec. You only need to propose a concept for now, but you’ll need to get the add-on ready for the upcoming Mozilla/Maemo developer weekend in Copenhagen on May 30-31.
I am interested to see innovative ideas for using the limited UI in Fennec, add-ons that focus on mobile-specific functionality, and code that exposes more of the Maemo device functionality to Mozilla (yes, XPCOM is likely involved).
I also wouldn’t mind some applets (either as add-ons or XUL apps) running on Maemo. Think about mobile-specific Chatzilla or FireFTP for example. By mobile-specific, I mean dramatically different UIs, not just porting the existing desktop UI. If many little focused applets work for the iPhone, why not for other mobile platforms? And with XUL/JS, it’s pretty easy to build them. Anyone got a XUL-based Twitter app? π
As always, we love to hear feedback from anyone building add-ons or apps on our mobile stack. Post comments, file bug reports, visit the IRC channels (#mobile & #extdev).
I decided to take a detour in my XULRunner session at MozCamp. I have done several XULRunner talks over the last few years. I usually focus on the functionality built into the platform and discuss the benefits of using Mozilla technologies to develop applications.
This crowd was very Mozilla savvy and many had at least experimented with building XULRunner applications. So, instead of my normal slide deck, I went with a “walk-through” of using the Mozilla build system to create a XULRunner application. I did the same with setting up an auto-updating XULRunner application. I think the Mozilla build system is something any XULRunner developer should learn and setting up auto-updating always seems to frustrate developers.
The talk went very well. Thanks to Robert Kaiser for helping me fill in some blanks. We had some good discussion and I could have spent a lot more time covering some of the smaller details. I think I might look into expanding this “walk-through” format.
Another topic we talked about was the potential of XULRunner on mobile devices. Many developers are excited to see XULRunner become available for mobile platforms. The ability to move XUL applications from desktops to mobile devices is fairly powerful. Fennec, for example, runs just fine on any supported XULRunner platform – without any changes.
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.
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.
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.
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:
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.
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.
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
Decoding
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
Decoding
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.