Snippets code from my daily experience

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?

Advertisements

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

Create a free website or blog at WordPress.com.