If you’re a hacker who wants to help out Mozilla (and especially XULRunner), I’ve got a couple bugs that need owning: they both have to do with converting a cross-platform image format (probably PNG) into a platform-specific icon format.

Bug 314651

API to generate Mac .icns from a PNG image

Bug 314030

API to generate Windows icons from a PNG image

If you’re able and willing to help, please comment in the bug… I’ve got people who can help you with the Mozilla-API side of things such as getting image bit data from a PNG.

The term “GRE” is shrouded in mystery and especially on linux there is no good definition of what a GRE actually is (or was). I have written a couple of Mozilla Developer Center documents on how to use the GRE (dynamic linking and the standalone XPCOM glue), and how GREs are registered.

I’d like to make a few clarifications of terms that have been floating around:

GRE

Gecko Runtime Environment: the “platform” parts of Mozilla, which is registered with the operating system in such a way that embedders can dynamically link against it without knowing in advanced where it will be installed. This was shipped with the windows installers of Mozilla 1.4 to 1.7, but technically has never been shipped on Linux. Red Hat has shipped GRE-registration files that make the Mozilla installation into an embeddable GRE. XULRunner is the new product that will be the GRE.

XRE

XUL Runtime Environment: this is the term that was floated for a long time to be an framework to launch XUL applications. It has morphed into XULRunner, and there really isn’t any reason to use the term XRE any more (there never was anything that we shipped as an XRE).

XULRunner

XULRunner is a product that will serve as the installable Mozilla platform. It will be a GRE with embedding services, as well as a bootstrap mechanism for launching rich-client applications like Firefox. Firefox 3 will be built atop XULRunner and will be the primary distribution mechanism for XULRunner.

LibXUL

LibXUL is a implementation detail of XULRunner. It is a dynamic library containing all of “gecko”. The real benefits of libxul are that we only export frozen symbols from it, and that we can perform various optimizations such as minimizing the effects of the PLT.

There is a bug in GCC 4.0 (and 4.0.1 and 4.1) which breaks the Mozilla/Firefox/Thunderbird build on x86_64 and various other processors: GCC is treating the builtin functions such as “memset” and “memcpy” as having hidden visibility in certain circumstances that are hard to figure out. GCC bug 20297 covers the issue, though the patch in the bug doesn’t fix all the problems and I haven’t seen any action by the GCC maintainers to get the patch landed or fixed. I tried to provide a patch to detect this bug in Mozilla bug 307168, but apparently my configure test is not good enough to catch all instances of the bug.

