Writing Browser Extensions - Comparing Firefox, Chrome and Opera(blog.nparashuram.com)
blog.nparashuram.com
Writing Browser Extensions - Comparing Firefox, Chrome and Opera
http://blog.nparashuram.com/2011/10/writing-browser-extensions-comparing.html?hn
32 comments
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.
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.
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.
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 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.
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.
The NPAPI route is hard, cross-browser and cross platform is harder. For simple, DOM manipulating extensions, this would be so much easy.
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...
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/
[1] - http://code.google.com/p/ppapi/
Wow, good tip, thanks!
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.)
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 know this is off-topic but I need to rant against Google/Blogger's mobile version of their platform since I keep running into it whenever I'm browsing HN on my iPhone.
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.
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.
Google added the same "feature" to the mobile Reader app and it caused the same problem. It happened to me every time I used it. Solution? I stopped using Reader. Well done, Google.
Every attempt I've seen to turn something into a special mobile version has failed horribly. Google Images is absolute, pure shit, I literally get up and find my laptop when I have to use Images because they've made it so horrible to use. And of course OnSwipe lol.
I don't want an "ipad" experience, I just want the website.
I don't want an "ipad" experience, I just want the website.
If you have a moment, I'd love to know what you dislike about Google Images for iPad. I worked on the product when I was an intern at Google. I'm sorry it's causing you frustration :(
#1 hate is I can't open images or pages in new tabs, if I tap and hold on the outer thumb I just get the option to save that thumb, if I tap and hold on the link in the preview I get nothing at all. That makes browsing multiple images painful.
#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.
#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.
Thanks for the feedback! Both of your grievances are legitimate issues. The reason why we didn't support those use cases on iPad is because they are power user features.
Pro tip: If you scroll to the bottom of the page, you can view the desktop site by hitting "Classic". Happy Googling :)
Pro tip: If you scroll to the bottom of the page, you can view the desktop site by hitting "Classic". Happy Googling :)
When I scroll to the bottom of the page on my iPad, Google _conveniently_ loads more images. It's like a cruel joke.
On my Android 2.3 phone with stock browser, when I tap an image, the image _below_ it gets highlighted, even though the correct image is opened - horribly confusing.
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.
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.
Same problem, there must be something weird with the way I scroll because I keep changing article when I'm just scrolling up and down.
If you want to create a cross-browser extension, you can use an API such as Kynetx, Webmynd, CrossRider, or KangoExtensions. Links and pros/cons can be found here: http://stackoverflow.com/questions/4913123/cross-browser-ext...
I've been building an extension with Kango and so far everything has worked as advertised. The build process is a snap. Everything is written in Javascript; I have complete access to the DOM via Jquery. Builds for FF, Chrome and Opera. And their support has been quite responsive.
The only downside is that for IE build support you have to buy a commercial license which isn't cheap ($2500).
The only downside is that for IE build support you have to buy a commercial license which isn't cheap ($2500).
Last time I looked it was a maze trying to figure out FF extensions. A painful long learning curve. I wrote my first chrome/safari extension about 5 mins after I read the intro.
Firefox Add-ons PM here. I completely agree. I'm a developer, however I had to have someone from the SDK team show me how to get started since it was so hard to find proper documentation.
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.
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.
start with the documentation on creating a FF debug version e.g. on Windows 64bit - it does not even work with the config files from the trunk - leaving alone the different flavors of documentation you find on Mozilla dev - have a look how Google has done this - and yes you have to describe how to setup the environment for e.g. VS2008 SP1 (again have a look at how Google has documented it)
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.
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.
Firefox's Jetpack extension API (using JavaScript) is very similar to the commonly used Chrome/Safari ones. You were likely looking at documentation for their C++ extension API.
I completely agree. I recently released my first Chrome extension and I found the documentation and guides to be clear and concise. I'm now looking into creating a Firefox extension and the learning curve has been very painful. I spent an hour or so just going through the Firefox docs and I'm still unsure how to start building an extension.
figuring out how to sign a FF extension properly without an https cert was one of the most difficult things i've accomplished in my programming career. :(
Speaking of Opera, there's a labs release out that supports extensions on Opera Mobile: http://dev.opera.com/articles/view/extensions-opera-mobile-l...
Chrome, Opera and Safari have a very similar extension architecture. If very easy to port on extension to the other 2 borwsers, as long as:
* the API is there. For example only chrome can block HTTP requests, and access headers.
* The UI element is there. Safari has no page action, for example
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.