Just Browsing

Mozilla Prism Update

May 21, 2008 – 8:53 pm

We’ve been hard at work on Prism since the 0.9 release in March, and there is a bunch of fancy new features nearing completion. Once we’ve finished testing and tweaking the code, I’ll make some preliminary builds available for folks to hammer on.

Here’s a run down of what’s new, with plenty of gory implementation details for those who are interested in that type of thing.

OS X Improvements

As a devoted convert to the Church of Mac, I’ve tried to get Prism running as well as possible on OS X. Prism 0.9 creates bare bones app bundles on OS X that define some of the basic properties of the app (mainly just Info.plist and icons) but spawn the main Prism bundle in order to execute the application. This has some unfortunately side effects. In particular, the name of the app is displayed as “Prism” in the application menu, and depending on the circumstances the Prism icon may be displayed in the dock instead of the app’s icon. The resulting impression is of an application tacked on top of Prism, rather than the illusion we are trying to create of a true desktop app.

To fix this, I moved much of the Prism code into an extension (prism-runtime@developer.mozilla.org). This can be referenced from each app bundle by including its path in a text file (whose name is the extension’s ID) in the extensions directory of the bundle. (I’m sure this trick must be documented somewhere.) The script to run the app looks like this:

export GRE_HOME="/Users/matthewgertner/Development/prismbase/prism/dist/PrismDebug.app/
  Contents/Frameworks/XUL.framework"
exec "`dirname "$0"`/prism" -override "/Users/matthewgertner/Library/WebApps/
  gmail@prism.app/override.ini" -webapp gmail@prism.app

As you can see, the XULRunner runtime itself is referenced from the main Prism bundle as well, using the GRE_HOME environment variable. In this way, only the actual Prism executable stub (which is tiny) needs to be copied into each app bundle. The result is a much more polished integration of Prism apps into OS X without needless duplication of Prism and XULRunner runtime files.

Splashscreen

Big Ajaxy web apps can take a while to load, and it’s disconcerting to stare at an empty white window while you’re waiting. In the case of Prism, just the basic parsing of initialization data and requesting the app’s main page can cause a perceptible lag, especially on slower computers. To fix this, I implemented basic support for a sort of web splashscreen. To use it, just place a line like this in your webapp.ini:

splashscreen=myfile.html

This is implemented by running a small script just after the <browser> tag is parsed in the main Prism XUL page, setting the “src” attribute of the <browser> to the HTML page. (Like so many Mozilla tips and tricks, I found out from Christian Biesinger that scripts are executed by Gecko as they are encountered during parsing, not once the entire page has been parsed.) The result is near instantaneous display of the “splashscreen”, which is replaced by the actual web app’s page once it has loaded.

Platform API

One of the main goals of Prism is to experiment with ways to improve the user experience of web apps. To achieve this, web apps need to provide additional information beyond their standard user interfaces (generally delivered to the client as HTML, JavaScript and often Flash). Broadly speaking, there are two options in designing APIs for web apps to access Prism functionality:

• Markup: new tags can provide additional data that Prism (and future versions of Firefox and other browsers) can use to enhance the app’s UI. For example, a mail application might include markup (perhaps a microformat or microsummary) specifying how many unread messages are in the user’s inbox. This data might be displayed as a dock badge (by Prism on OS X), as a tray icon tooltip (by Prism on Windows), as some sort of badge in a browser tab (in Firefox) and in a myriad of other ways we have only begun to explore. The markup-based approach is descriptive (as opposed to procedural), and as such is consistent with the general philosophy of the web. There is also a host of application-oriented markup that we can leverage so we don’t end up reinventing the wheel.
• JavaScript API: despite the appeal of a descriptive, markup-based approach, there are advantages to providing a JavaScript API as well. This gives the web app developer more control over how their application interacts with the new features. It can also be more efficient since watching for changes in a site’s markup can be expensive.

The right solution is probably to provide both kinds of APIs, possibly using the JavaScript API as the underlying implementation for the markup-based API. For the time being, we’ve been concentrating on designing and implementing a clean, simple platform API.

