ViewSourceWith, Thunderbird and mail editing

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

Open a tab using FUEL on Firefox 3

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

Houston we have a problem: ViewSourceWith under FF3b5

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“

Central extensions repositories

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

Get HTML code from nsISelection in XUL

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

XBL, CSS selectors priority and Firefox 3

I wrote a little XBL component to allow menuitems to have images centered, I added it to Firefox 2 browser context menu and worked fine immediately, after a while I installed component on Firefox 3 beta 4 and surprisingly the menuitem didn’t show the image

I’ve asked help on Mozilla IRC and after about an hour the mistery was revealed.

The innocent CSS declaration shown below works fine on Firefox 2

.menuitem-image-center {
-moz-binding: url(‘chrome://morekomodo/content/bindings/menu.xml#menuitemImageCenterBinding’);
}

but requires a little modification on Firefox 3 beta 5pre (at this time the latest available)

.menuitem-image-center {
-moz-binding: url(‘chrome://morekomodo/content/bindings/menu.xml#menuitemImageCenterBinding’)
!important;
}

You must notice the selector without !important attribute works on Firefox 3 when applied on menus different from browser context menu.

I suspect the browser context menu should have some special treatment on new Firefox…

Extend Firefox 2 Contest and other surprises

January and February are very important months for my programming activites.

In January ActiveState guys gave me a KomodoIDE license for my contribution to their OpenKomodo wiki, a great unexpected surprise, the first one.

A couple of days ago Mozilla published the Extend Firefox 2 Contest and I discovered my name on “Runners up” list, a great
unexpected surprise, the second one.
I can figure out ViewSourceWith is the winner, no! The winner is Table2Clipboard my outsider extension, a great unexpected surprise, the third one.

I’m happy that other people appreciates my work.

My feed reader alerts me, LifeHacker has new contents, I take a look and found they speak about Table2Clipboard, a great unexpected surprise, the fourth one.

ActivateState gave me a KomodoIDE license, EF2 prices contain a KomodoIDE license, now I have two KomodoIDE license, another surprise the fifth

Mumble mumble… may I sell the unused license?

Richscrollbar released

After ten months I’ve released a new Richscrollbar (RSB) version, starting from FF3 compatibility issues I’ve done some other work.

Finally standard OS themes aren’t offended by old ugly RSB scrollbars, now RSB integrates better with the native OS look&feel.

Now RSB simplifies integration with themes, a model based on supported themes repository allow me to quickly add css styles.

Finally users can decide to remove RSB scrollbars from listbox, tree and so on and have them only on main browser window.

Very strange is the reason RSB doesn’t work on FF3; The nsIStyleSheetService.USER_SHEET must be changed to nsIStyleSheetService.AGENT_SHEET

It’s always present the problem with disabled javascript due to bug 236839 that limits RSB usage for example with Thunderbird or when NoScript is installed

Initially I would make RSB compatible with Seamonkey but the current number of users is so little that this compatibility isn’t necessary

How to detect the current active theme name on Firefox

Sometime obtaining informations about components isn’t so quick, you must iterate over RDF, XML or call many API.

Sometime is very simple like get a pref string… well this time I’m lucky

The pref general.skins.selectedSkin contains the current active theme name.

var currentThemeName = Components.classes['@mozilla.org/preferences-service;1']
.getService()
.QueryInterface(Components.interfaces.nsIPrefBranch)
.getCharPref(”general.skins.selectedSkin”);

Firefox 3 and broken extensions

When I started Richscrollbar (RSB for friends) development I could not figure out a so difficult programming life cycle.

After all its task is simple, add extra buttons to browser scrollbars to speedup movements inside web page.

Gecko is affect by a bug that reduces RSB productivity dramatically but I’ve created it anyway.

Now I discover RSB totally doesn’t work with Firefox 3 beta 2, Mozilla guys changed API and I suspect introduced some regression.

Obviously it is impossibile to explain the problem to Mozilla, they are so busy to fight against the world.

After some frustrating debug I found the problems and fixed them.

Problem nr 1.

The nsIStyleSheetService.USER_AGENT has changed behaviour without documenting it (at least at this date)

I used USER_SHEET in Firefox 2 but under FF3 the same code simply doesn’t work.

I’ve replaced it with the other flag AGENT_SHEET and magically RSB started to work.

Where can I read the new behaviour? Damned Mozilla

Problem nr 2.

An horizontal useless scrollbar is always visible only on tab window open at browser startup, if user opens new tab and/or windows this dumb doesn’t appear, sigh!

I found a reasonable workaround hiding the scrollbar inside the notificationbox component.

I hope to publish the fixed RSB on this weekend.