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.
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.
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.
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...
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.)
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.
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.
The only downside is that for IE build support you have to buy a commercial license which isn't cheap ($2500).
