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.
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).
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.
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...
 - http://code.google.com/p/ppapi/
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"]
var ios = Cc["@mozilla.org/network/io-service;1"]
var uri = ios.newURI("chrome://myext/content/myext.css", null, null);
(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.)
When I view this article on an iPhone 4S, Blogger adds in a swipe feature that goes to the next article (or previous article if you swipe left).
This "feature" is driving me nuts because there are tables that break the screen on the iPhone where I cannot move around to view it because Blogger automatically assumes I want to read the next article.
If someone from Google is reading this, or even better Blogger. Please take this feature out. It is a really annoying experience.
I don't want an "ipad" experience, I just want the website.
#2 is to view the meta data that's "free" on normal GI you have to click through to the preview and start downloading it and other images at a larger size. Images has lots of shitty, spammy websites gaming the results as well as poor versions of images available elsewhere larger, seeing that info was always useful to me.
Pro tip: If you scroll to the bottom of the page, you can view the desktop site by hitting "Classic". Happy Googling :)
Also when an image is being viewed, you can't swipe to go to the previous/next image. I believe this works on the iPhone.
The only downside is that for IE build support you have to buy a commercial license which isn't cheap ($2500).
I'm currently working on completely redoing the Developer Hub to make it dead simple. Shoot me an email (gkoberger at mozilla dot com) if you have any suggestions or things that were particularly painful.
Grrrrrrrrrrrrrrrrrrrr - I'm still furious if I remember the days and nights wasted with false or outdated documentation.
At the end we skipped using FF (our original favorite) for these internal tasks and went along with Chrome - sadly to say so but this is currently broken with FF and great if that changes.