Writing a browser extension for three browsers | Hacker News Reader

Writing a browser extension for three browsers

einaregilsson.com

58 pointseinaregilsson20 comments

In my previous work at a company that made it's money from a browser extension, I saw what hell it was to develop browser extensions for all major browsers.

I should note it looks like this issue is mostly fixed going forward. The chrome extension model won, and Firefox and Windows Edge are supposed to be supporting either directly or through electrolysis.

I.E. was not an extension, but a toolbar, written in C++ (being C++ the debugger was Windows visual studios so it was doable). Firefox was Xul based and almost impossible to debug at the time (much improved in recent months), and chrome just worked.

Yes, I'm hoping to remove the polyfill for Firefox at some point, and add support for Edge when they have extension support. We'll see how closely they stick to the chrome.* apis. Firefox is implementing them but there are always some slight differences, e.g. in Chrome you can redirect in the onBeforeRequest event but you must do it in onBeforeSendHeaders in Firefox. It probably won't be possible to have the exact same code for all browsers without any special cases, but hopefully we can get pretty close :)

That's interesting. I've only made some toy extensions for both Chrome and Firefox, and I've got an impression that Firefox's extension model is somehow more "powerful", and Chrome's is a bit limited. But after reading the experiences shown in this thread, it seems that Firefox's model is actually harder to use in practice. Would this be related to the maxim that "less is better"?

The old Firefox extension model, XUL/XPCOM is definitely a lot more powerful. You can basically access anything and do anything. On the other hand much of it is not documented and you're on your own in figuring out how it works. But they're trying to move people off that model, and onto the Add-on SDK or the chrome model, which is a lot easier to work with, and better documented.

*two browsers

Opera 15+ is merely a fork of Chrome with some slight ui modifications. It does not merit being called a browser in its own right.

Do you mean Chromium instead of Chrome?

Extensions in Opera based on the chromium model, but have a few unique APIs too, like the ones for speed dial and the sidebar, which are not there in chrome.

Should maybe have been 2 and a half browsers. There are some slight differences, e.g. the way options pages are opened from the extension page, but basically Opera is just Chrome. What is the point of Opera, I don't really know why anyone would use it, but it was basically free to make the extension work for it, so I decided to include it.

> What is the point of Opera

Opera up to version 12 was a great standalone browser with UI and performance characteristics still surpassing all competitors even at this point in time. (As long as you exclude JS-heavy things.)

However at some point MBAs managed to take over, decided to continue making most of the company income with their mobile ad network.

Developing Opera 12 further was expensive, so they figured out a way to keep most of the users (for the ad revenue), while radically slashing the dev expenditure on the browser: Fork and rebrand chrome, while adding a few token features, pretend Opera 12 doesn't exist, and push people heavily to "upgrade".

I wrote my first extension for a proof of concept project for Chrome last month, and I literally had my first working example doing something interesting within 2 minutes.

I tried to do the same in FireFox, and gave up. I couldn't get my head around the documentation without taking a day out to get going.

Firefox is also starting its third extension model now. At first it was XUL/XPCOM where extensions could basically hook into ANYTHING in the browser, then there was the Add-on SDK (formerly Jetpack), which is kind of nice, but a lot more limited, and now they're going with WebExtensions, because, well, Firefox basically does nothing but copy Chrome anymore ;)

But yes, that does make it complicated to figure out what's the best way to make stuff for Firefox.

>Firefox basically does nothing but copy Chrome anymore ;)

Thanks

If you can wait for the WebExtension API. If not use Jetpack. Don't write new extensions with XUL/XPCOM.

Sorry, that was unnecessarily snarky. But it does seem like Chrome is leading and Firefox is following on a lot of things. The look, multiprocess, extension model, all things that started in Chrome.

I was pleasantly surprised by Jetpack though, the jpm tool is very nice.

As a primarily Firefox user on Linux I do agree with you about Firefox mostly following Chromium these days. It seemed like for a long time Chromium was adding in features Firefox had with improved implementations, but now Firefox appears to be lagging. The Firefox extension model did allow for extensions like DownThemAll which I don't think can survive in this generation of extension models.

Yes; I have no problem with adding an API to make simple things easy, but TreeStyleTabs, VIMperator, Firebug, all of them need something more powerful than the Chrome model. I really hope they don't deprecate the old model and leave power users out in the cold.

And frankly, the old model is not so bad; if you're building any kind of extension that does more than connecting a button to an HTTP call, the couple of hours you'll need to get started are irrelevant in the long run.

I have written browser extensions in Chrome very successfully. And failed horribly with Firefox.

Now when I see any working extension in Firefox I marvel at how much work that person must have put in to get it to work. Over time hopefully Firefox will get better. But the extensions have been bad for a while...

That's exactly why they want to move to the WebExtensions format.

I've built a Firefox extension (now abandoned), which even used XPCOM, and while the documentation was spotty (this was back in 2010, it may have improved), it wasn't particularly difficult. The fact that you can easily unzip any extension and look at its source makes up for a lot of gaps in the docs.

It’s not mentioned in the article (understandably), but writing an extension for desktop Safari is very similar to writing an extension for Chrome. One can even use the same codebase in most cases — the biggest differences are that Safari is a little more conservative in what it gives extensions access to and any Chrome-specific JS obviously won't work.

But you need a Apple developer license to develop for Safari, and that costs 99$ per year :/

Reply on news.ycombinator.com