Snippets code from my daily experience

December 10, 2011

Open and save Firebug command line text with ViewSourceWith

Filed under: firebug,viewsourcewith — dafi @ 11:11 am

I spend much time using the Firebug command line set in multiple lines view, I edit javascript code or run little not automated tests copying and pasting code to the Firebug command line window.

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

September 19, 2011

Signing extensions, McCoy, Spock, Uhura and private keys

Filed under: Uncategorized — dafi @ 6:15 pm

I’ve written many extensions in these years and not all are present on AMO, many extensions are hosted on customers servers and are updated using signed update.rdf files.

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.


	

November 30, 2010

Off topic post about XUL, Apple, Google and Open Source

Filed under: Uncategorized — dafi @ 8:41 am

I don’t write about XUL since a long time, this is due to the fact I’m spending all my free time writing a Cocoa application for Mac (no iPhone).

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!

September 26, 2010

Firefox 4, packed XPI files and extensions test environments

Filed under: extension,firefox,gecko — dafi @ 8:50 am

My test environment is simple

  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.

August 29, 2010

Sunday thought: Discarding localizations from extensions

Filed under: extension,localization,sunday_thought — dafi @ 11:30 am

XUL is so flexible that creating localized extensions is incredible easy, adding new languages is simple and the developer effort is very low.

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.

July 24, 2010

nsIProcess now works with Unicode

Filed under: nsIProcess,unicode — dafi @ 5:55 pm

In the past I’ve spoken about my problems passing Unicode arguments to nsIProcess.run(), due to these problems I’ve created the IWinProcess component.

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.

June 10, 2010

A survey on Safari 5, Chrome and Firefox extensions API

Filed under: chrome,firefox,jetpack,safari — dafi @ 2:28 pm

A couple of hours after Safari 5 publication I’ve received an email asking me to port Table2Clipboard to Safari, after two days I’ve received five emails asking to port on Safari both Table2Clipboard and ViewSourceWith.

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.

Content DOM Modification (eg injection) Firefox Yes
Chrome Yes
Safari Yes
Accessing to web pages to modify or simply traverse the DOM is the main browser activity and it is fully accessible from extensions
Chrome and Safari introduce the concept of JS (and CSS) injection to separate access to content DOM from extension DOM, Firefox is like the wild fast west you can do (almost) anything
Tabs and Windows Access Firefox Yes
Chrome Yes
Safari Yes
Enumerating, inserting and closing windows and tabs are common tasks, both Safari 5 and Chrome have very well designed APIs.
Firefox API is too low level (XPCOM from JS) but luckily FUEL simplifies all these operations, Jetpack has a very handy API.
On Safari I was unable to find APIs to listen tabs creation and destruction, Chrome has very well documented APIs to do that.
Tabs Customization Firefox Yes
Chrome No
Safari No
The UI widget tab is available only on Firefox thanks to XUL. If you want to colorize tabs or add operations to context menu you simply can’t on Chrome and Safari, this is by design.
This is a very advanced topic and extensions can live without this feature but new UI ideas must repose in peace for ever.
Browser UI Widgets Customization Firefox Yes
Chrome Partial by design
Safari Partial by design
Firefox has no constraints, Chrome allows to add icons on address bar (page actions), Chrome and Safari allow to add toolbar buttons, Safari allows to add context menu items, too.
At this time the context menu is accessible from APIs in Chrome only from an experimental API
Clipboard Support Firefox Yes
Chrome Partial
Safari No
Is clipboard support an advanced topic? I’m not sure.
Chrome clipboard support is strange, it only allows to copy full tab content and text selection, the text selection can be copied using the trick document.doCommand(‘copy’) so not a real API exists.Developers can’t copy their own strings but only content already present on web pages.

Firefox allows to copy strings from code and the advanced usage permits to choose the flavors, for example plain text and HTML code.

Table2Clipboard is easy to port on other browsers (95% is DOM content code) but how can I copy to clipboard my own generated strings? Sadly I can’t

File System Access Firefox Yes
Chrome No
Safari No
For security reasons Chrome doesn’t allow to open local files (at least from simple APIs), this sounds reasonable but can be very limiting for advanced usage. Chrome (and maybe Safari) can communicate with the file system writing NSAPI Plugins this is more complicated than using a native Javascript API but it sounds consistent with security constraints.

I consider ridiculous that Chrome doesn’t allow to access to file:// pages from extensions

Run OS local applications Firefox Yes
Chrome No
Safari No
Running local applications from extensions follows the same rules of ‘File System Access’ and same solutions (ie NSAPI Plugins)
HTTP low level Access Firefox Yes
Chrome No
Safari No
I think this lack on Chrome/Safari makes almost impossible to implement efficients web pages inspections as done by NoScript
XMLHttpRequest and Cross-domain Firefox Yes
Chrome Yes
Safari Yes
Any modern web application uses XMLHttpRequest but with Cross-domain Restrictions, from extensions all browsers allow to make Cross-domain calls

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?

January 12, 2010

Porting Table2Clipboard to Jetpack

Filed under: jetpack,table2clipboard — dafi @ 7:54 pm

I’ve written many Jepacks to solve little annoying problems mainly related to urls and tabs.

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

January 10, 2010

Sunday thought: Please don’t kill XUL

Filed under: sunday_thought,xul — dafi @ 3:33 pm

After reading the Mike Connor’s blog post and the Firebug’s post blog I realized XUL developers are closer to a revolution.

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

January 8, 2010

How to programmatically change XUL tree’s pseudo-classes

Filed under: extension,nsITreeView,xul — dafi @ 3:45 pm

I encountered the following problem: Change font and color for XUL tree based on user input. The user chooses the font and picks the color from a dialog and the tree widget is immediately redrawn with the new styles.

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 :)

Next Page »

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.