Hacker News Reader

Comment by simonster | Hacker News Reader

This is really just about writing a browser extension that injects code into a page and does nothing else. Firefox extensions can do all sorts of things (modify the browser UI, call functions in system libraries, create protocol handlers, perform raw IO) that other environments don't permit.

Many of these things probably can't be done through Jetpack/Add-on SDK, but, for better or for worse, Firefox's extension mechanism is vastly more powerful than that of Chrome or Opera.

View on HN

It is true that Firefox's extension mechanism is more powerful than Chrome or Opera. However, some of the things that you list (such as calling functions in system libraries and performing raw IO) can be done in Chrome and I think in Opera by creating an NPAPI extension in C/C++.

Edit: I realize it is harder to write it this way. It is also harder to write Firefox extensions in C/C++ instead of in their JavaScript APIs. The point is that some things not possible in other browsers' JavaScript APIs are possible if you create NPAPI extensions (although some things such as certain UI flexibility are only available in Firefox.)

Edit: You can also register protocol handlers via JavaScript, although they need to start with the string 'web+' which makes this less powerful than what is possible in Firefox.

The NPAPI route is hard, cross-browser and cross platform is harder. For simple, DOM manipulating extensions, this would be so much easy.

You can write NPAPI extensions for Chrome - you might nevertheless not be able to publish them on the Chrome extension directory.

I've been working on extensions for FF and Chrome recently - one of the biggest problems I had and tmk this is still the case (if it has not changed in the last 3 weeks) that it is in the moment extremely complicated to debug FF extension with the latest versions of FF.

Venkman e.a. don't work with these and compiling a 64bit Windows FF debug version (working with the VS debugger) was the only way we found to get towards that. And this for itself is complicated enough (VS2008 SP1) - when you have compiled debug versions of 64bit FF and Chrome you will realize that it is like night and day reg. documentation (up-to-date and consistent), support and effort.

There is a lot the Mozilla guys have to work on in this area (rather sad - if I would have had more time to spend on that I would have certainly contributed something back - maybe later this year).

Note the error in the article: currently (latest FF versions) you can debug Javascript in the browser e.a. but not FF extensions. If you look a bit deeper into the documentation / google it you will find this specifically mentioned. If you want to try it out start Venkman e.a. and try to find your extension code.

NPAPI is difficult. I couldn't find a working sample project(though I only spent a couple hours) last year when I wanted to try it out.

It sounds like Google is working on a new plugin architecture in JS + HTML that will support the deep interactivity of NPAPI, so we'll see...

Google already uses the new Pepper Plugin API[1] in the current versions of Chrome. They've also switched projects like Native Client to use this new API instead of NPAPI. PPAPI definitely seems better based on my experience of writing a few Native Client modules.

[1] - http://code.google.com/p/ppapi/

Wow, good tip, thanks!

You don't need to write Firefox extensions in C/C++ to do raw IO. The same interfaces Firefox uses to implement sockets and streams are accessible by JavaScript. I wrote a web server in ~200 lines of code.

You also don't need to write C/C++ to call functions in system libraries in Firefox. js-ctypes (libffi under the hood) works quite well, although converting headers to js-ctypes function definitions can't be automated IIRC, which makes it a bit of a pain.

Raw power comes with a price: the learning curve for building classic FF addons is steep and confused.

Though many of them can if you use something like this to dig into the browser internals: var {Cc, Ci} = require("chrome");

Then just use "Cc" instead of "Components.classes" and "Ci" instead of "Components.interfaces" for anything that needs them.

For example, the code in the "adding a stylesheet" section of this page ( https://developer.mozilla.org/en/Using_the_Stylesheet_Servic... ) would look like this: var sss = Cc["@mozilla.org/content/style-sheet-service;1"] .getService(Ci.nsIStyleSheetService); var ios = Cc["@mozilla.org/network/io-service;1"] .getService(Ci.nsIIOService); var uri = ios.newURI("chrome://myext/content/myext.css", null, null); sss.loadAndRegisterSheet(uri, sss.USER_SHEET);

(Assuming you actually have a stylesheet registered at "chrome://myext/content/myext.css", you will just have registered it with the stylesheet service, and it will take effect immediately.)

Reply on news.ycombinator.com