Before publish new updates for my extensions I try to test them on every application declared supported on install.rdf, this is a very expensive activity when a specific extension runs on different kind of applications and versions.

I add support for a new application (e.g browser, email client, multimedia applet)

• when I use the application itself and I need the extension functionality on it
• when other users ask to me

Now I must decide to drop support for some applications and for specific versions to simplify my release tests cycle.

In some cases it’s easy to decide, for example Firefox 2.x is no longer supported by Mozilla and users continuing to use it are braves or simply fools.

Supporting SeaMonkey 1.x is very hard for me, no special technical problems SM is a very good product but I simply don’t use it.
Instead I’m a satisfied SeaMonkey 2.0 user since alpha1 version.

Supporting Flock, the “social” browser, is easy due to the fact is very compatible with Firefox 3.x but sometimes little differences caused me headaches.
I think to drop support for extensions not Flock centric considering the decision taken from its team last December

Komodo 4.x is no longer upgraded by ActiveState but many people continues to use it, Komodo has a commercial version, KomodoIDE, and not all users purchased the upgrade (me too) so it is very difficult to drop the very old 4.x architecture.

NVU is dead but many users continue to use it also if its sibling/son Kompozer should be strong preferred.

What specifically means “discontinue support”

I would to remove specific tricky code present in extensions to make them cleaner but this can be a bad solution, regressions are always possible so the cure can be worse than the disease…

Removing SeaMonkey 1.x support will make my extension build system cleaner no longer install.js, contents.rdf  and informations present both in install.rdf and chrome.manifest, obviously I don’t discard support only to remove a couple of configuration files but I consider it another complication.

So, “discontinue support” for me means moving attention and energies on applications (and versions) I can test easily, on application I daily use, on applications I receive feedback from other users.

I use many applications written using Mozilla technologies, these applications support the so called profiles allowing users to run multiple instances of same application but using different “configuration” environments.

As developer I use profiles to test extensions without compromise the integrity of my main env.

Running multiple profiles is described in million of places so I don’t annoy you but I describe my own solution based on a bash script that hides details.

Creating bash scripts to run separated application profiles requires only a bit of shell programming experience but it is a repetitive task and can be boring when you need to run different version for example firefox 2 and firefox 3, you manually must write the same script modifing only the application path.

My approach allow to configure applications to run in a single file and then create automatically the necessary scripts.

Suppose you want to run a new songbird profile, using my script you can write:

dave@dafihome:~$ sb

The sb script creates a new separated profile on a configured directory with a default name, but suppose you need a second (third and so on) songbird profile you can pass your preferred name

dave@dafihome:~$ sb testVSW

Now you need to test also Firefox 2.x and Firefox 3.x profiles, simply write

dave@dafihome:~$ ff20 testVSW
dave@dafihome:~$ ff30 testVSW

So you have three separated profiles with same name testVSW, how they don’t clash? The real name created by script uses the application prefix so the directories names are

• sbtestVSW
• ff20testVSW
• ff30testVSW

Do you need Komodo 4.4.x and 5.x profiles? Again

dave@dafihome:~$ ko4
dave@dafihome:~$ ko5 italian-locale

Configuring applications

The names sb, ff20, ff30, ko4 and ko5 are configured in ‘~/.moz_profilerc’

The file format is very similar to fstab and contains three columns describing applications.

The first column contains the type of application.

At this time it can be set to mozapp or komodo, this is necessary because mozilla apps uses MOZ_NO_REMOTE env variable to run separated profiles instead komodo uses KOMODO_USERDATADIR.

The second column is the script name user runs from command line (and is also the prefix added to profile directory names)

The third column contains the application absolute path

Below is shown my configuration

mozapp     ff30          /opt/devel/mozilla/ff30/firefox
mozapp     ff30en        /opt/devel/mozilla/ff30en/firefox
# ff20 refers to installed firefox
mozapp     ff20          /usr/bin/firefox

