The Inside Track on Firefox Development.

May 2, 2004

Writing Firefox Extensions

A preliminary introduction to the new Extension API. It's important that you read this document if you develop extensions for Firefox or Thunderbird.

Posted by ben at May 2, 2004 1:08 AM

Comments

Date ought to be yyyy-mm-dd for those of us who think that 05/02/2004 is February.

uuidgen on *nix / Mac OS X console can generate those Unique IDs.

Can locale / skin be omitted, if they are irrelevent ?

Posted by: Chris Neale at May 2, 2004 7:18 AM

"Your server must send this file as text/rdf or the update checker will not work."

According to http://bugzilla.mozilla.org/show_bug.cgi?id=61839 the mime type for RDF will be fixed to support application/rdf+xml in 1.8a.

Does this mean that the server must incorrectly send text/rdf for the foreseeable future?

Posted by: Erik Arvidsson at May 2, 2004 11:23 AM

Why using <em:property>URL</em:property> which is semantically very poor, instead of <em:property rdf:resource="URL" /> as in every RDF vocab ?

Posted by: Eldarendil at May 2, 2004 6:07 PM

I second Chris Neale�s suggestion to use yyyy-mm-dd dates. Keep up the good work :-)

Posted by: alexanderino at May 3, 2004 5:20 AM

Can we use real URLs instead of unreadable GUIDs? I have no idea which app the targetApplication is pointing to, and I'd have to look up an app's guid every time I wanted to use it. A URL like 'http://www.mozilla.org/firefox' is much easier to identify and remember.

Posted by: Neil Deakin at May 3, 2004 7:25 AM

What about programs without an extension.rdf file and WITH an install.js file, any backwards compat there...even without an updater/installer...perhaps a warning that (This package comes without the automatic updates/uninstall, which means it was created prior to this version of firefox, There may be issues, but..."Continue", "Cancel" )???

Posted by: Justin Wood at May 3, 2004 7:24 PM

Problems with this signature from nsExtensionManager.js.in?

1277 _rootRes: function (aRoot, aRoot)
1278 {
1279 return this._rdf.GetResource(aRoot + aID);
1280 },

-Just trying to help.

Posted by: Ran at May 3, 2004 11:11 PM

Do you want to deal with overlapping vocabularies, for example with dublin core? You could probably use dc for author and others instead of em.
Though sticking to one namespace might be easier for authors, and it's not likely that we really make any use of the "I know dc:author".
Anyway, once we document this vocabulary (where?, devmo/rdf/vocabularies/? w.m.o/projects/rdf/vocabularies/? Other places?), we should give a rationale why we don't use dc or other existing vocabs.

Posted by: Axel Hecht at May 4, 2004 4:04 AM

Wouldn't it be more XML-like to split up em:targetApplication into three parts?

...
...
...

Posted by: Matthew Wilson at May 4, 2004 9:47 AM

I see my XML got eaten.

<em:targetApplication>
<em:application>...</em:application>
<em:minVersion>...</em:minVersion>
<em:maxVersion>...</em:maxVersion>
</em:targetApplication>

Posted by: Matthew Wilson at May 4, 2004 9:57 AM

Matthew, I'm trying to keep the vocab the same in the manifest as in the EM datasource itself.

When you create resources like that you're effectively saying

targetApp->ID->Firefox
->min->0.7
->max->0.8

but as soon as someone installs another extension into the same master datasource you get multiple assertions of the same object that you can't disambiguate.

e.g

myExt-targetApp->ID->Firefox
->ID->Thunderbird
->min->0.7
->min->0.5
->max->0.9
->max->0.6

thus all the metadata needs to be stored in a single property on the extension.

Posted by: Ben at May 4, 2004 12:04 PM

Shouldn't the anynomous resource created by the stuff Matthew posted take care of that ambiguity?
As in, the XML would yield to
<urn:fooext> <em:targetApplication> :_1 .
:_1 <em:id> "{daf44bf7-a45e-4450-979c-91cf07434c3d}" .
:_1 <em:maxVersion> "1.2" .
:_1 <em:minVersion> "0.7" .