The platform API is implemented as a JavaScript global property, a bit of magic that makes a specific component accessible from every window object in a JavaScript application. (Alex Vincent has a good write-up of the general principles involved, although I would recommend using our code as an example since it uses some more modern constructs like XPCOMUtils.) The main interface implemented by our global property is nsIPlatformGlue. I’ll describe specific features in subsequent sections.

Note that the platform API is very much in flux. Some of the newer features (like protocol handler registration) haven’t even landed yet. We’re hoping to get as much feedback as possible about the idea of a platform API in general, as well as the specific way the current API has been designed. It is bound to change in strange and unpredictable ways, so exercise appropriate caution when using it.

System Tray Icon and Minimize/Close to Tray

A tray icon can be displayed on Windows by adding the following line to your webapp.ini:

trayicon=true

The icon can also be shown and hidden programmatically using the platform API:

window.platform.icon().show();
window.platform.icon().hide();

(It would be nicer if “icon” were a property rather than a method, but this won’t be possible until bug 304048 is fixed.)

You can also change the title of the icon (used for the tooltip) by setting it’s “title” property. The “behavior” property can be used if you want your app to minimize and/or close to the system tray:

window.platform.icon().behavior = Ci.nsIApplicationIcon.HIDE_ON_MINIMIZE |
  Ci.nsIApplicationIcon.HIDE_ON_CLOSE;

Minimize to tray means that the application window is hidden when it is minimized. It can be restored by clicking on the tray icon. Close to tray means that the same thing happens when the X in the app’s title bar is clicked (i.e. it is hidden but keeps running). To close the app completely, choose Exit in the system menu.

The implementation contains vestiges of Mook’s MinimizeToTray extension, as well as some of my own work on generic tray icon support for XULRunner apps. Interest in this type of support remains high, so hopefully the code in Prism will eventually find its way in some form into XULRunner proper.

Dock and Tray Icon Menus

One of the biggest advantages of integrating a web app more tightly with the desktop is the possibility of providing new and potentially more ergonomic ways of interacting with the app. Dock and tray icon menus are an example of this. On the urging of Mike Shaver, Prism uses menu markup from HTML5. This sounds fancy but is actually boringly simple. Just add <command> tags to the <head> of your webpage with “id” and “label” attributes. A DOMActivate event is sent to the tag when the menu item is selected. If you can’t or don’t want to change the web app directly, you can insert <command> tags using DOM methods in the load() handler of your webapp.js file (an optional file located next to webapp.ini in the app’s home directory).

Items are added to the dock/tray menu like so:

window.platform.icon().menu.addMenuItem("myMenuItemItem");

Dock Badges

You can add a badge to the dock icon on OS X (e.g. to display the number of unread messages in a mail app) like this:

window.platform.icon().badgeText = "12";

The implementation is currently based on ancient code from Thunderbird, but I am planning to port it to more modern APIs and provide some more flexibility in formatting the badge (fonts, colors, placement, etc.).

Protocol Handlers

A key aspect of desktop integration is the ability to use a web app as the default handler for a specific type of URL. Taking again the example of a mail app, I might want Gmail or whatever webmail I use to open in Prism when I click on a URL with the mailto: scheme. This can be accomplished using Prism’s protocol handler support:

window.platform.registerProtocolHandler("mailto", "http://mymailapp.com/compose?to=%s");

This installs the protocol handler in the system registry (or Launch Services database on OS X), so the Prism app is automatically started when the URL is clicked. If it is already running, the existing instance is used to open the appropriate page.

This approach is a bit problematic for large Ajaxy apps like Gmail, since gobs of JavaScript have to be reloaded when a protocol handler is invoked. We are therefore planning a second API that will let the app specify a JavaScript callback to be used if the app is currently running.

---

For an example of how a sophisticated webapp.js can use some of these features, see the great script that Steve Krulewitz has written for Gmail (a work in progress but one that I already find indispensable for use with my own prismified Gmail app). I’m planning to extend the script to support dock badges and protocol handlers, if Steve doesn’t beat me to it.

A much-discussed point has been how these new features and APIs can be used in Firefox as well as Prism. Please don’t take any of the above as set in stone. I hope that by posting this we can get some constructive feedback about what’s good, bad and ugly about the way our API is designed. Note also that most of the above-mentioned features are implemented only on Windows and OS X at present. I am planning to port them to Linux when I have time, but naturally contributions would be most welcome.