mozapp     flock         /opt/devel/mozilla/flock/flock

mozapp     komp          /opt/devel/mozilla/kompozer/kompozer

mozapp     sb            /opt/devel/mozilla/Songbird/songbird
mozapp     mccoy         /opt/devel/mozilla/mccoy/mccoy

komodo     ko5           /opt/devel/mozilla/ko5/bin/komodo
komodo     ko4           /opt/devel/mozilla/Komodo-Edit-4/bin/komodo

Profile destination directories

I group profiles by extension, for example inside ViewSourceWith source directory I have a ‘profile’ subdirectory where all profiles are written, this is specified in ‘~/.moz_profilerc’

# Directory where profiles will be created, inside profile present on current directory
profileDir      $PWD/profile

# If true create profileDir silently, otherwise generate error
profileDirCreateSilently    false

It is possible to write all profiles inside a specific directory setting profileDir

profileDir      /devel/mozapp/profiles

Scripts destination directories

The scripts sb, ff20, ff30, ko4, ko5 are symbolic links, they are generally created inside a directory present on $PATH env variable.

I prefer to add them inside /usr/local/bin (this should require to be root)

# Directory where links will be created, generally resides in env PATH
linkDestDir     /usr/local/bin

The script moz_profile.sh

All operations are done using the script moz_profile.sh that allows to edit configuration file and create applications scripts.

Editing configuration (it opens the editor set on $VISUAL or $EDITOR env)

dave@dafihome:~$ moz_profile.sh -e

Creating scripts

dave@dafihome:~$ moz_profile.sh -c

This script greatly simplifies switching from profiles, obviously occupied disk space grows but after a profile is no more needed you can delete it without risks

The script, that works also on Cygwin, is present on SVN repo at moz_profile.sh

I spend my time to created extensions based on Gecko expecially for

• Firefox, Thunderbird and SeaMonkey (all under Mozilla umbrella)
• Songbird
• Flock
• KomodoEdit/KomodoIDE

Every product has its own developer website where you can upload your extensions (Komodo hasn’t a dedicated upload zone).

From a visitor/user feedback’s point of view Flock is the best.

Flock addons site is cool I love it, extension informations are very complete, you can see also the locales supported by extensions.

Songbird has a cool addons site simple and very quick, extension informations are complete.

Mozilla with AMO is the most important but is also the worst.

The outsider KomodoEdit addons site not yet really exists, registered users can’t upload their extensions.
I hope Komodo guys take a look at Flock addons site if they decide to create a similar place.

From a developer feedback’s point of view Songbird is the best.
After signup you can immediately upload and publish extension on Songbird site, the upload process is easy and publication policy very developer friendly.

AMO upload mechanism is simple but publication mechanism is awful. I don’t like its approval mechanism based on sandbox, my RichFeedButton waits approval for an year.

Flock allows to upload extensions immediately after signup but publication waits approval, after a couple of days I’m yet waiting

The most mature and important addons site AMO, has IMHO the worst user/developer experience.

I don’t like so much Flock but it has a great develope/user website

Recently after a discussion with my friend bard we realized how it is easy to obtain HTML source code associated to the current browser (eg Firefox, Flock) selection.

It’s too simple to discuss the snippet, leave the code speaks itself

function selectionToHTMLSource()  {
    var sel = document.commandDispatcher.focusedWindow.getSelection();
    if (sel.rangeCount < 1) {
        return "";
    }

    var node = sel.getRangeAt(0).cloneContents();
    var xmlStr = new XMLSerializer().serializeToString(node);
    return xmlStr;
}

The code handles single selection, if you need to work with multiple selections like tables rows/cells take a look at Table2Clipboard

An user on AMI tells me that my bonsai RichFeedButton doesn’t work when installed together with another extension.

I install the offended extension and discover that RichFeedButton breaks this little jewel!

The solution was simple but the bug hunting was hard