(I hope that's N-Triples allright, those ascii graphs confuse me)

Posted by: Axel Hecht at May 4, 2004 1:11 PM

To be honest I never really got the hang of RDF/XML serialisation.

I just get nervous when I see internal structure inside an XML element.

Anyway, I like the look of this stuff.

Do you anticipate that the ability to install XPCOM components into the user profile directory will be added back into the Mozilla suite? (I thought that I had posted this question before on some other thread, but I can't find it now. Apologies if I'm being a muppet.)

Posted by: Matthew Wilson at May 4, 2004 1:56 PM

Some Thoughts About Versioning.

How One Could Know Which 'MaxVersion' To Use For His/Her Extension? I Mean How One Could Predict At Which Version Compatibility Between An Extension And A Target App Will Break?

Similarily, How One Supposed To Remember Which Old Versions Are Compatible And Which Aren't?

And Anyway Many Authors Would Tend To Just Nail 0.1 - 1000.0 Or Something In Order To Not Bother.

In Other Words I Think A Target App Should Always Try To Load An Extension And If It Fails Propose To Update/Uninstall It Without Breaking The Whole Loading Process.

Posted by: Maniac at May 5, 2004 1:31 AM

Axel - Interesting about the anonymous resources - that had slipped my mind. I'll try that.

I've not been using DC because this isn't really web metadata that's likely to be aggregated elsewhere (I could look at it I suppose for some of the FE data like name etc) but I'm trying to keep the internal implementation of the manager very simple (the whole system is so complex I don't want to add to that complexity).

Maniac - I would expect a safe approach would be to set min/max version to the same value (the current version of the app) e.g. for 0.9 your ext would be min 0.9 max 0.9. This is provided as a convenience so that when you discover your extension continues working with 1.0 you can update the metadata to say 1.0. You should set minVersion to the lowest version number you intend to test with, for safety's sake. There is no way to test whether or not an extension is not compatible by simply loading it. The subtleties of integration is such that you may only find something breaks by excercising a particular spot of code somewhere that isn't always called.

Posted by: Ben at May 5, 2004 3:00 AM

Thanks Ben, for the info on the min/max version problem. I had the same questions (why have a max version?). The thing is, the min and max versions go in a file in the extension itself. My extension is hard coded to work only with that max version of firefox that I specified. If my extension is coded to use firefox version 0.9 to 0.9, and then firefox version 1.0 comes out, would my extension still work? Would I have to make a modification to my extension just to say that it works with 1.0 (assuming it still does)? Would I then have to deploy it to all the users?

What I'm trying to ask is, why doesn't the min/max version go on the update rdf and not in the extension?

Posted by: Mike Goodspeed at May 5, 2004 2:40 PM

Because I need a way to stop you from installing incompatible versions from your local hard disk. Say you save foo.xpi that's only compatible with .7 to your hard disk then you try and install it. If the extension itself doesn't maintain compatibility info then you could break the app. I'm looking for ways to streamline this process however - and adding info to the update rdf might be one way of doing that.

Posted by: Ben at May 6, 2004 3:14 PM

Hmm Ben, would it be possible to 'update' an extension to say (after installed) that it works for Firefox 1.0, if the xpi said .9, or would that even be needed

(This is without having to update/re-deploy the xpi with updated rdf)

Posted by: Justin Wood at May 6, 2004 6:44 PM

My understanding of Mozilla and Firefox extensions is rudimentary, so I may not know what I'm talking about, but without install.js, how does an extension perform custom actions during installation? For example, the flashblock extension uses install.js to add custom XBL bindings to userContent.css, without which the extension is useless.

Posted by: jacob at May 8, 2004 12:21 PM

At what point will this take effect? Already on the trunk? 2 weeks? Is there any way we can plan, or start testing?

Posted by: Robert Accettura at May 8, 2004 4:33 PM

How will localisations fit into this scheme? Language packs currently use the XPI mechanism to register a bunch of locale chrome.

Do we simply add multiple <em:locale>...</em:locale> elements?

Posted by: Mark Tyndall at May 10, 2004 4:36 AM

I think it would help many platform dependent extensions to have some way to identify a specific platform, in order to prevent users from installing things on the wrong OS (I am personally regularly confronted with help requests for such accidents).

How about adding an optional <em:platform> or <em:operatingsystem> tag? If set, then installation would only be possible on that particular platform.

Posted by: Patrick Brunschwig at May 14, 2004 2:19 AM

What advantage does a GUID string have over a namespace? This GUID thing doesn't sit well with XML when you could have obvious strings http://www.mozilla.org/keymaster/gatekeeper/products.rddl#firefox

Posted by: ughhhh at May 14, 2004 8:07 AM

©1997-2006 Ben Goodger. All Rights Reserved.
Opinions expressed here are my own, and not those of any organization that I may be affiliated with.
Reload icon is © Stephen Horlander;
Firefox logo is by Jon Hicks, and is a trademark of The Mozilla Foundation.
GetFirefox buttons are from rakaz