This week I’ve received four times the same (i.e. duplicated) ViewSourceWith (VSW) bug report that sounds…

“ViewSourceWith stopped to show the icons on context menu, this regression is present on Karmic Koala (Ubuntu 9.10)”

I use Intrepid Ibex (Ubuntu 8.10) and all works fine, so I’ve burned a Karmic Koala ISO and tested it discovering the “regression” exists.

Debug -> Add logs -> Remove logs -> Clean Profile -> DOM Inspect -> MozRepl without find where the problem occurs.

Last resort -> Bugzilla -> Found!!!

The Bug 527253 unveils the mystery!

This isn’t a regression

ViewSourceWith isn’t the guilty, Firefox isn’t the guilty but… Gnome is the guilty

Type the command shown below from command line and restart Firefox

gconftool-2 --type bool --set /desktop/gnome/interface/menus_have_icons true

EDIT Or use the UI to obtain same result (thanks to mzz) system -> preferences -> appearance -> interface -> show icons in menus

This worked for me and also for two bug submitters (the other two guys do not replayed to my hint)

So remember Bugzilla is your friend

Finally after almost a year I release a new version of Table2Clipboard, one of twelve extensions that won in 2008 the Firefox 2 Contest in the section Runners Up.

What’s new

Until now Table2Clipboard has pasted to clipboard the structure of HTML tables without the styles (colors, borders, fonts) but many users have asked me that the behavior was much more similar to that of Internet Explorer (IE) which indeed maintains many details.

Well, the version 1.0 preserves the styles and in certain cases the result is better than that obtained with IE.

IE inserts also the DOM elements declared “not visible”, for example the table shown in Figure 1  is pasted in Excel as shown in Figure 2.

Figure 1

Table selection on Internet Explorer

Figure 2

Copy from Internet Explorer paste to Microsoft Excel

Table2Clipboard discards hidden DOM elements as shown in Figure 3, this makes more sense for me.

Figure 3

Copy from Firefox with Table2Clipboard paste to Microsoft Excel

Other little improvements

Now web links are copied and user can choose to copy images (tag IMG), too.
All defaults settings can be modified from configuration dialog.

The copy of styles on OpenOffice doesn’t work as well as the one on Microsoft products.
The “Paste Special” feature available on OpenOffice doesn’t recognize CSS styles but only deprecated tags like FONT.

I will add support for OpenOffice soon but I prefer the “release early release often” (after a year??? ) approach so this version has poor styles support on the popular open source office automation suite.

Compatibility issues with Thunderbird 3.x are now fixed.

Table2Clipboard can be installed from AMO or from the project site on dafizilla.

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.

Edited on 9 June 2009 Mozilla guys decided to add a getter for imageURL so no extension will be affected by new property mediaURL replacement, you can read the full story at bug 497098.

Another time Mozilla community demonstrates its strength, why nobody considered the impact before modification is another story

–

Today a ViewSourceWith user filed a bug about a regression on Firefox 3.5b4, causing VSW to no more open images

After dressing the debug uniform I started to investigate the problem.

I’ve realized the object gContextMenu doesn’t more contain the property imageURL used by VSW and maybe many other extensions.

The imageURL property has been renamed/refactored to mediaURL.

Honestly the new name fits better its new usage and maybe the imageURL property is not intended for usage from extensions.

The poor gContextMenu documentation doesn’t describe imageURL so maybe I abused its usage.

I think gContextMenu need a better documentation because its usage is so sexy inside extensions.

The workaround

A string find/replace inside code fixed the bug, to maintain compatibility with FF 3.0.x I’ve modified the code as shown below

var imageURL = gContextMenu.imageURL || gContextMenu.mediaURL;

When Firefox integrated the spelling checker I didn’t immediately realized its value, but using it day after day I became “spell” addicted and now I can’t imagine my browser without this feature.

You can install all dictionaries you need, but many people uses only the dictionary for its own language.

Obviously I’m not a normal person so I use three dictionaries; Italian, English and French switching between them when necessary.

Following Murphy laws every time I start to type inside a input box I discover I’m using the wrong language and I must switch it from context menu, a very annoying practice.

Finally I’ve solved this problem writing the extension SpellBySite.

SpellBySite switches automatically to the correct dictionary looking for it on user settings.

For example user can set English dictionary for mail.google.com, Italian for twitter.com and so on.

When input boxes receive focus the dictionary is set and spell checking executed, no more needs to switching from context menu

Now my life is a bit easier

PS
SpellBySite is waiting on AMO to escape from sandbox

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

ViewSourceWith (VSW for friends) is definitively a browser oriented extension, using it with Thunderbird (TB) produces a very different experience.

VSW under TB allows users to view the mail message text (for example to inspect headers) but it doesn’t support any editing feature.

Under Firefox VSW offers textbox form editing (single and multiple lines) and I use daily the feature to edit GMail message content.

Editing rich textbox like GMail is a great feature, you can edit HTML code not only plain text, this is a great step ahead.

A couple of users asked me to add to VSW the ability to edit Thunderbird messages, not the raw view but a real edit feature in mail composition.

Well, now VSW (from version 0.3) can be used to edit Thunderbird messages, both plain text and HTML messages.

Technically speaking adding TB editing was enough easy using the nsIEditor, the same component used under Firefox with GMail.

I hope to post more details about the nsIEditor usage in VSW

I want to migrate to Firefox 3 and stop compatibility with FF2.x so I’m starting to use intensively FUEL.

Today I’ve replaced the old “open new tab” code shown below

newTab : function (url) {
const newTab = getBrowser().addTab(url);
getBrowser().selectedTab = newTab;
}

With the FUEL version

newTab : function (url) {
var uri = Components.classes["@mozilla.org/network/io-service;1"]
.getService(Components.interfaces.nsIIOService)
.newURI(url, null, null);
Application.activeWindow.open(uri);
}

Onestly I found so complicated the FUEL approach.

Why I need to create an URI?

Why open doesn’t work with a simple string?

BTW FUEL is great

Bad news for ViewSourceWith and its compatibility with FF3.0.

Due to the bug “Code running in context of hiddenDOMWindow runs unprivileged?” ViewSourceWith stopped to work when FF3.0b5 was published.

I’ve done many code modifications to adhere to FF3 requirements and now VSW 0.1b is ready.
After dozen of regression tests I’m afraid something is missed so I ask to VSW users to help me to test it deeper.

Any help is welcomed not only technical tests, for example you can share my help request in other blogs/forums.
If you would help me to test VSW 0.1 download it from here.

Tests can be done on

• Firefox from 2.0 to 3.0b5
• SeaMonkey
• Songbird
• Flock

Tests must verify

• text box editing
• page view source
• css/js view
• error console view source clicking on links
• temp files removal at application exit

Try to

• open more that one browser window closing the openers and verify if VSW continues to work
• use your daily VSW usage behaviour
• use you creativity

Platforms

• Windows
• Linux (I use Ubuntu Feisty)
• MacOSX

Please use this post to give me feedback or better land to “ViewSourceWith Open Discussion“

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