The problem was into an innocent function associated with a listener that simply checks the nsIDOMEvent’s target id and attrName as shown below
if (event.target.id == "xxx" && event.attrName == "yyy") {
...
}

For some motivations the “event.target” expression breaks the other extension.

I suspect event.target at some event stage isn’t valid and generates internally some error corrupting (???) the full event queue or simply I’m a bad programmer

The solution??

Simply swaps first equality test with second one

if (event.attrName == "yyy" && event.target.id == "xxx") {
...
}

The javascript short-circuit evaluation ensures me event.target.id is parsed only if first condition is true.

Every day I learn something about XUL and its implementation…

Thanks to

Jane Ocean to give me many names to add to this list

marcoos to help me to discover new cool XUL applications

The Mozilla XUL application framework is used to create mainly two types of standalone applications: browsers and email client.

But XUL has all potential to be used to create any complex and cross platform application.

Well, I want to list all applications based on XUL (or XULRunner)

Browsers

absolutely the most significant XUL target

• Firefox – no words… the browser changed internet
• Mozilla Suite – All in one, browser+email+HTML composer
  
• SeaMonkey – The Mozilla Suite successor, I think is better than Firefox but I love bell and whistle
• Flock – A step ahead but actually only a Firefox with some extensions already installed (IMHO)
• Netscape 8.x – No revolution but contains many interesting features, it’s based on Firefox 1.0
• Netscape 9.x – it’s based on Firefox 2.0
• Minimo – Browser for mobile devices
• Camino – Browser for MacOsX It’s based on Mozilla’s Gecko but isn’t a XUL application
• Swiftweasel and Iceweasel – Binary optimized Firefox. Iceweasel is under GNU license
• WebRunner

Email clients

anybody has news about the Eudora porting to XUL??

• Thunderbird – the well known email client

HTML Editors

nothing so innovative but very usable

• NVU – why this cool project has been abandoned????
• kompoZer – the NVU successor

Schedulers, calendars and PIM

I’m waiting to completely remove Outlook

• Sunbird – Cool, easy and enough stable
• Lightning – Ok Ok I know! This isn’t a standalone application but sunbird as extension

Developer tools

• Komodo – Interesting IDE project, cool KomotoEdit full free (added 08 Sep 2007)

Instant Messaging

•  Instantbird

Other categories

Non stricly web-related XUL applications

• Celtx – Celtx is a project collaboration tool for people who work in film, TV, theater and New Media
• Songbird – THE web media player, I really love it but maybe it’s a bit slow and unstable
• eMusic DLM – Download manager
• Etna – XML editor
• Joost - Internet TV viewer and more
• Miro – Video player
• Chatzilla – IRC client
• Second Life client – The well known artificial world (added 28 Jul 2007)
• Evergreen – An enterprise-class Integrated Library System (ILS) (added 23 Sep 2007)

At this time I found only these but my search continue

Do you know other XUL based applications?

The browser flock is developed starting from Mozilla Gecko code but has many specific features.

Together with many cool features the flock team has added many bugs not present in original Gecko code!

The last I found involves the DOMAttrModified event listener.
The code below works on Firefox 1.5, 2.x and 3.x (thunks) but doesn’t work on flock!!!

onLoad : function() {

var feedButton = document.getElementById("feed-button");

if (feedButton) {

// add the listener for feedButton

document.addEventListener("DOMAttrModified", RichFeed.onAttrModified, false);

// triggers a modification only to test the listener

feedButton.setAttribute("feeds", "true");

// onAttrModified should receive the modification but this doesn't occur on Flock

var v = feedButton.getAttribute("feeds");

}

}

onAttrModified : function(event) {

if (event.target.id == "feed-button") {

// never called with Flock browser

}

}

So my decision is to stop the flock support on my bonzai extensions, I have no time to search workarounds to all flock bugs.

Who cares for my decision? Nobody I know