Copy and paste doesn’t really fits my needs, I prefer to edit javascript files from my preferred editor (i.e. KomodoEdit) than run them on Firebug especially if code consists of many lines (more than dozen) so I’ve added to Firebug the ability to open and save files extending ViewSourceWith

Now it’s possible to open/save files directly from Firebug but the most important feature allows to open the file both on your editor and on firebug then any saving done is reloaded automatically.

A better example, you open the file ‘hello.js’ both on your editor and firebug using the new ‘Open’ button, you edit the text from your editor and save then switch to Firebug console window and immediately the text is updated with last saved version from the editor.

VSW with Firebug support isn’t officially released but if you are interested in testing it you can download ViewSourceWith 0.9a1

Production environments require automated tasks to create and maintain update and I’ve always used command line tools to pack XPI files and generate corresponding update.rdf files.

I’ve always used McCoy + Spock on from linux boxes to achieve these results.

A customer asked me to migrate the env from Ubuntu 64bit to OSX Lion so I’ve decided to drop Spock in favor of Uhura that uses only Perl scripts to sign extensions and doesn’t need a McCoy profile.

The problem was to migrate private keys generated with McCoy and use them with Uhura, the binary version (v0.5) available from McCoy web page doesn’t allow to export private keys but the code present on mercurial has this feature

 hg clone http://hg.mozilla.org/projects/mccoy

so I’ve compiled it and exported all my private keys in a couple of minutes.

Ok a couple of minutes plus 6/7 hours to compile McCoy, the Mozilla build process is documented very very well but I’m lazy and stupid so compiling McCoy and Mozilla necessary files required me a bit of time.

If you need to export private keys from McCoy you can download my compiled version for Linux i686 from here, if you need a version for Windows or OSX I’m sorry but you must compile yourself.

I don’t like Apple policies, and I don’t like its “app store” vision, so why I’m writing a Mac app?

In last months I saw Google Chrome be adopted in many places (dropping Firefox), I saw Google Android growing its market share, I saw the “fascist” Apple policy go ahead like a panzer division and this isn’t the web I love.

I don’t like the technically limited Google Chrome browser and I don’t like the “bells and whistles” java based Android OS.

I believe in the Mozilla’s motto “Make the web a better place” but I need to gain from my (low) skill because I’m a person and I need to eat at least one time per day.

I love the Gecko architecture but it’s very difficult (al least for me) monetize my XUL/XPCOM know-how so why not to make a new experience?

I can invest some months to learn Cocoa (its learning curve is high) and create another unuseful duplicated old-designed app ready to be refused-then-hopefully-approved on the future Mac Store.

Firefox 4 is closer to be released (IMHO), the beta 8 is simply fantastic but people continue to switch to Chrome only because it’s faster, if you ask to normal users why they use Chrome they will say “because it’s faster”, bleah NO COMMENT.

Developers say “Webkit Developers Tools is like Firebug” then I reply “are you sure?”, Firebug has tons of features you don’t know, RTFM!

I’ve a couple of feature requests for ViewSourceWith and Table2Clipboard so I hope to close XCode ugly editor to launch my Komodo Edit and start again to work on my preferred platform, the Mozilla platform!

1. Create an XPI file with all files unzipped (no jar file inside)
2. Install the XPI on a separated (and clean) profile, this is applicable to any Gecko application: Firefox, Thunderbird, Komodo, SeaMonkey 2.x
3. Run unit tests or use the extension
4. If some test fails I edit code (xul, js, css) directly on installed files
5. Move edited files on main code build tree
6. Repeat the process starting from 1.

Any developer uses its own approach, someone prefers to edit the chrome.manifest to point to files on specific directories, someone uses other enterprise-big-team oriented ways.

No matters the approach you use under Gecko 2.0 (ie Firefox 4.0) the XPI file will not unpacked by default, this can complicate your development process but the solution is easy.

em:unpack

Add to your install.rdf the following line and everything comes back (more details here)

<em:unpack>true</em:unpack>

My dev environment has two XPI creation tasks, debug and dist so it’s easy to insert <em:unpack/> only when necessary (debug mode in my case)

RTFM

Please visit often Firefox 4 for developers (better to follow the feed) because FF4 is a little/big awesome revolution and extensions can be affected in many ways.

So adding locales is technically trivial but having locales updated can have a dramatic impact on release process.

Everything is based on voluntary contribution and this is simply awesome but very often localizers stop translation without tell anything, other translators can’t respect deadlines, this is voluntary activity so if they can’t do it means simply they can’t do!