In the meantime, if you experience the error “relocation R_X86_64_PC32 against `memcpy@@GLIBC_2.2.5′ can not be used” or something similar while building mozilla, use the following hackaround:

ac_cv_visibility_pragma=no path/to/mozilla/configure --enable-options-here

or put this in your mozconfig:

ac_cv_visibility_pragma=no (Don’t prefix this with ac_add_options!)

A not-atypical winter weather forecast for Johnstown: “3-6 inches of snow; 10-12 inches in the higher elevations.” Suzanne and I live on the highest elevation in town:

One of the most frequent and persistent complaints about XULRunner is that I have explicitly excluded support for client/server SQL databases. Some have even gone forth to say that lack of proper database access in the platform will be it’s Achilles’ heel. And so I’m going to try and address this issue head-on:

XULRunner does have a database strategy: the platform will provide support for a SQLite embedded database API reflected into XPCOM. It will not include support for client/server database mechanisms such as MySQL/Oracle/etc. This reasons for this are fairly simple: The primary targets of XULRunner are twofold: support the Mozilla rich-client apps (Firefox and Thunderbird); and allow innovation of networked rich client apps based on web technologies. Client/server databases really don’t have any part in this strategy; Mozilla would not have any real testing/QA framework for this code if it were included. We need to keep a lean and focused platform that does not try to solve everyone’s problems.

Having said that, there are a couple solutions for doing client/server database access:

1. Jan Varga has done client/server database code which lives in extensions/sql. If an app really needs client/server database access, it can ship the SQL extension with the application; I’m going to work with Jan to get this code into shape as a real platform-level extension and make it available on http://addons.mozilla.org/.
2. It’s not that hard to write a web proxy which takes SQL, performs a query, and returns the results as XML: AJAX-style web apps could use this to perform SQL-based queries over XMLHttpRequest. This will be even more useful once Neil Deakin completes the template work.

I’ll have a few cool XULRunner demonstrations up shortly, including a popular AJAX-style webapp in it’s own XULRunner process (hopefully with minimize-to-tray and everything), and the beginnings of some dashboard-like widgets written in XUL+SVG that are loaded directly from the web and have web-based security permissions.

The Linux installer for Firefox is terrible:

1. It is not packaged as a self-extracting executable, but a tarball that the user must manually unpackage before running;
2. It doesn’t provide any extra value compared to simply unpacking a Firefox tarball:
   • No OS integration;
   • No shortcut generation.

For these reasons, and because nobody has stepped up to create l10n repackaging of the Linux installer, I believe that we should not ship the Linux installer for Firefox 1.5, and I have filed a bug to that effect (bug number to remain hidden to avoid spammage). If you disagree with my decision, please email me directly and let me know why (and how much work you’re willing to do to make the Linux installer actually useful).

It is now possible to use XULRunner to install XUL applications in an OS-appropriate manner. The code for Mac is already checked in, and the code for Win/Linux is under review in bug 306689. This was most important on Mac, because unless there is an application bundle for the XUL application, the UI is basically nonfunctional.

To install a XUL application which you have in a ZIP/XPI file:

Mac

/Library/Frameworks/XUL.framework/xulrunner-bin -install-app /path/to/my/application.xpi

Windows

/Path/To/xulrunner.exe -install-app /path/to/my/application.xpi

Linux

/path/to/xulrunner-bin -install-app /path/to/my/application.xpi

It is also possible to install directly from an unpacked directory (xulrunner-bin -install-app /path/to/my/unpacked-application). But please note that the INI file must be called “application.ini” in the root of the XUL Application package, it may not be named “chatzilla.ini” or any of the other custom filenames that have been floating around.

Next steps:

1. GUI installer to drive the same process
2. Developer-mode process that uses symlinks instead of actually copying the files (mainly useful on Mac).

Robert Accettura writes

… You can have a ‘feature’ like Microsoft Office’s Mail Merge. It’s messy, has an awkward UI, and doesn’t always behave as the user would expect. It’s often considered to be one of the worst features in the entire suite…. I think that’s an example of the ugliness Asa hope to rip out (though different product [sic]).

I seriously hope that Robert wasn’t for one second suggesting that Microsoft Office ought not have mail merge. Mail merge is one of those daily activities in some environments that absolutely is part of a complete word-processing/office solution. You can’t just go around removing features because they have byzantine or even terrible UI. Features, even features that are only going to be used by 20% of the user population are necessary to sell a product. The trick is not to remove features, but to make their use as painless as possible for the people that need them, and as invisible as possible for the people that don’t.

At the same time, it is extremely important to understand that that Microsoft Office and Mozilla Firefox are in very different classes of software. A web browser is primarily a platform so that web content can do it’s stuff. All the fancy bookmarks and history integration planned for Firefox 2.0 is not there because users want fancy-pants bookmarks, it’s there so that the user can get to what they actually want to be using (the web) faster and better.

Neil Deakin points out a well-done parody of platforms and frameworks. Which got me to thinking: how is XULRunner different from these megalithic platforms? The most important part is that we’re not trying to do everything. In fact, one of the most important parts of my job is deciding what’s out. This is a balancing act, but I try to use these two guidelines to shape my decision:

1. Would most XUL apps use this feature?
2. Is it something that couldn’t be done as an extension or reusable application code?

If both questions come up “yes”, I am much more inclined to take a feature than if either answer were negative. For example, I am seriously considering incorporating the binary bits of DOM Inspector into XULRunner, as well as the binary bits of Spatial Navigation. Both of these features are tightly linked up with the gecko internals and there are some good ways that they can be reused.

I have rejected other features for similar reasons: generic SQL support is out (integration with MySQL and other databases) because it’s easy to build as part of your application and because it’s not likely to be generally useful.

I am not a skilled graphic artist. This is by no means a “final” XULRunner logo. I just created it in my spare time and it is a lot of fun:

In case you don’t remember your Greek mythology, Atlas was condemned to bear the heavens upon his shoulders by Zeus as punishment for leading the Titans in their war against the gods. I thought that the idea of holding up the Firefox globe was a fitting visual metaphor for XULRunner.