As I said elsewhere, I reviewed thousands of addons for addons.mozilla.org back in the day. The number of extensions which used XBL directly were just a handful, and usually by the most capable developers. I have no doubt these developers would have adopted to XBL going away, especially as WebComponents is basically a replacement for most of it.
That some of XUL has gone or was moved to HTML doesn't really matter much either. People could have adopted to this as well. Adopting to ongoing changes in Firefox was the bread-and-butter of extension development before WebExtensions (or the add-on SDK/jetpack), a necessary cost of doing business with the reward of very powerful things you could then do in and to the browser. With JetPack and the Addon SDK mozilla tried to provide stable APIs with some success. Adding WebExtensions to the mix would have helped, just to make it easier for Chrome extensions devs to port their stuff. People not in need of anything besides these stable APIs could use these and be done. People who needed more powerful capabilities would have went the other route and tracked Firefox changes, just like they used to for over a decade already anyway.
There were tons of major breaking changes over the years (Firefox 3.5 to 4 was particularly "bad" IIRC), and while those caused some causalities over the years with abandoned extensions not getting updated (tho most popular add-ons affected got new maintainers or were forked), most extensions kept going, adapting as needed.
I am pretty sure that I could pick up my "legacy" DownThemAll! code now and today, spend a month adopting it, and have a working version for Firefox 94+. A month may sound like a lot for some hobby project, but in an alternate reality where "legacy" add-ons still would be supported, I would have spent that month over a duration of the last 5 years.
But in this reality, I have no supported way to actually load such a "legacy" extension. I could add such a capability back to a Firefox fork, but then only I would be able to use it, but nobody else would... Unless I released the fork, and really, I don't have the resources to maintain an entire Firefox public fork.
I agree, it's untrue. In my opinion, most of the problems Firefox has stem from mismanagement and utter lack of vision.
This has a lot to do with mozilla losing their leaders and rock star devs at a rapid pace in the last 10 years. Some golden-parachuted out to the FAANGs, others just shrugged seeing the Mitchell Baker Club got more and more influential in a bad way and looked for less toxic places to work, and of course Eich prominently got cancelled for being against gay marriage and his departure rippled through the entire community. I was subscribed to planet.mozilla and there was a constant stream of "it's been fun, I am moving on" blog posts by names I immediately recognized.
The Code of Conduct situation caused a minor exodus especially in the volunteer community, especially outside of the US. A lot of rather important people, who were the ones building the local communities, just had enough with mozilla corp leadership unilaterally pushing stuff on them without soliciting any feedback first. mozilla was supposed to be this community of equals and Corp dictating more and more things really did not sit well with a lot of folks. Some outright (and sometimes rather publicly) left, others just dialed back their volunteer time a lot. This left especially the Western European communities in shambles.
The WebExtensions switch caused a lot of extension developers (who often were also volunteering in different areas of mozilla) to move on.
The loss of extensions, themes and customization options made a lot of the power users very unhappy. And those power users were exactly the kind of people who kept telling friends and family to use Firefox, driving Firefox adoption. While they often kept using Firefox themselves, they also quite often stopped advocating for Firefox in their circles.
All of this put together, mozilla losing leadership, volunteer, power user and dev mindshare at such a rapid pace then translated directly into a loss of market share.
Major failures such as FirefoxOS and BrowserID furthermore have been very demoralizing, making mozilla leaders very cautious, to the point where you had very little innovation going on from the top down. These failed projects - especially FirefoxOS - furthermore took away a lot of developers from the core product, leaving Firefox in a place where for years they had to play catch up with Chrome.
Things like Rust and servo where went more of a bottom-up direction, with bright engineers pushing it, not so much the leadership. And then these things were the first ones on the cutting block last year.
Google only "helped" in so far that they kept mozilla busy playing catch up, making the situation worse by a ton of (experimental) features and new specs that Firefox then had to implement, thus taking developers from other areas that needed improvement. I think most of the time it wasn't Google's intention to fuck with mozilla tho, it just happened to be the outcome.
>I tried to work with Mozilla to get a couple minor changes made to enable some of the missing features, but that went nowhere fast.
Yeah, unless you actually write the code, there is no way. And writing code for the mozilla code base can be quite intimidating with their mix of C++ and js and XPCOM and not-XPCOM and webidl, etc. I once submitted a patch (unrelated to my extensions) that bounced from the who-is-who of mozilla rockstar devs at the time, and nobody wanted to really even look it because it was changing something so deep within the XPCOM-Javascript bridge and nobody really remembered how it even worked. I finally got my r+ from some brave soul who just said "I don't really know the code it touches either, but somebody has to do the review".
Even if you do the work, it can be an uphill battle to get code in, especially if you're trying to add new features and not just fix existing bugs.
I spoke to people within mozilla back in the day - I was part of the community after all and knew a lot of folks - and they weren't exactly happy, but weren't in a position to make things better, either.
DownThemAll! was big enough that they eventually "officially" reached out and ask me what I need, and then essentially said they couldn't really do any of it, "sorry" and they know "that sucks" (refreshingly honest, at least, but I wasn't talking to upper management but a developer-turned-developer-relations). The person who contacted me, one could tell, was given a mission to appease developers by showing mozilla cared, but wasn't actually provided any resources to really help or support people. All that person could do was to apologize and suggest to read the docs and read the docs on how to propose and implement new APIs - but at the time I had already proposed some new APIs that in my opinion would not just have benefited DownThemAll! but all kinds of add-ons dealing with downloads, and was struck down as "not generally useful to a lot of add-ons, sorry, we do not want to maintain such an API" already.
What I said almost 5 years ago still is true in that regard: they tried to a certain degree to accommodate some of the really popular add-ons, and with some success too, and the smaller add-ons were left in the dust. Not because of ill-will of mozilla, but simply because they lacked the resources to do anything more.
I (Nils) am the maintainer, and I would more characterize it as slumbering, not entirely abandoned or dead. I keep meaning to fix bugs and make new releases, but as we all know the last two years have been a bit crazy ;) I know, that's a lame excuse, and I already planned to do better now that things in the world finally seem to settle down a little, even before seeing this little reminder pop up on HN.
I (Nils) was the maintainer of it for many years at the point already, and I was genuinely considering to let it die for quite a while. I was furious at what mozilla did to the loyal and active extension community and especially on how they did it - essentially by decree without community interaction at all. I was part of the mozilla volunteer army, not just with DownThemAll! and a few other more minor extensions, but I also had been on the team reviewing add-on submissions - I think I reviewed something like 2000-2500 individual submissions including updates in the end - and contributed a few minor bits to Firefox itself. The carelessness of how mozilla approached this large chunk of their community, after declaring their "1 million mozillians" goal not too long before, was mindblowing to me.
I eventually decided not to let it die... DownThemAll! had been a big part of my life, and while I recognized that I had to dumb down the feature set, I saw a way to at least make the core stuff work, maybe. I am glad I tried it even though it required a considerable amount of time to fully rewrite this thing.
The net result of mozilla's move was that they killed a large number of useful extensions entirely, while the survivors then usually became available for Chrome as well thanks to the mostly shared API - DownThemAll! is available for Chrome as well right now - giving users even less incentive to stay with Firefox. Oh well.
Yeah, it was 2006 when I joined you and Federico, if I remember correctly, while you and Federico started DownThemAll! in 2004. #201 is correct :D
2006 was really a long time ago...
DownThemAll! went through a lot of revisions since that time, including the work it took to make it restartless, then make it compatible with "electrolysis" and so on. And in the meantime ensure it didn't break with every Firefox release. But at the core the functionality kept the same. People contacting me with questions could be quite overwhelming - and I am sorry if some of you HN'ers mailed me and I didn't answer - but it was very enjoyable to see what different kinds of people were using our creation and get in touch with all kinds of folks that way, from students downloading lecture videos to movie editors downloading the "dailies", and everything in between.
I am still not happy mozilla decided they had to break all extensions, and I had to do a full rewrite as a WebExtension, and thus abandon a lot of features that simply are not possible anymore with that new API, while at the same time reinvent the wheel for the UI (now being forced to use vanilla HTML, which can be quite hard to get performant enough when people queue a couple of tens of thousands downloads at once). But the very core of functionality, namely selecting and queuing up a lot of links quickly, is still there, so I hope some people still find this new DownThemAll! WebExtension useful.
Lastly, while the last release was indeed 2 years ago, I keep meaning to fix some bugs and make a new release. I was already planning to set aside a lot of time this month for that, even before seeing DTA pop up on HN again. I guess this HN post can only motivate me more :D
Federico's death was incredibly sad. We only met once in person, but he was such a nice and humble guy, not just in real life but online too. I miss him too, may he rest in peace.
I volunteered massive amounts of my time for mozilla for more than a decade now, not only developing. I do not consider my previous statement rushed, but a realistic prediction based in a decent foundation of experience and knowledge, and - rather unfortunately - so far I am right and there is no indication that that's about to change.
I'd really like to share your optimism here, but really, knowing what I know, I just cannot.
From Nils Maier, developer of some of the most complex and most popular extensions, DownThemAll! (+ MinTrayR):
Read my comments
That comment by Giorgio (nice guy btw, shared a room with him on at a couple of mozilla events) is over a year old by now and rather optimistic. So far, nothing of that happened, nor will it ever happened at a scale that actually accommodates most add-on developers.
I get this conclusion from over a decade of add-on development, and many years of volunteering my time to/for mozilla in various capacities incl helping other add-on developers, reviewing add-ons for AMO, fixing bugs within Firefox itself, during which I became quite familiar with the code base and development process of Firefox.
PS: As to maintaining XUL vs WebExtensions API, they always maintained XUL/XPCOM themselves because that's what Firefox itself uses, meaning the entirety of Firefox developers "maintains" that "API". They regularly broke stuff for add-on developers, which was sometimes annoying, sometimes avoidable, and other times just necessary.
Some add-on developers learned to adept to that, other add-on developers switched to the add-on SDK (which like WebExtensions is a limited API, just not chrome compatible) if it was feasible, and a lot of developers will switch to the WebExtensions API if feasible in the future or even now.
The current Firefox UI is XUL and XBL, tons and heaps of it. Re-implementing it in e.g. HTML is not an easy task, in particular not when you also want the result to look at least somewhat OS-native (took XUL itself ages to get there, btw). You also cannot do the OS-native look in HTML alone, you need support from the engine, which means servo has a some work ahead on that front too.
So for the foreseeable future, servo is not an alternative to replace XUL/XBL anyway. mozilla said that themselves.
Using servo to render the actual web pages inside the browser, that's another matter (once servo is considered stable enough, of course).
To the add-on developer, this should not really make any difference anyway, XUL add-on, SDK add-on or WebExtension alike, as most add-ons for the most part will use the regular DOM APIs which servo has to provide anyway to interact with web stuff.
Sorry, but that is just wrong, Certain types of APIs are infeasible to provide, because mozilla is too time and resource constrained to invest major resources into spec'ing, implementing and maintaining "niche" APIs.
So far, Firefox did not even manage to reach chrome parity, let alone bug parity.
They are trying I guess, and may succeed for a bunch of use cases to bring what's required. But certainly not all. Even the add-ons that can be somewhat reasonably be ported will have to deal with limitations, and I think the quality of some of those ported add-ons will take a (major) hit.
To elaborate:
If you're doing "web stuff", toolbar buttons, and request stuff (adblocking etc), you'll probably be fine. If you're lucky enough that you only need a few additional new things and your name is e.g. Giorgio of NoScript, you also will be probably fine.
If your add-on does not have a sizable user base, and you do fancy things like modding the browser UI itself, or doing something else not entirely "webby", your outlook is a lot less rosy.
Firefox always broke stuff, since the very beginning. Mayor stuff, sometimes for no good reason, sometimes for very good reasons. Add-on developers learned to deal with it. A lot of add-on developers now have an alternative in WebExtensions, which will ease that pain indeed.
But those developers that cannot or will not use WebExtensions (e.g. I will not/can not port most/any of my add-ons incl. DownThemAll!), but probably would manage breaking changes (I did that for more than a decade now), are left in the cold, rainy dark now.
>Reaching into content windows is forbidden [modulo CPOWs] in multiprocess Firefox.
It is not forbidden, it is just different, using frame scripts or CPOWs.
>That alone is going to break tons of addons.
It will break a ton of add-ons, it will not break a ton of other add-ons. And also the "breakage" varies and would be a in the range of learning a bit about frame scripts and then fixing up a couple of tens to hundreds lines of code, as opposed to porting your entire add-on to an entirely new WebExtensions-API, which essentially would require a rewrite, if that is even possible at all without losing too much functionality.
>This necessitates a redesign.
It does not necessitate a redesign of the Firefox extension API if that's what you mean here.
>Since a major redesign is necessary anyway, it makes sense to future-proof the architecture so that addons will work in perpetuity.
Just like Add-on SDK add-ons will work in perpetuity... Oh wait, they never did.
The WebExtensions API will introduce breaking changes sooner or later if you want to keep it sane and secure, as any API does, because no API is designed perfectly with perfect future vision.
It will probably break far less often than the "open API", and that is a good thing. I'm not opposed at all to a nice, new, shiny, stable WebExtensions API for those users that are not affected by it's limitations.
Actually, I hoped that Jetpack/the Add-on SDK would become such an API back when...
>Ultimately, this ends up being friendlier to addon developers, since addons will break once instead of again and again as the architecture evolves.
It is not friendly to intensionally break thousands of existing code bases to the point where you will need to almost completely redesign and rewrite your code, wiping out a ton of add-ons in the process because the new API is either too limited to port the code or because the author simply does not have the resources available to rewrite a ton of code.
Thanks for implying I'm in it for the money without even knowing me. Nice ad hominem you got there.
Let's just say that the donations do not nearly cover the time I spend developing add-ons, helping other add-on developers out with their questions, volunteering on AMO, writing patches for core Firefox and so on.
This is wrong. It absolutely does not break XUL extensions per-se. Add-ons will require some (moderate for most add-ons) changes when accessing out-of-process web content. A lot of add-ons may not even require changes at all, because they either do not access web content directly in the first place, or the Cross-Process-Wrappers and shims mozilla already implemented will be enough (changes might be still wise to get away from a blocking wrapper-API to the async frame script API, but that matters only for perceived performance of the browser, not for security)
DownThemAll! for example does already support e10s in the Nightly builds since quite some time, NoScript supported e10s in the past, Greasemonkey spend 9 months to add e10s support (Anthony tells in a comment to the original blog post). GM is admittedly an add-on that required a lot of changes to make it work, but it does work now apparently.
Yeah, and the not-so-popular add-ons can screw themselves, I guess. Your add-on only has 10.000 users? 200 users? uhhh... Sorry, priorities.
Then again, actually look at the vimperator or pentadactyl code... That code interacts and/or hooks a ton of stuff. Designing and implementing APIs just to support that will require a lot of time. And that is just one add-on.
Furthermore, do you really believe that add-ons like vimperator or Tab Mix Plus or Stylish or SqliteManager would have been created if there was no "open API"? I don't think so.
Also, did you know that a lot of the Chrome extension API was created after directly soliciting feedback from Firefox add-on developers? Yet, a ton of add-ons still couldn't or just weren't supported in the Chrome API. And added to that, the Chrome API kinda stagnated after that.
I don't think I'm overly pessimistic. Apart from having been in the game since mozilla suite and having experienced a LOT of things that didn't turn out so well, to say the least and keep it polite and curse-word free...
The WebExtensions API is supposed to be an intentionally strictly defined API with a limited feature set; that just comes with the territory. It is supposed to give you access to a subset of Firefox features/internals. Compare that to the current extension "API": What Firefox can do, your add-on can do, and a lot of more things as well. You can customize Firefox to the point it really is a new browser (with thinks like Tab Mix Plus, Tree tabs, vimperator/pentadactyl) or just keep it (almost) vanilla, as you please. This is a major plus for users.
Sure, for a lot of things the extension team may add a WebExtensions API. But that is limited to what that team deems worthy of their time, deems "useful", and deems "safe". It is no longer up to the add-on developer to decide what they would like to develop, but up to the WebExtensions API gatekeeper team on what they want to allow and what they then prioritize and create the actual APIs.
Adding new APIs you may need will require you nag the team about it, though luck if you don't speak any language they understand, tough luck if they don't care or cannot care because their time is not infinite.
What makes me even more pessimistic is seeing the Jetpack/Add-on SDK after years of development and how it still only can address only the most basic use cases. The number of SDK-based add-ons, even relatively simple ones, that have to resort to 'require("chrome")' is staggeringly high. If the pace of the Add-on SDK and the stability its API is any indication... Time to look for another browser... Except there isn't any comparable to what Firefox still is right now.
And let's not forget: A change like this will break almost all existing add-ons in major ways. Many if not add-ons need to be rewritten in their entirety or at least in major chunks from scratch. Many add-ons will simply not make that huge investment in time required for that and simply die, without readily available replacements and leaving users behind scratching their heads.
That some of XUL has gone or was moved to HTML doesn't really matter much either. People could have adopted to this as well. Adopting to ongoing changes in Firefox was the bread-and-butter of extension development before WebExtensions (or the add-on SDK/jetpack), a necessary cost of doing business with the reward of very powerful things you could then do in and to the browser. With JetPack and the Addon SDK mozilla tried to provide stable APIs with some success. Adding WebExtensions to the mix would have helped, just to make it easier for Chrome extensions devs to port their stuff. People not in need of anything besides these stable APIs could use these and be done. People who needed more powerful capabilities would have went the other route and tracked Firefox changes, just like they used to for over a decade already anyway.
There were tons of major breaking changes over the years (Firefox 3.5 to 4 was particularly "bad" IIRC), and while those caused some causalities over the years with abandoned extensions not getting updated (tho most popular add-ons affected got new maintainers or were forked), most extensions kept going, adapting as needed.
I am pretty sure that I could pick up my "legacy" DownThemAll! code now and today, spend a month adopting it, and have a working version for Firefox 94+. A month may sound like a lot for some hobby project, but in an alternate reality where "legacy" add-ons still would be supported, I would have spent that month over a duration of the last 5 years.
But in this reality, I have no supported way to actually load such a "legacy" extension. I could add such a capability back to a Firefox fork, but then only I would be able to use it, but nobody else would... Unless I released the fork, and really, I don't have the resources to maintain an entire Firefox public fork.