I’m very sad but I’ve decided to drop localizations inclusion from my extensions I leave only my mother tongue and obviously English.

Epic fails

A short list of attempts I’ve done to obtain completed locales but without success

• Contacting localizers asking to complete localization without receiving reply (bad citizens???)
• Searching other people to continue translations
• Asking translations for less than ten strings per release (including accesskeys and key)
• Setting long deadlines (two/three weeks) discarding periods closer to holidays (summer/winter)

Technical workarounds

I know there are many ways to have an incomplete locale using en-US for missing strings, (read Firebug lesson) but I really dislike mixed locales and I’m a zero-or-one man so complete locales go inside XPI, incomplete locales not bundled!

I surrender

So finally I’ve decided to stop locales inclusion, I will continue to write code compliant with locale rules (eg no hard coded strings) because it’s easy and really useful.

Yesterday I’ve discovered that Firefox 4.0b2 is shipped with a revisited nsIProcess implementation containing two new awesome scriptable methods: runw() and runwAsync() (the ‘w’ stays for wide string).

These methods have identical run() and runAsync() signatures but they accept UTF-16 strings as arguments.

I’ve modified my extension to call runw() instead of run() and everything worked like a charm, also the process name (ie the program to launch) can contain Unicode characters, this is a rare case but run() never worked with similar insane scenarios (IWinProcess supports Unicode also on program name).

New methods are very welcomed considering IWinProcess needs to be modified to work with the new XPCOM Registration mechanism and I’ve not enough energies/time/skill to make it compatible with Gecko 2.x.

IWinProcess can be dropped in flavor of native runw()/runwAsync() but to be sure I prefer to wait news from Gecko team and I hope to see soon the nsIProcess page on MDN documenting these new methods.

The same happens with Google Chrome, people asks to migrate extensions to their new favorites browsers but this is in many cases very difficult or impossible.

Giorgio was very clear on his post “Before you ask… (No NoScript on Safari)” and NoScript is infinitely more important and popular than my bonsai extensions.

Now I want to summarize what it is possible to do on Chrome and Safari and what isn’t possible to do from an extension developer point of view.

Keep in mind that from an extension developer perspective Firefox is a platform, Safari and Chrome are applications with minimal support for pluggable code.

Minimal support doesn’t mean you can’t create great extensions but it means you are very limited in advanced topics like web page listeners, clipboard, file and network system access and many other programming areas.

Jetpack from my point of view is closer to Mozilla Platform than WebKit/Chrome extensions framework so for simplicity when I speak about Firefox I include Jetpack (please apologize me for this simplistic and superficial classification)

Below you find a table with extensions capabilities supported by browsers at time I wrote this post.

It comes from my needs to implements extensions on Chrome and Safari, it is incomplete and anybody is welcomed to help me to complete or correct it.

Safari is less extensible than Chrome

Safari extension API set at this time is very limited also when compared with Chrome, as mentioned above this doesn’t mean all extensions are toys but the user experience can be limited and the developer creativity is seriously damaged.

Treat extensions developers as first class developers

I think extension developers must be able to do same things the application developers can do, obviously security constraints are welcomed but please don’t kill developer freedom in name of an opaque concept of security.

Is the browser less or more secure without AdBlockPlus or NoScript?

JetColorTab, the 50 Line code contest’s winner born to solve a need without installing full features extensions.

In these days the Mozilla community (and me) has debated about the future of Jetpack and XUL and many people says “a big number of extensions can be written simply using standard DOM and HTML”

This sentence intrigued me so I’ve tried to rewrite Table2Clipboard (T2C) for Jetpack, T2C makes a simple operation, it copies HTML selection also DOMRange to clipboard preserving the format and many other aspects.

After 30 minutes the porting was completed (excluding the UI not yet rewritten) so heavily DOM oriented extensions can be easily ported to Jetpack but some XUL code remains.

Extensions like NoScript or AdBlockPlus today are very hard (impossible??) to move to Jetpack and hopefully this is not necessary because XUL sits near to us for a long time

Little fixes to T2C required

• Jetpack version 0.6.2 doesn’t allow (or at least I’m not able) to use modules so while waiting for CommonJS comes to Jetpack it is necessary to copy all scripts into the main jetpack file
• HTMLTableElement, HTMLTableCellElement, HTMLTableRowElement are not “visible” so expressions like

  if (a instanceof HTMLTableElement) {}
  

  don’t work but this isn’t a problem because the code can be written more efficiently

  if (a.localName == "TABLE") {}
  

