> You need to re-examine your review policies, and figure out why Chrome can manage to approve extensions in a few days, when you take weeks to review the same code.
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.
And an other component is Firefox extensions have significantly more power available than Chrome ones, so they would need more review to be trusted even if Chrome extensions had any.
Firebug could be built for Firefox (however hard and painful that was). You can't build anything similar for Chrome.
Some kind of review or moderation in the Chrome webstore would be pretty useful.
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.
I have made extensions and this review process is a total pain, but remember that mozilla is a volunteer based project and they seem to need help on that aspect, maybe they should invite people to join their reviewer team, they have local users groups that can make that happen.
Please submit your feedback and ideas about the review process to Mozilla, I'm sure they would work harder to improve the review process if more people would let them know how painful it is.
Agree people in my company have been negatively affected by chrome addons that "went bad" ie they were at one point legitimate but got sold to adware companies.
They have started moving toward a review process over the last few months. Extensions now go through an automated review and can be flagged for manual review if they appear suspicious.
I disagree. Reviewing should never have been part of software culture but sadly is becoming a norm.
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.
By having a review process for extensions just a few suffer (the extension developers) and many (the users) benefit, because they can trust the browser.
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!
> By having a review process for extensions just a few suffer (the extension developers) and many (the users) benefit, because they can trust the browser.
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.
But how is the general user supposed to be able to evaluate technical questions like whether their new extension is spying on them? If it appears to be doing what it said it would do, they aren't going to pop the hood and see if it's doing anything else. All you'll get is 10,000 variations of "I downloaded the More Smilies extension and got a bunch of smilies! 5 stars."
If the problem is spying specifically, then build a proper sandbox for network traffic. Make sure the user knows if they want the sandbox disabled (or extensions seek specific permissions).
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?
As somebody who works right now on a Firefox extension I can't agree more.
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.
Statement that firefox Add-ons inside the broweser don't have a sandboxing is false. All the add-on SDK built add-ons load in sandboxed in a less privileged JS sandbox, although it is true that there is an escape hatch via `require("chrome")` as some add-ons just want to make modifications that are not even possible elsewhere. This is also reflected on reviews add-ons that do not use `require("chrome")` go through a faster review process while add-on's that do use `require("chrome")` get more thorough reviews.
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.
> While this makes things little confusing for newcomers,
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.
Five years ago or so, you could debug extensions with Chromebug, based on Firebug. It is what we used to debug Firebug itself. But when Mozilla decided to go and split out its own DevTools about three years ago, the writing was on the wall, and the lead developer John left. Unfortunately, he was the only one that really understood Chromebug, and Mozilla kept changing things that broke it with each new version of Firefox.
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. :/
I've written Firefox extensions, and I gave up on the official Mozilla extension store. It is far easier to host the extension xpi yourself and provide the update configuration in your extension manifest for your own webserver. This lets you auto-update your extension yourself. The only downside is you have to learn how to sign the extension with either the command line or an eccentric GUI program on windows.
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.
Moving OT a little - it seems that signing things should be a [more] central part of all major OS nowadays. Our OS should be signing the docs we send for us, signing our emails for us, signing pics we send to family so they can see they haven't had any changes made in transit, etc., etc..
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.
> When I tell other coders that I try to do web development in Firefox, they give me sad, withering looks
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 hate Firefox, I use it as my primary browser, but its developer tools are terrible compared to chrome. If you have the network console open while a large page loads, good luck interacting with the chrome until it's finished.
Which tools and which versions of browsers are you comparing?
I guess as a developer you would be using Canary Chrome vs. Nightly Firefox, to get the latest features, right?
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.
> its developer tools are terrible compared to chrome. If you have the network console open while a large page loads, good luck interacting with the chrome until it's finished.
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.
Btw, we debug a lot of JS code and although Chrome has better developer tools they do crash... a lot and are unresponsive too. Chrome/Webkit should have native tools not the one written in JavaScript because this is a mess. They are still better than Firefox's dev tools.
Firefox's developer tools are terrible even compared to Internet Explorer 10/11 (which are actually surprisingly good). But at least Firefox as 3D doodads, because that's important...
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.
> (Chrome requires some tricks because it only accepts scripts from the store these days).
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)
If you think Firefox is bad, try writing an extension for Thunderbird. All the docs talk about old XUL based extensions and new Jetpack ones, and there's even articles on their dev site about building Thunderbird extensions with Jetpack, but the truth is that Thunderbird support was removed from Jetpack. I had to check git logs to find this out!
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. :-(
The way Mozilla treats is own supporters (Thunderbird users and developers ) is disheartening... Sure it's less glamorous than mobile, datajournalism or <insert buzzword here>, but we need a quality FOSS email reader and I'm seriously considering switching to 19 years old Mutt
The fundamental problem is Mozilla has drifted further out of touch with reality as the funding it receives is not attached to incentivisation of the correct course of action. At this point they look like a social justice movement masquerading as software development organisation, with the net result being a greater appeal to the social justice movement than software developers.
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.
I think there is some truth to your critique, but I'm not sure the conclusion should be that Mozilla should be focusing on software developers, as software developers are not the bulk of its users.
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...
>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.
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.
True, but (1) for better or worse, these are all things that are of interest primarily to the clued-in nerd audience, not the public at large; and (2) the greater capabilities offered to extensions are a double-edged sword. It's true that extensions can do things that sites cannot, but that also means that they can compromise users' security and privacy in ways sites cannot too. In a world that's a lot more security-conscious than it was 15 years ago, a decent argument can be made that the security risks highly empowered extensions present outweigh the value they bring to the table. (That's a decision that ultimately rests on how popular they are with the mass audience, too; it's easier to shut down a security hole that nobody depends on than one that millions of people do.)
…which is why the add-on review process is time consuming, and why AMO shows you half a dozen warnings before letting you install an unreviewed add-on.
Right -- which is (part of) why interest in extensions is declining. It's a self-reinforcing pattern: platform vendors tighten security on extensions; extensions can now do less and are harder to get, so fewer people try them; which makes it easier to tighten the security screws on extensions the next time around.
Maybe Servo will be their clean slate. I know it's an experimental browser created to help test a language and parallelism in web APIs, but if it does well, it could come to replace Firefox. This is unlikely and years away at best but it's possible.
Gecko is not even a browser, its a layout/render engine.
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.
It does seem like disarray is creeping into Firefox. The little things like reviews, docs, Aurora PPA[1] (ok, I'm squeezing my personal problem in here a bit) are falling behind.
To be fair, they also have a mobile operating system and LGBT advocacy to tend to.
Ubuntu controls the PPA. Ubuntu has reassigned the developer that largely lead the Ubuntu Mozilla integration. There is little we as Mozilla can do to control this. If you need this resolved complain to Canonical management or find someone from the Ubuntu community of Nightly/Aurora users who wants to own keeping the PPA running.
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.
The documentation for writing add-ons is really bad.
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.
There are two bright points to using Firefox: 1) Firebug and 2) it isn't Chrome.
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.
When it works, Firebug is good and useful, though with some Firefox "Nightly" versions, Firebug is broken. Of course, I know, that's what I get for running Nightly...
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'm very pleased to see Omniref write this article, as I wanted to write the same article myself after my experience porting my extension from Chrome. Everything they complain about is true - the Firefox Add-on SDK is a pain, and the approvals process is a pain. The only thing this article leaves out is how much of a royal pain Mozilla's Add-on documentation is. It doesn't help that ten years of changes to the extension workflow mean there's a whole lot of jargon to absorb (Bootstrapped extensions? Jetpack? XUL?). If I release further updates to my Chrome extension, I'm not sure I'll bother with Firefox.
I have also experienced this sad situation with Firefox. XUL was my biggest disappointment because mozilla was not willing to invest any time to make it better. Instead they shipped this monstrosity called addon-sdk. You need python to develop JS applications? This is stupid.
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.
> Firefox has a very rich history and the technology is fantastic but sadly it is not made to be easy to the developer.
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.
You don't even have to submit anything to Mozilla. Firefox is able to sideload extensions just fine (unlike Chrome). Just make it available for download straight from your website.
Slightly offtopic, but are there plain fast browsers which only do HTML, CSS and Javascript no plugins, nothing else?
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?
Firebug. Chrome doesn't have anything as responsive.
However, Firebug STILL does not support source maps. I have been jumping between tools for this reason alone. Usually, Firefox is my primary browser for dev work.
As someone who has had a semi popular Firefox plugin going on 8 years now, I agree 100%. We are trying to figure out how to dump our main plugin, but so far no buyers exist. Maybe I should just sunset it. :-/
Sometimes I try to find the most important extensions on Chrome.
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.
The critique of the development process doesn't really apply. But the review process does to a degree – there are high-privilege APIs in Firefox OS that require review to ensure they are used responsibly. Distributing apps that use those APIs requires approval.
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.