Here's a diff that lets FireTray be built and run against XULRunner 1.9.x and 
XULRunner 2.0.

I changed the nsMinimize.js component to use XPCOMUtils for XULRunner 2.0 
compatibility (and it's cleaner). This required me to bump the minimum versions 
for Thunderbird and Sunbird (I think all the other supported products should 
already be compatible). Compatibility could probably be achieved without 
XPCOMUtils, but I didn't feel like investigating into it. Plus, Thunderbird 2 
is pretty much EOS/EOL, so I don't feel too bad about that.

FYI, binary components built with XULRunner 2.0 are not yet compatible with 
XULRunner 1.9.x
https://bugzilla.mozilla.org/show_bug.cgi?id=586523

But it might be more desirable to produce separate builds for XULRunner 1.9.x 
and XULRunner 2.0. That way you're not statically linking unnecessary stuff and 
you can take advantage of XULRunner 2.0 things (like mozalloc if someone can 
figure out the build issues).

Nightly builds of the XULRunner 2.0 sdk are available here:
ftp://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-mozilla-central/

New diff. Now links against the new xpcomglue_s_nomozalloc lib.

FireTray built with XULRunner 2.0 should now be run-time compatible with 
XULRunner 1.9.x. I haven't tested this (not easy on an x64 only system), but it 
should be.

Thanks for the patch, I am using a slightly modified version :

http://pkgs.fedoraproject.org/gitweb/?p=mozilla-firetray.git;a=blob;f=mozilla-fi
retray-0.2.8-fix-xpcom-registration.patch;h=4713d17203523244d69886bba30a281dc5bc
3dc8;hb=HEAD

FYI that build will not be compatible with XULRunner 1.9.x applications (no 
mozalloc support). If that was the intention, theres not much point in keeping 
around the other 1.9.x compatibility code either.

Also, according to the XPCOM Glue documentation, you should not be linking 
against xpcomglue and xpcomglue_s at the same time.
https://developer.mozilla.org/en/XPCOM_Glue

Before I pushed that build, I tested it with all applications available in 
Fedora :

- Firefox 4.0b4 (xulrunner-2.0b4)
- Seamonkey 2.0.5 (gecko-1.9.1.10)
- Thunderbird 3.1.3 (gecko-1.9.2.9)
- Sunbird 1.1a1pre (gecko-1.9.2.9)
- Chatzilla 0.9.86 (xulrunner-2.0b4)

And they all worked without problems

If I build with mozalloc, and install it into Firefox 3.5 (Gecko 1.9.1), I get

Failed to load XPCOM component: 
/tmp/ff/extensions/{9533f794-00b4-4354-aa15-c2bbda6989f8}/components/libnptray_x
86_64.so

However if I add -DMOZ_NO_MOZALLOC and only link against xpcomglue_s_nomozalloc 
it works fine. Do you have a system-wide install of XULRunner 2.0 that the 
extension could be dynamically linking against?



Also, new diff. Fixed building with mozalloc (thanks hicham.haouari for the 
mozilla-config.h tidbit). Added a command line flag to control Gecko 1.9 
compatability when building with Gecko 2.0

I admit that my approach isn't suitable to make firetray redistributable via 
the addon manager.

But I have been constrained by the lack of xpcomglue_s_nomozalloc, since 
xulrunner-2.0b4 in Fedora is compiled with mozalloc support. The downside is 
that xulrunner will be pulled even for applications that do not use it ( 
Thunderbird, Seamonkey, Sunbird).

xpcomglue_s_nomozalloc was added in 2.0b5.

Since I assume it's being built out of the Firefox package, 4.0b6 was released 
yesterday. So update and you should be all set.

Thanks, I will have to wait for xulrunner to be updated as it is not mine.

New diff. Thunderbird just had a version bump. I think the intention is 
Thunderbird 3.2 will use XULRunner 1.9.2 and Thunderbird 3.3 will use XULRunner 
2.0.

Also, extensions with binary components are kind of broken on Gecko 2.0 right 
now because they're not installed unpacked anymore. So I added 
<em:unpack>true</em:unpack> to the install.rdf to force them to be unpacked. 
This should be removed later, when it's fixed.

Thunderbird 3.1.3 uses gecko-1.9.2.9 FWIW

Re-base patch to current trunk (revision 112).

Also, this changes the Gecko 1.9.x compatibility command line flag from 
"--no-gecko19" to "--gecko19-compat". Basically, it's a change from enabling 
Gecko 1.9.x compatibility by default to disabling it by default.

Issue 155 has been merged into this issue.

Issue 157 has been merged into this issue.

Issue 159 has been merged into this issue.

Is anyone going to post a test xpi soon ?

Yes, after fixing some problems with the virtual machines used to build the 
component, I will prepare a test release and publish it in the download area. 

http://code.google.com/p/firetray/wiki/firetray030svn117

Fine! Works great with FF4.0 on Ubuntu 10.10 64bit. Thanks.

Works in debian squeeze 6.0.1 32bit

fine with ff 4 on gentoo 64 bit