• gContextMenu.target can be replaced by the standard Jetpack context.node, the parameter context is passed for example to beforeShow()

Where XUL is necessary and improvements required

• Jetpack allows to obtain the text or HTML selection using jetpack.selection but it doesn’t expose the focusNode so I used jetpack.tabs.focused.contentWindow.getSelection() (i.e. XUL nsISelection)
• XUL clipboard supports flavors but under Jetpack you can set only one at time, so you can’t add text version plus html version of same content, I think the ‘set’ method should have an ‘add’ mate
• T2C needs to access to CSS using ownerDocument.defaultView.getComputedStyle
• T2C uses the inIDOMUtils, it should be great if this interface become available from Jetpack

Jetpack Table2Clipboard can be downloaded from the Jetpack Gallery

I have only a few questions in my mind and my stupid answers.

Q: Is it really so difficult to write XUL extensions?

A: For me no and I’m not a so clever person! OK there is a learning curve but every complete (non strictly complex) system requires to study, to learn and to compare itself with other people. Please don’t  confuse “rich” with “complicated“.

Q: We really need new addons ecosystem?

A: Maybe we need a lightweight ecosystem but XUL is the right way, Jetpack sounds good but today it is strongly tied to the browser, this will change when Jetpack for Thunderbird will be published.

I love Jetpack believe me

Jetpack suffers from its so called “JQuery oriented syntax”.

I don’t like the sentence “JQuery oriented syntax” simply because doesn’t exists a “JQuery syntax”. JQuery uses Javascript closure syntax construct, I admit sometime it is very ugly and code tends to became naturally obfuscated

Are we sure “JQuery oriented syntax” is really so simple for newbies?

I agree with Daniel Gazman blog post, solution can be worst than the problem.

Q: Is restarting the browser after an addon installation so terrible?

A: I want my Operating System doesn’t require to me to restart after an update but I don’t care if my browser must be restarted after an addon installation/update. People are so lazy, people are so stupid? They accept OS reboots but suffer browser restarts? This is really a strange world!

Q: Is the problem related to Google Chrome success?

A: I don’t like so much Google Chrome, ok its startup time is amazing, then? What other feature is so fantastic? I’m a programmer and maybe I don’t see “commercial” related problem.

Maybe someone forgets that “Firefox is a platform”, Firefox isn’t a simple browser.

You can reuse your XUL platform know-how to create extensions for other applications; Thunderbird, Komodo, Songbird, Prism (my favorites four XUL applications)

You can create standalone applications using the XUL platform, too.

You can use extensions also on your mobile phone thanks to Fennec.

Please apologize me for my bad English and my rant

Changing styles for XUL trees requires the implementation of a nsITreeView, some nsIAtomService manipulation and some Mozilla CSS Extensions, definitively a bit verbose but enough simple after a dozen of attempts :P.

The Mozilla CSS tree extensions are mainly pseudo-classes that can’t be modified from code, so you need to create a CSS text snippet with new values and then “reload” it.

Reloading CSS files can be accomplished using the nsIStyleSheetService service, it only requires a nsIURI pointing to the CSS resource.

Based on the scenario described above the styles are generated at runtime so I need to create a CSS style representation and stores it for example on a temp file. The styles don’t really need to be persisted on disk so why do I need to create an unuseful file?

Well using the “data:” protocol it is possible to encode the generated CSS string and pass to nsIURI the data uri without needs to create temporary files as shown below.

function applyUserStyles(cssStyles) {
    // myTreeChildren is the CSS class name used for the tree
    // obviously can be parametrized
    var css = '.myTreeChildren::-moz-tree-cell-text {' + cssStyles + '}';
    var data = 'data:text/css;charset=utf-8,' + encodeURI(css);
    var sss = Components.classes["@mozilla.org/content/style-sheet-service;1"]
                .getService(Components.interfaces.nsIStyleSheetService);
    var ios = Components.classes["@mozilla.org/network/io-service;1"]
                .getService(Components.interfaces.nsIIOService);
    var u = ios.newURI(data, null, null);
    if (sss.sheetRegistered(u, sss.USER_SHEET)) {
        sss.unregisterSheet(u, sss.USER_SHEET);
    }
    sss.loadAndRegisterSheet(u, sss.USER_SHEET);
}
 

Maybe a simpler solution exists and my code is the worst way to proceed, if you know a better way please tell me