This post is related to “The Future of Developing Firefox Add-ons” on the add-ons blog. Please read that first for context. A couple of concerns from that post have come up that I would like to address here.
One concern people have is that their favorite add-on is no longer going to be supported, especially add-ons for power users. Some of the ones being mentioned are:
- Tree Style Tab
- NoScript
- Vimperator/Pentadactyl
- Tab Mix Plus
- FireGestures
- Classic theme restorer
We have a lot of ideas about how to make these sorts of extensions work using better APIs than we have now.
- Opera has a sidebar API. Combined with a way to hide the tab strip, we think this could be used to implement an extension like Tree Style Tab.
- We’re working with Giorgio Maone, the developer of NoScript, to design the APIs he needs to implement NoScript as a WebExtension.
We’re hoping people will have a lot of other ideas for the extensions that they care about. If you’d like to propose or vote on ideas, please visit webextensions.uservoice.com to express your opinion.
There are also concerns that restricting people to the WebExtensions API will limit innovation: we can make APIs to support the XUL extensions people have already made, but how will we know what other ones we’re missing out on?
It’s likely that we’ll still allow some access to XUL in the future. We want people to be able to experiment with new ideas, and they shouldn’t have to wait for us to design, implement, and finalize a new API. However, we don’t want this to become another feature like require('chrome') in Jetpack, which is used by virtually every add-on. We’re still trying to figure out how to avoid that fate. We know that we need to be more proactive about providing APIs that add-ons need. But is that enough?
Our big fear is that, once we provide a WebExtensions API, there won’t be anything to motivate people to switch over to it. We can try to deprecate access to the parts of XPCOM used to implement the functionality, but often there won’t be a clear mapping between the old and the new APIs.
Again, we’re open to ideas about how to do this. Moving away from XUL will be a long process. We’re announcing all of this early so that we can begin to gather feedback. APIs that are created in a vacuum probably aren’t going to be very useful to people.
Bill McCloskey's Blog 
I want to add PrefBar to the list of Addons that probably will not work anymore with the new “API”.
PrefBar does quite a lot of things.
– Change every preference, if the user wants to
– Toggle plugins active/inactive
– Run small “macro like” Javascript snippets *in chrome context*
– Execute external applications like other browsers, media players, editors, … just as the user wants/needs to
– All this placed, in form of buttons, to toolbars, menus, organized in submenus, …
… and many more.
I understand that you’ll need a new “framework” as the future “Servo based” Firefox will no longer have XUL and maybe even no XPCOM. But I think I would rather rewrite my Addon as soon as first testing versions of the “new Servo based” browser are available than to write something for some Walled-Garden API. Just allow me to use whatever you will use to run your HTML GUI. I guess there will be some Javascript based API just like XPCOM. Give Addons access to this. This is what makes Firefox different. Users already have a choice if they need a browser with feature-reduced API.
“We want people to be able to experiment with new ideas, and they shouldn’t have to wait for us to design, implement, and finalize a new API. However, we don’t want this to become another feature like require(‘chrome’) in Jetpack”
How about maintaining a a separate developer branch or ‘prototype’ annexe to AMO specifically to allow add-on developers to build proof-of-concept add-ons and thus inform Mozilla’s API development. A sort of community Mozilla Labs, with significant flags and protections (e.g. withhold signing or requiring an add-on or explicit about:config setting to enable installation of and privileged access to XUL and XPCOM) to forewarn end-users that such add-ons are not for general use by the uninitiated.
Before going public with something like that you should have the CLEAR answers to your questions BEFORE going public.
Right now lot of developpesr will not even care to update their add-on for E10 since they “know” that in around 12 months they will have to scrap their work.
Bravo Mozarella !
And yet every time Mozilla don’t tell people as early as possible of what’s happening (no matter how publicaly they work on forums, blogs, bug trackers, etc), people complain that they weren’t “transparent” enough.
And add-on developers who scrap their addons rather than trying to work with Mozilla on this aren’t worth discussing. They’re the ones who complain the most about reviews taking forever, and their addons breaking with every version. Nobody said complex addon development was easy. Whining about it and walking away from an addon now isn’t sympathetic behavior – it’s just pathetic. It’s using this as a scapegoat to cover for your own lack of interest at worst, and just giving up at best.
Re avoiding the fate of require(‘chrome’) and other unmaintainable features: don’t cave in, and just don’t make a require(‘chrome’) escape hatch. Otherwise it will inevitably canibalize the web platform APIs. People will just postpone change, and avoid the hard question of actually building consensus on the APIs, which will fail from disuse.
Will have to think harder about what a good feedback cycle to properly iterate new APIs would look like.
So I guess add-ons like https://addons.mozilla.org/en-US/firefox/addon/backtrack-tab-history/ which modify behaviour and UI, but have only a few hundred users, will simply no longer be welcome? Not enough users to be worth the effort of developing a new API for, and fundamentally incompatible with the limited access WebExtensions is proposing to offer…
This is what i’m afraid of. Popular addons will get helping hands from Mozilla directly but what about less popular addons or lesser known addons? here’s one example that i’m talking about ( https://addons.mozilla.org/en-us/firefox/addon/moz-rewrite-js/ ). I have plenty others but listing them all here is way too long because i’m using 76 Addons (my firefox setup is stable and i’ve been a firefox user since Firefox 1).
There’s a good idea in webextensions.userchoice.com: make the extension-breaking changes on a fork of Firefox. If users don’t care, they’ll use the new version. If they do, “their” version is still there for them. If 98% of users go for Option B, Mozilla can backtrack without losing its remaining users. Less fury, more usability, less transition aggravation.
Anyway, what I came here to do was list the extensions I won’t live without: Adblock+, NoScript, Classic Theme Restorer, Tree Style Tabs, Stylish, Firebug, Zotero. NoSquint is also important, although not as end-of-the-world as the others.
I’ve been using Firefox since it was Firebird, and Netscape before that. I’ve been so cross about Mozilla’s cavalier treatment of my extensions — whose functionality is essential to me — that I’ve put a hold on an out-of-date Firefox and haven’t updated. Reading about their stuff-the-user plans means I’ll be actively looking for some reasonable browser again — no, not chrome/chromium. Braindead UI. — unless a clarification comes from the folks up top that makes it clear this will not be the biggest stuff-the-user move of them all.
“However, we don’t want this to become another feature like require(‘chrome’) in Jetpack, which is used by virtually every add-on. We’re still trying to figure out how to avoid that fate. We know that we need to be more proactive about providing APIs that add-ons need. But is that enough?”
This for me is the most concerning thing about this – that the decision has been made and announced, but without a clear understanding of why WebExtensions will be better than Jetpack (other than compatibility with Chrome). The fact that commercial operators are less willing to write Firefox extensions is IMO as much to do with the slow review process as the differing API. Where is the analysis that says that all this upheaval has a better shot of fixing things than doubling down on Jetpack so that the majority of addons can be written in Jetpack without require(‘chrome’), and hence have a speedy review process?
To answer your question, I suspect that no, MoCo providing APIs isn’t going to be enough – there’s just not the focus on the ecosystem. Particularly since this direction doesn’t seem to play well with the idea that browser functionality should be written as extensions (which would help align incentives).
One option is some form of more-invasive extensions which can be dependencies of standard extensions, and would expose APIs to standard extensions. These more invasive extensions would have higher-bar review processes, but allow communities to share this intrusive code – reducing review requirements for everyone, speeding things up, and limiting the number of authors who’d need to be contacted when compatibility problems arise. For this to work well, the addons system would have to support the dependencies natively – ie not require everyone shipping an extension to ship a copy of the dependency.
Why not just put more resources into Servo and browser.html, and then make the big backwards incompatible API change once they’re ready?
I think one thing that needs changing, is the in tab stuff, it looks too much like Chrome but uglier haha. If we’re going to rip something from Chrome we should do it better 😛 (like Google initially did, they took all us Firefox engineers and rip everything from Firefox but do it better/faster).
js-ctypes please! Keeping it? I think the changes are good if we can now use js-ctypes or js-cpp-types to use XPCOM from threads, because XPCOM just has that lack of running from multi threads.
But Servo has no XPCOM right? So does Servo have identical replacements for all things XPCOM? In which case can we call that via ctypes or other things?
One design flaw in Firefox is, that js-ctypes can’t set from workers/threads to run code on the main thread (main thread callbacks) so I’m hoping this redesign fixes that so we can run callbacks on the main thread as parts of the native APIs (Windows, Mac OSX, GTK, JNI) need to have stuff call on a certain thread.
Going away from XUL to HTML is an awesome idea, but how about xhtml (which really is just html)? The xhtml localization is much faster then the i18n localization.
Keeping js-ctypes would also allow us engineers to do engineering, and not be limited by if the WebExtensions API doesn’t have support for function X, then us engineers can’t do what we do best and engineer solutions easily when one didn’t exist.
Basically if you make it so that we can only make things that your API provides, that totally takes out the artsy aspect, creative aspect, engineering aspect. That’s heartbreaking. 😦 Right now add-ons are an art form man its just beautiful. 🙂
These changes I’m hoping are for attracting addons from other browsers to Firefox. Not for making it easier for people who made addons for Firefox to port them to other browsers haha. I take pride in my favorite addons (ones I made and others that I use) are not possible on other browsers. 🙂 Also this new API sounds like its good so the newbies can jump in and make addons right away, as they have hard time getting into our powerful system. So maybe:
* Remove main thread xpcom, make callable via js-ctypes from workers/threads (or whatever servo is using, something callable from other threads for us via ctypes or something else as long as its the equivalent of XPCOM)
* Support for setting up js-ctypes callbacks on other threads, including especially main thread
* XUL -> XHTML == awesomeness
* WebExtensions goal should be to enable addons from other browsers to come to Firefox (not other way around) and should also be for making it newbies to get in and make an addon right away, and as they invest time, hopefully they’ll move up to the more powerful addon ecosystem.
* Browser chrome UI is going to html/xhtml right? so we can still change that up?
I applaud Mozilla for trying to improve their browser speed (I personally feel
as though they don’t get enough credit for the improvements already made). But
trying to make addons work “cross browser” is possibly the dumbest idea I could
ever imagine. By definition it means that firefox addons can’t access features
that aren’t available in other browsers addons, which (also be definition) means they
can’t be better than their counterparts from other browsers. Do you have any
idea how many of your current consumers are only with you because the addons
are better. Many of us have desperately hoped that another addon from another
browser would provide similar functionality so that we could leave firefox, but
kept coming back to firefox because of the addons. You’re trying to compete with
chrome by making a chrome copy??? Your current consumers will leave in disgust
and why on earth would anyone leave chrome to adopt an exact replica. If our
choices are chrome and chrome-copy then it’s a sad day for all of us.
For your own survival, please make sure that before you complete this move. The
web extensions API is done in such a way that vimperator/pentadactyl and similar
addons remain (in look and feel not in code) completely as they are now (100%).
You will never bring back chrome users by being chrome and you will lose your
current user base.
> “Our big fear is that, once we provide a WebExtensions API, there won’t be anything to motivate people to switch over to it. We can try to deprecate access to the parts of XPCOM used to implement the functionality, but often there won’t be a clear mapping between the old and the new APIs.”
I don’t know anybody who has successfully motivated their users via intimidation. If the WebExtentions API is strictly better in all senses then people will naturally make the change themselves. Being easier to review to enable a faster release cycle, compatibility with Chrome, easier to use than XPCOM, better toolkits for development, etc.
I don’t think depreciation is something you should be doing as a threat. Surely it makes more sense to depreciate this functionality when the addons that make use of it have dropped to a trivial amount. If that’s what you all meant in the first place then that really isn’t being made clear currently.
Out of interest, does this change effect Classic Theme Restorer? That addon has been the top-rated addon for a while now and its one purpose is to undo the “improved” Australis layout. I feel like that should be a good indication that some of your development team appears to be seriously out of touch with your userbase.
Threat? This is reality. Either Firefox can move to a better addon system, or it will be forever stuck spinning its wheels to support increasingly broken XPCOM addons. Why can’t people see that?
What you need to avoid is chrome’s extension issue. It doesn’t wait for extensions to do their work, for speed. This cause extensions to not function. Very bad for security and privacy extensions. The only thing needed for an extension to be skipped is a paging from pagefile to memory or simply having the hard drive overloaded by background work like a virus scan.
Firefox do the right thing. Yet now Firefox is switching to chrome’s model?
Is performance now more important for Mozilla than user-control, security and privacy?!
What about Chrome’s bottle neck? The main chrome process can easily be overloaded causing everything to stop. Funnily enough the main process is single core only. It can’t expand to other cores, multi-threaded. It is limited to the speed of a single core. (My observation, reproducible every time)..
Is Mozilla going to adopt chrome’s issue tracker behavior too?
Wait 4 years before responding to bugs. Have the audacity to ask to update the sample code.
What about the infamous memory issue chrome have?
Firefox already got leaks, now multiply that with a lot of Firefox processes. Not good.
Should I even mention how big and nasty the plugin-container gets including the infamous gluttonous flash process?
Why didn’t you mention Adblock Plus? It’s a very important extension too for security and privacy.
Other important extensions:
CanvasBlocker
Disable Plugin & Mimetype Enumeration
Disable Visited Links
Disable WebRTC
NoRedirect <- especially this one to block redirect tags (They can't be blocked in chrome)
Maybe a bit off topic but these are important too for many users including novice users:
Greasemonkey
Stylish
DownThemAll!
Tab Mix Plus
Hide BookmarksBar
Please don't treat users as children and patronize us. Other companies already do like Google, Apple, Microsoft and it is infuriating to say the least.
Hope that was useful.
Hello, I’m the author of the listed addon Tree Style Tab.
You mean that we can rebuild Tree Style Tab with the sidebar API. However, I think that you don’t find out what is the essence of TST.
I believe that TST’s unique value is a natural compatibility for other tab-related addons, and sidebar API based TST loses the value.
If I rebuild TST using such a sidebar API, it can probably provide tree-like GUI in a sandboxed frame, working instead of Firefox’s native tabs. But, probably other addons can’t cooperate with it, because most addons’ authors think about only their addons and Firefox’s native tabs. Even if new TST became available based on the sidebar API which can’t cooperate with other addons, it’s useless. Moreover, then I’ll receive more and more requests for the sidebared TST, like: Please add the feature provided by another something major tab-related addon, like “copy tab title”!
On the other hand, current TST changes just the appearance of Firefox’s native tabs, so other tab related addons also work with it seamlessly even if they don’t know TST. If an addon provide a new menuitem “copy tab title” in the context menu on tabs, it is also available even if TST is installed, because TST’s “tree item” is truly Firefox’s native tab. I mean that this is TST’s natural compatibility for other addons. I think this value is never available with isolated addons based on sandboxed sidebar. Like the UNIX strategy, one addon should not include too much features, because one author only can do a few work. Instead, one addon should cooperate with others casually. I think this is why Firefox is loved by many power users.
The reason, why TST seems unstable and fragile, is that there are too less entry points for addons which work on Firefox’s low level layer. Because we never can insert our custom operations to Firefox’s features (like dragging of tabs, bookmarking of webpages, etc.), we have to replace it entirely or rewrite internal functions. If more stable entry points become available, TST will be more safe, stable, and compatible with other addons.
Anyway, my conclusion is: I believe that low-level extensibility for addons should be kept, even if new extension APIs become landed. Extensibility based only on isolated APIs will kill addons’ casual cooperation.
Thanks..
One addition.
If addons based on new APIs can cooperate with others casually around Firefox’s native features like current TST, I passively agree to the decision of killing low level extensibility for legacy addons. Basically Firefox should be more safe and stable for non-power users – I think so. If new APIs truly can build addons which cooperate with others seamlessly with enough rich entry points, then I’ll have no reason to negate migration from legacy way to the new way – except that it is a hard work.
No love for downthemall or Font Replacer? Those two are some of the biggest reasons I use firefox over other browsers…
Mozilla need to have a modular API. Allow developers to create libraries to extend the API. These libraries would make Firefox updates MUCH more manageable, since the number of API libraries will be vastly smaller than the number of Addons in the AMO. These could be turned into community projects and contributed to by Addon developers.
It would be best to have a Core API that developers can use for cross-browser addons. Then have an extended API for Addons that can only run in Firefox.
Another idea…have hooks into the lower levels of Firefox through the API, but make it a permission based system. Like in iOS, alert the user when an extension wants to access some resource (ex. your bookmarks).
As for XUL, for starter a replacement could be modular dynamic HTML5 component overlays. Extensions such as DownThemAll could launch like a Chrome Web App. Extensions like Tree Style Tabs could use an HTML container that communicates with the browser. Make the rest of the UI modular and manipulable through the API.
Bill, I don’t know how much of this makes sense. I would love to hear your thoughts on this and talk about this some more.
Regardless of what Mozilla decides to do, I hope my favorite Addons will be supported. Like:
1. Tile Tabs (Very Important)
2. Locationbar2
3. Omnibar
4. Open With
5. Resurrect Pages
6. Thumbnail Zoom Plus
7. Tab Scope
8. The Fox, Only Better
> One concern people have is that their favorite add-on is no longer going to be supported, especially add-ons for power users. Some of the ones being mentioned are:
So what about the other 14,224 addons?
first feedback: I’ll block firefox updates until this is solved. this means: until there wil be some kind of compatibility mode, or all plugins i’m using will be adapted. i’m not using a lot (like 10 addons maybe), i always cared about to use as few as possible, but those are definitely essential for me. it’s also the first time, i’m seriously thinking about to change to another browser. this change makes it the perfect time for it.
don’t get me wrong, maybe all this may be needed for some reasons,sure, but i’m worried about that some coders of extensions won’t make new versions. either because they’re not active anymore, simply don’t want to use the new API, or because necessary functions aren’t available and it will take months or years until those will be available.
things like this MUST be a parallel working process, so firefox will be compatible to old extensions for awhile (until day x for example) to ensure availability, until new API is complete enough and replace them with a new API version, as soon available.
again: probably this step is needed, but serious: meanwhile i really could use chrome, since firefox will be matched more and more to it. the difference between both (3rd party stuff, limitations, etc.) is getting smaller with almost every release… and not meant in a positive way.
A few questions for you Bill:
So, you’re actually saying you’re going to work with a small handful of well-known extensions to create extension-specific APIs so they can perform their specific, single task? Isn’t that right against what Extensions is all about? I thought extensions were about having the freedom to modify and extend the browser using an open framework, not something that would require task-specific implementations by the actual browser developer.
What about new ideas that could be implemented with XUL but need a new API for WebExtensions? I doubt developers would be able to properly develop anything if they have to rely on something that isn’t implemented yet or has to be translated to something that isn’t implemented yet “later on when it’s in the browser”. How would that motivate small-time, volunteer developers to build anything? Or are you just focusing on working with companies to integrate commercial extensions that need APIs in lieu of XUL?
What about highly functional extensions that don’t have many people using it but that are absolutely essential for people who do use it? I can’t imagine Mozilla would ever give those light of day (because: maintenance cost) and you’re destroying the open add-on ecosystem that way – more than has already been done, anyway. Who will be vetting the requests?
Also, won’t that, in the long run, just lead to a very messy, complex extension system with so many different APIs that you’re creating a spaghettimonster?