Writing Extensions for Firefox Is Barely Worth the Trouble
omniref.com
omniref.com
AFAIK Chrome extensions don't go through a review process. That's why I know of two Chrome extensions that were spying on their users and submitted the visited urls to third party servers (Smooth Gestures and a Diigo extension having something to do with screenshots).
So while it's important to be able to iterate quickly, I don't think the Chrome team have made the best choice. The damn spying by extensions is the primary reason I recommend Firefox instead of Chrome to anyone who asks.
EDIT: I just asked on #mozilla IRC and was told that https://lists.mozilla.org/listinfo/dev-extensions would be one way to send that feedback.
Firebug could be built for Firefox (however hard and painful that was). You can't build anything similar for Chrome.
Just because some extensions are bad, don't make everyone suffer and provide a bad experience. Maybe provide a proper review system where people can downvote and moderators can ban such extensions. They are so many choices available instead of a highly dramatized review process.
Like I said, there are many options here. Approval process should just do some automated scans but that's about it.
Such a sandbox can't be done for this use case. How would the sandbox know what is legitimate traffic for that extension and what is traffic related to spying?
By not having a review process a few don't suffer (the extension developers) and many (the users) suffer, because they can't trust their browser.
I'm firmly in the "I want to be able to trust my browser" camp but perhaps a balance can be found where the benefit of the many can be only slightly reduced while the pain of the few can be greatly reduced. Here's to that!
The users will also suffer if there are less extensions available because most developers of $small_hobby_project don't want to go through an approval process every time they try to update their extension (and you would need to check every update, or the whole ordeal is pointless).
They'll especially suffer if, typical for Google, the extension review team is horrible and understaffed. Google can't even get paid support right, what makes you think they'd be quick and orderly about approving free browser extensions.
A couple of months ago I noticed that the Unfriend Notify for Facebook extension (https://chrome.google.com/webstore/detail/unfriend-notify-fo...) with 200,000 users is doing the same thing (a good clue is that it asks for access to all sites but doesn't do anything useful outside of facebook.com).
I wrote a note via the webstore's "Report Abuse" that I am pretty sure referenced the bad code but the extension is still in the store.
Shady shit right there.
The documentation is a mess. Right now there exist 3 different ways of developing your extensions. Even if you decide you are going to use the official Addon SDK it is not clear if you should be using the CFX tool like described in their main repository[1] or JPM[2] which according to this blog post[3] is now the official tool. If you decide to go with the new tool you will find out that there is no documentation how the import system works, except another blog post[4] that just says they are now using npm. Good luck with figuring out all the details.
But I think the main problem with Firefox is that once the Addon is inside the browser there is no sandboxing. The Addon has the same privileges as the Firefox process, including the potential to modify other Addons at runtime. That's why the review process is taking such a long time, they basically need to hand check all of your source code to catch if you are doing something nasty. If you don't ask in Chrome for some permission you will just not have access to this API, but not in Firefox. No permissions, always full access. This is an enormous security risk, because it is impossible to check all corner cases of big Addons and be sure that the Addon will not get code from outside and just eval it.
[1] https://github.com/mozilla/addon-sdk [2] https://github.com/mozilla/jpm [3] https://blog.mozilla.org/addons/2014/08/19/announcing-add-on... [4] http://work.erikvold.com/jetpack/2014/08/07/cfx-to-jpm.html
Your criticism in regards to tooling is valid, but it ignores a bigger picture. Two of the the three different ways of writing add-ons have existed long before chrome was even announced and made great add-ons like firebug possible. The fact that there is already a three different ways to write firefox add-ons is outcome of constant improvement of the firefox add-on platform. While this makes things little confusing for newcomers, it still necessary to keep old add-on systems in place, as this keeps people's add-on's alive and subsequently make users using those add-on happy.
You also misreading blog posts about JPM, as it is not a new official tool yet, but we are working hard to get there. As of reason why, add-on SDK was designed with commonjs modules in mind as we saw it becoming de facto standard. Back then node was not announced yet, needles to mention npm and tons of packages published to it. There for toolchain named CFX was written in python. Now that node became a standard tool in the JS toolchain and npm is where js libraries get published we are working to refresh our toolchain and embrace all this, subsequently making thousands of packages available in npm available to an add-on authors.
A "little confusing" is way off the mark here. If it weren't for Google Search working its magic, it would be practically insurmountable.
> it still necessary to keep old add-on systems in place,
I don't think anyone is asking to scrape the old APIs. Just clearly mark the APIs as depracated and link to the new corresponding bits of documentation .. that is after writing them first.
As it stands, writing a Firefox extension is somewhat of an arcane art currently.
If you think debugging your extension is hard, imagine debugging Firebug. We built our own tracing/logging extension a long time ago to help, and I think it predates Chromebug. But it is not the same.
Fact is, Mozilla extensions are going to have some issues when e10s ships in final form. It can give then the opportunity to redo things. I'm not a fan of JetPack, btw, as I think python is a requirement. And not the version I have on my machine. Talk about a non-starter.
At least the built in tools are finally getting to a useable state. They are made for e10s. They have some nice features. I haven't noticed them breaking sites that you debug by being them being turned on (my fault for waiting so long to file a bug). They have some great UI choices (yet some bad ones). Overall, they are shaping up.
BTW, the debugging of extensions only works for some extensions. Sadly not mine. :/
All of the problems detailed in this blog are true. But I feel like the author missed one thing that bugs me. Whenever you install a Firefox addon, you might notice that little text saying "author not verified". Why is that? Because the verification process for authorship is above and beyond the normal extension process and insane.
Author signing process: https://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html
Automatic Firefox extension updates (without Moz store): http://www.borngeek.com/firefox/automatic-firefox-extension-...
I can see problems with peoples systems being hacked and made to sign stuff, but surely having the signing system in the first place leads to enough gains overall - provided it can be made simple, clear and useful for the common user.
/uninformed rant
Firefox has an Addon Debugger.
Also https://addons.mozilla.org (AMO) has much more accountable guidelines than https://chrome.google.com/webstore/ (cws).
cws has a lot of issues with lengthy reviews as well https://groups.google.com/a/chromium.org/forum/#!searchin/ch...
Over at AMO you can monitor the review queue position of your addon, and there is even IRC channels #amo-editors and #amo to talk to.
Review mails have specific feedback about issues they find.
Google extension reviews, bug reports (e.g. Chrome or Android bugs[1]), googlecode site support[2], are an ever growing super massive black hole.
[1] e.g. https://code.google.com/p/android/issues/list?can=2&q=blueto... [2] https://code.google.com/p/support/issues/list
I don't know what environment you live in, but despite the at least 2/3rd adoption rate of Chrome (note, not Chromium but really Google Chrome) over Firefox there is no hate here at all. It's a choice depending on personal preference, and in my case also for FOSS. It's not like Firefox has already lost, which is how you put it.
In fact I've used Chrome for months when I disagreed with Firefox 4's design. In the end I couldn't stand the way Chrome worked and reverted. Besides FOSS, it really is a preference.
I might agree on the topic of making add-ons, though the last time I looked into that (and quickly gave up) for any browser I was maybe 16, which is now 5 years ago. Userscripts is the way I and everyone I know takes, and there Firefox is better than Chrome as far as I know (Chrome requires some tricks because it only accepts scripts from the store these days).
I don't know what's better about them, but yeah I too noticed the crashes.
The only annoyance I have with the developer console is something they only recently added: you now need to right click in the console and tick "Log request and response bodies" every single time. No about:config option. But aside from that, I never noticed much difference. There are some things I like in Firefox that I missed in Chrome but that's probably because I'm used to Firefox. When I went the other way around, going from Chrome to Firefox after a few months of Chrome usage, Firefox had actually caught up and I didn't need Firebug anymore at all. Never noticed anything missing.
Yes, seems like there could be a pref for that. Filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1064458.
But that all being said, if ANY developer addon lets me manually edit cookies then I will happily use it. Right now they all only let you delete, not alter, cookies. So it is hard[er] to test your site's security against malformed or malicious cookie issues.
> Firefox's developer tools are terrible even compared to Internet Explorer 10/11
Wow what, care to elaborate? I've attempted to use them once and couldn't do the most basic of tasks, went straight to getfirefox.com. Not sure what I tried to do, probably something network related or maybe css modifying.
I find Firefox less resource-hungry and with the WebIDE and Code Snippets that don't need to import/export to devtools source snippets it might even be ahead of Chrome.
Not always. As a developer I use the latest stable Firefox, since that's what I can recommend to my users.
Eh? Tampermonkey makes it dead easy to write and run userscripts in Chrome. I've already written them for half a dozen sites I go to that could use a little tweaking.
Chrome is only closed source in the sense that Mozilla's Firefox builds are closed source. It doesn't have any features that are unavailable in Chromium. It ships with proprietary Pepper Flash and EME plugins, but both work fine in Chromium too.
Even the much maligned RLZ tracking used by third party Chrome installs to report the installation referrer to Google is an open-source feature (disabled by default in Chromium and the first party Google Chrome builds)
To get a restartless "Hello World" Thunderbird add-on running I had to bang my head against a wall for a solid week. It was not pleasant, to say the least. In the end the code itself wasn't bad (especially after I decided to just use Browserify and bypass their require() mechanisms completely), but finding the right incantations was horrific.
The debugger situation was very bad, but looked like it was improving a little. I was able to get my Firefox beta to connect to my Thunderbird beta and remote debug. Except that it couldn't reliable set breakpoints, or step in and out of privileged code. And my console.log() message only went to the global debug console. Oh, and I had to write console.log()—extensions don't get that by default.
Sadly in the end I discovered that the part I wanted to override was deep in the bowels of the C++ code, making it more or less impossible. It's an XPCOM component, so there's a small chance I could make a replacement component in Javascript and forward all but the functions I want to override through to the real one, but I got overwhelmed and stopped working on the project. :-(
but seriously, "19 years old Mutt" rings hollow. Linux is 23 years old, BSDs are older still, etc etc. software age in itself means little.
Edit: "Mutt 1.5.23 was released on March 12, 2014." not sure how the 1.5.20 thing sneaked in.
This is just one manifestation of that, and the resulting misallocation of resources. Firefox used to succeed by being better, not by having an ideology. That at one point it had both is a happy accident.
But the original article doesn't just point to a problem with Firefox for developers, but also a problem that makes it hard for developers to create extensions, which can mean a worse experience for Firefox users.
Mozilla's ideology does have the the potential to be focused on user value. Mozilla is, according to its formal and written mission, dedicated to the "open web" (https://www.mozilla.org/en-US/mission/), not to all Good Things. And Mozilla has succeeded in ways because it has consistently held faith in the web, when others have not. Microsoft gave up on browsers and Mozilla didn't, which was Firefox's first big win. Google gets distracted by Dart and (P)NaCL, while Mozilla sticks with Javascript and creates something like ASM.js. Or compare Android and iOS to Firefox OS – Mozilla is really sticking its neck out to support the open web in this case. Firefox OS isn't about social justice, that is a product being created to defend an ideology focused on the open web, and it's a huge allocation of resources by Mozilla.
Extensions actually fit in kind of poorly here, which is perhaps why things are rough. Extensions aren't the open web, and while there's value in Extensions for Firefox-the-product it doesn't have good mission alignment.
All that said, I'd agree that Mozilla, like many mission-led organizations, has a real challenge distinguishing its aspirations from the work that really defines its contribution to the world.
1) You're absolutely right that writing extensions for Firefox is harder than writing extensions for Chrome. But that's in no small part because Firefox has been around for something like twice as long as Chrome has; and really, Firefox's add-on infrastructure goes back even further, all the way back to the original Mozilla suite. Which means Firefox is carting around something like 15+ years' worth of legacy infrastructure with it. There are lots of bits of technology that Made Sense At The Time™ (XUL and RDF manifests, for instance) that just seem needlessly baroque today.
It's possible to imagine them ripping all that out and starting from a clean sheet of paper, but that wouldn't necessarily be an unalloyed good for developers. After all, backwards compatibility is a Good Thing for developers too; just for developers who have already gotten into the platform, rather than those seeking to get in now.
Rather than have a Great Break and throw out all those years' worth of extension developers' work, Mozilla has instead been making incremental improvements to extension development -- creating things like bootstrapped extensions (https://developer.mozilla.org/en-US/Add-ons/Bootstrapped_ext...) and reducing the dependency on things like RDF that nobody wants to work with anymore. This is a pragmatic approach, but it will require a very long time for it to get Firefox to a place where it can compete directly with Chrome on this front.
Which leads me to point 2...
2) Imagine that Firefox didn't have to worry about all that legacy support, and really could start from a clean sheet of paper.
Would it be worth it?
My personal sense is that browser extensions in general are a technology that's on the far side of the adoption bell curve. As the Web itself becomes a more capable platform, many scenarios that used to require an extension can now be handled quite well by sites on their own. And anecdotally, I see a lot less interest in extensions among the "normal users" I interact with these days than I did, say, 10 years ago.
So, if you're Mozilla, maybe you could make extension development cleaner, but it's just not worth the effort to do so. Why plow developer time into improving something that few people care about today and fewer will care about tomorrow? Maybe it's best to just remove the most obnoxious problems by tweaking around the edges, and let time take care of the rest.
Which, come to think of it, sounds a lot like what they are already doing...
I disagree. Many kinds of extensions are designed to work across multiple sites, and add functionality most websites would either be unwilling or uninterested in adding. Consider extensions like Ad Blockers, Privacy Extensions preventing tracking, HTTPS Everywhere, No Script, download managers, extensions which affect the browser display as a whole (such as Tree Style Tabs), etc.
Its currently a research project, but the hope is the project will mature to the point that it can be incorporated. It also allows for Rust Developers to see immediate uses and usability issues with changes to the Rust language.
1. Mozilla are improving the extension architecture and developer tools too quickly for you to keep up with and that leads to lots of documentation.
2. Because Mozilla don't want people to use their extensions to sell a users information, spy on them, advertise to them etc. the review process takes longer than Google's.
To be fair, they also have a mobile operating system and LGBT advocacy to tend to.
[1] https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/...
There are precompiled tarballs available at nightly.mozilla.org and aurora.mozilla.org I have used these on just about every major distro and several of the smaller ones without issue.
I challenge anyone to locate a one-page official documentation which walks you through a "hello world" add-on creation process? Right now there are a thousand pages talking about add-on, but each one of them also has a thousand links in it to make you jump to other places, then again to jump to more places.
If someone with knowledge of the latest development can put a _complete_ walk-through for a basic "hello world" add-on in ___ONE___ page, it will be greatly appreciated. If there is a date stamp on the page (so readers know if it's still compatible with newer version of Firefox), that would be the greatest thing in the world.
Had the documentation been better, I could have turned maybe a dozen ideas into add-ons which might be useful not just to myself but other users as well. More useful add-ons are definitely helpful to the Firefox movement.
I am a strong believer of Mozilla's mission ("open web"), will continue to use Firefox exclusively for web browsing. Plus, Vimperator/Pentadactyl are indispensable. Writing more add-ons is another way for me to support the mission.
The first one is a personal preference - Inspector seems weird to me and while it may have most of the needed functionality, it doesn't feel like it does.
The second is because there isn't any way I know of to have Chrome start in clean mode (with no bookmarks, etc. from personal use). So, I test and debug in FF and only use Chrome for news, apps, etc.
Chrome has user profiles [1], which are even easier to use than what Firefox uses.
[1]: chrome://settings/createProfile
[1]: http://peter.sh/experiments/chromium-command-line-switches/#...
The Firefox developer tools have matured and recent iterations work a lot like Firebug so I miss it less.
Your second point is very much on target. Because of problems rendering web pages, I haven't found Chrome and webkit-based browsers useable for developing or testing web-based interfaces.
Pages that look good and essentially the same in Firefox and IE will have strangely different fonts (and sometimes layout) when viewed in Chrome, Opera, Safari, etc. Users of these browsers sometimes notice my sites appear a little misshapen and ask what to do. I suggest trying Firefox, or in a pinch, IE.
This is less an issue with mobile viewing since page rendering is different on those devices vs. desktop/laptop anyway. Of course, browser development travels at near light-speed, so the situation can change quickly. But given the mix of old and new systems out there, it's a headache that won't go away for quite a while.
I would love to see firefox converging with NodeJS but given mozilla's attitude towards developers lately I seriously doubt that it will ever happen.
Firefox has a very rich history and the technology is fantastic but sadly it is not made to be easy to the developer.
Another great thing with the addon-sdk is it works with Firefox for Android as well (with some limitations).
Does Chrome for Android even have extensions yet?
Believe it or not, all those technologies used to be fantastically developer-friendly, compared to the alternatives. It's just that over the last 15 years the alternatives have gotten friendlier faster than Firefox has.
Also, those sidebar images with links are really bugging me. See screenshot: http://i.imgur.com/6hbFTqm.png .
Just add the following one-liner to the main stylesheet and to fix it: .meta img { max-width: 100%; height:auto;}
Pushing out a fix now. Thanks for the heads up.
I believe it was Jamie Zawinski who said that there are plenty of those browsers, which are fast but do not do anything unlike Netscape which did everything. However that must have been 15 years ago.
I suppose one could cook up a simple browser just importing webkit, but why reinvent the wheel?
So far I haven't been able to find neither treetabs or scrapbook. I gave concluded that creating real extensions (not just wrappers etc) is impossible in chrome.
You really can't extend the gecko engine on mobile like you can on desktop, since the gecko engine is your userland.
It took me 2 hours for Chrome and was just easier to debug and did everything I wanted.