
Why Did Mozilla Remove XUL Add-Ons? - est31
https://yoric.github.io/post/why-did-mozilla-remove-xul-addons/
======
newscracker
> I was very surprised to see that, years after it happened, some community
> members still felt hurt by this choice.

Actually, it shouldn’t be surprising at all since people lost a lot of useful
functionality that still do not have replacements today. _Users were not stuck
on XUL as a technology. They cared about functionality and power user
functionality!_

I’m using mainline Firefox and not some fork that still supports XUL addons,
but I still miss not having good replacements for:†

* Tab Mix Plus (I haven’t seen any replacement for this; and if you haven’t used this in the XUL world, you wouldn’t know the value of it)

* Lazarus (form saver)

* Session Manager (no, other session saving extensions still feel iffy to me)

For reasons I haven’t delved into, these extensions cannot live in a
WebExtensions world today. _So yes, I’m one of the people hurt by the choice
not of removing XUL, but not providing alternatives even several years later._

> The main drawback is, of course, that WebExtensions do not give add-on
> developers as much power as the promiscuous extension mechanism. I hope that
> all the power that add-on developers need can eventually be added to
> WebExtensions API but that’s something that takes engineering power, a
> critical resource that we’re sorely lacking.

I don’t have a lot of hope since years have passed with progress in making
some more addons work with WebExtentions but not really close to being there
for other addons. Though the Firefox team has said it’s currently not planning
to implement Manifest V3, if and when it does (and depending on how it does),
that could potentially make uBlock Origin obsolete. That would be a much
larger blow to the users.

†: Please let me know if you have suggestions for great replacements for the
first two extensions.

~~~
filmgirlcw
I'll agree this is all true for power users but I think that catering to that
small number of power users at the expense of having a faster, more stable,
more secure browser earlier was a major mistake.

I loved Tab Mix Plus too and yes, there are some things you still can’t do in
WebExtensions that you could do before. And that sucks. But I stopped using
Firefox despite those options because it was so slow and unstable, especially
on the Mac. By the time it got better, it was not only too late, but Chrome
had extensions.

Catering to the loyalists is what killed Firefox. What’s more important to
normal users is speed, not Tab Mix Plus.

~~~
arp242
Well, Firefox is far from dead, is it?

I guess the issue is a different view of what Firefox should be; I feel that
many people would be satisfied if Firefox was just a small(ish) browser
catering to power users. There's nothing wrong with that: power users are
users too (and there are more of them than many seem to think), and I feel
that many people are somewhat frustrated that _all_ software seems designed
with only my grandmother in mind. This is an issue that extends far beyond XUL
by the way.

~~~
kmeisthax
The original design goal of Firefox was to be a "90/10" browser (relative to
the old Mozilla suite). e.g. 90% of the people only need 10% of the features.
Catering to power users was never the goal of Firefox and they lost users to
Chrome when they did. What people want is a browser that loads webpages
quickly and doesn't use a lot of system resources doing so.

~~~
arp242
Well, Mozilla included email, chat, and whatnot. Regardless of what the goals
were, it _did_ cater to power users and clearly many people don't want the
direction Firefox went in.

~~~
Semaphor
> and clearly many people don't want the direction Firefox went in.

A majority? I doubt it. I think it’s an extremely vocal minority that don’t
care about the slowness of their browser (pre-e10s, pre-quantum), about things
breaking (XUL extensions) or about UI features for the broad masses.

I’d bet money that FF’s 25% in Germany would be far closer to US numbers if
they stayed where those vocal people want them.

~~~
arp242
I never said majority.

All I'm saying is that based on my observations people's views on what Firefox
should or should not be are different, and that this explains why people are
still "angry" about the extensions breaking and such. I'm not having an
argument with anyone.

------
kevincox
I don't care about XUL addons. What I cared about was addons with full access
to the browser. I understand that they wanted to move, and that addons would
break. But I would still _love_ to be able to list non-sandboxed extensions in
the store even if they came with a big warning "this extension will probably
break with every new version of Firefox". There is still functionality that
can't yet be replicated with WebExtensions.

For example I was maintaining VimFx as an unsigned extension for a while after
it wasn't allowed in the store. Sure, it broke often, but the fixes were
generally easy. However what really killed it was the lack of interest from
not being able to be listed in the store and not being able to run on stable
Firefox releases. If we could attract even a handful more maintainers I'm sure
we could have kept it mostly up to date.

To this day I can't get back some of the functionality that I lost. Firefox is
now just a different chrome. Sure, it is made by a different company, but the
user functionality is now almost identical. (Sure, Firefox has about:config,
but that is limited to what Mozilla imagined)

I'm really glad that Mozilla adopted WebExtensions. I think it is an amazing
solution for most extensions. Plus it is safer and cross-browser. However
there are a couple of extensions that need full access, and I wish that was
still an option, even if there is no stability guarantee.

~~~
xg15
Question: would it be possible to restore the missing functionality through a
companion process outside the browser?

Both Firefox and Chrome support the Native Messaging API [1] to communicate
with a process outside the browser.

This would still be absolutely less than ideal as the process would have to be
installed separately (I believe) and maintained separately for each platform -
but it would allow the extension to be listed again.

[1] [https://developer.mozilla.org/en-US/docs/Mozilla/Add-
ons/Web...](https://developer.mozilla.org/en-US/docs/Mozilla/Add-
ons/WebExtensions/Native_messaging)

~~~
kevincox
For some extensions, yes. But the problem isn't so much sandbox from a
security perspective, but the lack of access to Firefox internals.

For VimFx the primary problem is that it makes major changes to how input is
processed. It can't get the level of input access it needs from the
WebExtension APIs. You can see this in the WebExtension versions of similar
vim-style binding extensions, I've tried maybe a dozen and none of them work
as you would expect. It is common for inputs to be missed by the extension
depending on what part of the browser is focused at the moment.

------
dman
I had written multiple XUL based addons that I used for personal productivity.
When Firefox moved away from XUL/XPCom I think they removed not just an
implementation (which I admit had many warts) but also the alternate vision of
the Browser being extensible by end users who were almost on an equal footing
with Browser developers. As a developer I can live with, support and cheer for
a worse implementation of a better idea, but when you give up on that idea you
rob me of any reasons I could use to support or evangelise for you.

It boils down to a simple question - does Firefox intend to go after power
users in ways Chrome will not or cannot? The answer to this question used to
be very clear to me in the first decade, now I think the answer is no. Even
the Rust based oxidation efforts seemed limited to coming up with better
implementation of the same primitives that Chrome offers, I didnt see anything
about offering fundamentally different tradeoffs / choices.

If Firefox course corrects to going back to power users, I will be the first
one to cheer them on. The vision for firefox has to be to reduce the gap
between what browser developers can do and what end users can do.

~~~
danShumway
I think your comment is a much more salient criticism.

In many ways, webExtensions could be a more accessible system than XUL addons
if there was a serious effort to give the end-user more tools to use them. I
honestly really like the overall architecture of webExtensions, and I like the
idea of having more core code in modern Javascript. But there's a lot of
weirdness around the ecosystem itself that makes building extensions into a
chore.

There's a theoretical set of changes Firefox could make that would turn
webExtensions into an extremely accessible, powerful user-facing feature for
on-the-fly customizing and inspecting what their browser was doing. And I
don't _think_ it would need to be _that_ inherently less secure.

It would need to approach security differently, but I feel like many of these
are solvable problems, and many of the changes required (better sandboxing,
active tab permissions) are stuff we want for extensions today anyway.

Some of the changes that came out of dropping XUL are really good. A lot of
Firefox's styling is handled through CSS now. That should be a huge
accessibility win for new users, and it should provide a nice gateway for new
users to think more about moving on to making their own websites using the
same technology. Except... userChrome.css is hidden in a config directory
somewhere and not loaded by default[0]. They built a really nice way for users
to quickly add minor styling customizations, and then they hid it from end
users.

[0]: [https://www.userchrome.org/how-create-userchrome-
css.html](https://www.userchrome.org/how-create-userchrome-css.html)

~~~
dman
Sure - I can see that if we do arrive at a future where all of Firefox chrome
is implemented via a HTML/CSS itself and it sits on top of a standardized core
that exposes well documented APIs (which both end users and Firefox
developers) can use for feature development - then yes we will be back to the
world where someone outside Mozilla could build something like Komodo IDE on
top of Mozilla tech.

One question I have as a user - what is an acceptable grace period for coming
up with an equivalent replacement when you take an API away? Even the CSS
styling not being loaded by default that you pointed out suggests that Firefox
devs appear to view extensibility as something that they have to support
cautiously and grudgingly. There is a chicken and egg problem here - if you
make it harder to develop, build and ship non trivial extensions to end users
then only a tiny fraction of users will use them. Then you will use the lack
of usage of these extensibility features to deprioritize the development
efforts that go into them. I would really like someone to take on the task of
building a "Workstation" browser - built for power users.

~~~
danShumway
> There is a chicken and egg problem here - if you make it harder to develop,
> build and ship non trivial extensions to end users then only a tiny fraction
> of users will use them.

This is a really good point.

> what is an acceptable grace period for coming up with an equivalent
> replacement when you take an API away?

I really don't know.

I am frustrated with the current state of extensions in Firefox, even as I
acknowledge that the situation in Firefox is still way better than it is in
browsers like Chrome or Safari, and even as I remain hopeful that the Firefox
extension ecosystem _could_ be really good. I am sympathetic to the argument
that it's an engineering resources problem. But, that also makes me really
nervous about the Mozilla cuts that happened recently, because now how long
are we going to wait for Servo to be in a usable state, if it even ever gets
to a usable state?

Like you mention above, when you're forging a new trail in an underdeveloped
area and making a case that users would benefit from these features if the
ecosystem supported them enough and trained users to use them, you need some
freedom to be flexible and experimental and to waste some resources forging
that trail. And if resources are as scarce as Mozilla is claiming, then what
are the features that are going to be cut first? The experimental,
trailblazing ones, the weird ideas like, "shouldn't there be a section in the
Firefox options where users can just live-edit the CSS to the browser?".

~~~
dman
So I will concede that it is time to bury all the XUL/XPCom misgivings. We now
need to rededicate ourselves to the same extensible vision using the new
stack.

~~~
danShumway
I think we need some kind of champion to make that point -- to prove that the
extensible vision we _did have_ and lost is still worth pursuing.

But that's not really a useful thing for me to say, because I have no idea
where we can go to get that champion, and I'm at least low-key worried about
Mozilla's ability and willingness to be that champion.

But agreed. I think it's about more than just XUL vs webExtensions, I think
it's a broad tech/cultural issue about making the case that end-user-
accessible control and customization is important.

------
wtallis
This article really doesn't match my recollection of how things went down. It
implies that the switch to a multi-process model (Electrolysis/e10s) was held
up pending the switch to WebExtensions. But I'm pretty sure I remember a
transition period during which all my XUL-based extensions were either
rewritten to support multiprocess or deprecated, which was years before XUL
extensions were actually killed in favor of the less-capable WebExtensions.
The article talks about this like it's a path they rejected, even though I'm
pretty sure it actually happened. That transition was also a lot less painful
than the switch to WebExtensions: over a period of several browser releases, I
watched as the list of extensions preventing my browser from turning on the
multiprocess capability dwindled. All the most important and popular
extensions I was using made the switch smoothly with no major user-facing
changes in capability or UI, which is the exact opposite of how the
WebExtensions switch went.

It would really help if this article could use dates and/or version numbers to
establish the timeline of events it's talking about.

~~~
Yoric
(article author) Thanks for the feedback, I've just updated this part of the
article to clarify it. I don't remember exact dates, though, so I won't be
able to add them.

But yes, you are right, there was a time during which a number of old-style
extensions were ported to be compatible with e10s. It was possible for some,
impossible for others, hard when it was possible, and most add-on developers
didn't port them, either because it was too difficult or because they had
grown tired or the _maintenance tax_ I mention.

And yet, after they had ported their add-ons to be e10s-compatible, the add-
ons broke nevertheless, one by one, for all the reasons mentioned in the
article.

At some point, we threw the towel.

~~~
wtallis
> At some point, we threw the towel.

You threw in the towel before your most important extension developers did.
Well-maintained popular extensions like NoScript and TreeStyleTab remained
functional throughout the e10s transition with fixes delivered before the
breaking changes in Firefox made it to stable releases, but they were
irreparably harmed by the WebExtension transition. Their WebExtension versions
are _still_ not up to feature parity, despite ongoing maintenance.

It's quite obvious that the WebExtension model is better for users and
developers of _simple_ extensions. But it continues to not be an adequate
substitute for the kind of extensions that gave Firefox real advantages over
Chrome and other browsers. It's not at all apparent why those advanced, killer
app extensions had to die in order to get the bulk of the extension ecosystem
moved over to WebExtensions.

~~~
Yoric
The author of NoScript was part of way more meetings than me during the design
of the WebExtensions API, so he would probably be able to tell you more about
what happened to his add-on.

I see a TreeStyleTab on AMO, so I guess it got ported:
[https://addons.mozilla.org/en-US/firefox/addon/tree-style-
ta...](https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/) . It
may have been harmed by the progressive disappearance of XUL, of course.

------
jiripospisil
An alternative explanation about why XUL extensions needed to go by a Firefox
dev Mike Conley [0], drawing pretty much the same conclusions and then some.

The same thing that happened to Firefox happened to Babel [1]. Babel's plugin
API exposes the internal structures and APIs to plugins, which means they're
unrestricted in what they can do, but it also means that it's very hard to
change things in the codebase because you might accidentally break plugins
that rely on the previous behavior / APIs. This is one of the primary
motivations behind Rome [2].

[0]
[https://www.youtube.com/watch?time_continue=4542&v=6D6idUjkv...](https://www.youtube.com/watch?time_continue=4542&v=6D6idUjkvqk)

[1] [https://babeljs.io](https://babeljs.io)

[2] [https://romefrontend.dev/blog/2020/08/08/introducing-
rome.ht...](https://romefrontend.dev/blog/2020/08/08/introducing-rome.html)

~~~
dayjobpork
I'd like to live in a world were instead of developers just breaking an
existing api, they leave the existing, in use apis and add new ones. It's
ridiculous how often shit just breaks because an api is changed in an update.

~~~
hapless
That approach is what made XUL and XPCOM un-maintainable -- a giant catalog of
APIs in which large fractions were legacy, but non-removeable.

------
jd3
While I understand from a technical and business perspective (particularly due
to the security implications of needing to manually review each and every new
addon) why Mozilla eventually went down the WebExtensions route, having
personally revived the old XUL/XPCOM "MessageFaces" addon (a Plan9/unix era
vismon/faces knockoff for Thunderbird/SeaMonkey) from 2004 when I was in
college in ~2016, I was devastated to hear that Mozilla was removing support
for XUL/XPCOM and the Add-on SDK from Firefox.

Nothing that the extension achieved is even remotely possible anymore — adding
custom column in mailbox Thunderbird XUL, custom icon vbox in the Thunderbird
mail header, reading from a browser profile directory to display picons,
windowed preferences, etc. I find this sad.

[https://github.com/JohnDDuncanIII/messagefaces/](https://github.com/JohnDDuncanIII/messagefaces/)

[http://cs.gettysburg.edu/~duncjo01/sites/messagefaces/](http://cs.gettysburg.edu/~duncjo01/sites/messagefaces/)

[https://kinzler.com/picons/ftp/](https://kinzler.com/picons/ftp/)

What's most sad to me is that my workflow was never quite the same after I
stopped using SeaMonkey with many of the famous XUL-based extensions (Old
Addons Page, Chatzilla, MessageFaces, etc.) — it was aesthetic bliss,
particularly with the Orthodox (Netscape/Mozilla Suite) complete theme.

I've ranted about this in the past, but I still feel like XUL was a bit ahead
of its time (see Facebook's JSX). Had Mozilla invested more development time
in fleshing out the XULRunner APIs and marketing it as a universal platform-
independent "native" UI language, perhaps the modern web ecosystem would look
a bit different today.

I fear that the web today is slowly converging, aesthetically speaking,
through the further limitation of site interfaces and UI, into a corporatized
unary devoid of any creativity/novelty.

~~~
narag
_I still feel like XUL was a bit ahead of its time_

But you said that you understand that from a technical perspective they had to
replace it. That sounds more like a dead end than ahead of its time, unless
there's something more?

IMHO, it was the wrong solution for a number of problems. Most of them don't
exist anymore.

~~~
jd3
Sorry, i should have clarified — i feel like XUL, at a very early stage in the
web's development, helped inform what advanced / platform independent
interfaces might eventually look like (Facebook JSX -> React -> React Native,
svgs, dom parsing, etc).

In recent years, particularly through the proliferation of things like JSX,
javascript with XML-based extensions seems to be quickly becoming (for better
or for worse) the dominant interface rendering paradigm.

I agree that XUL was, ultimately, probably the wrong solution due to a number
of reasons, but its effects are definitely still somewhat visible in the
ecosystem today.

What i'm still trying to figure out is how we recapture the freedom and
aesthetic creativity that thrived during the early years of the web. We can
argue that this was mostly a cultural/demographic shift in users, but I would
also argue that, as McLuhan noted, shifting interfaces (particularly through a
uniformity of aesthetics) can influence culture.

~~~
narag
I see what you mean. Maybe some new app with a feature of creating something.
Lately most novelty is in the consumer side.

------
AlexandrB
From an engineering point of view, it's understandable that XUL add-ons had to
go - this article lays out the case very well. But from a product point of
view, Firefox lost its "killer app". Now the choice to use Firefox over Chrome
is mostly an ethical one. That's a tough sell for most people, and it
certainly won't get someone who's never used Firefox excited to try it.

Chrome may soon give Firefox a little win here by nerfing uBlock Origin, but
is that enough?

~~~
The_Colonel
> But from a product point of view, Firefox lost its "killer app".

For most of (former/present) Firefox users extensibility wasn't the "killer
app".

FF gained its marketshare at the time because IE was so crappy on most metrics
and that was the main competition.

~~~
anoncake
Not being IE doesn't help much when the competition is Chrome.

~~~
The_Colonel
Yes, chrome was for a long time simply better browser (mostly because it was
much faster/responsive).

But as the article explains, this was largely caused by the need to provide
extensive backwards compatibility which stifled innovation or completely
prevented it (in case of multi-process architecture).

------
InfiniteRand
I understand the reasoning behind why XUL and XPCOM had to go, but I learned
about this technology when I was in college, just starting to become really
passionate about technology, and Mozilla sold these things as "important"
ideas, technological paradigms that were not just the best way forward but
would make the world a better place by making development easier, exposing
more things to power users, allowing better sharing of common components, etc.

Except in the end these were not the best way forward (well, at least for now,
old technological paradigms do come back periodically, making the whole idea
of an obvious unified "best way forward" questionable), and so Mozilla had to
ditch them, and I understand that.

But that means when Mozilla is preaching that WebAsm or Rust or whatever is a
truly revolutionary technology that will save the world, well, I don't ignore
Mozilla, I just don't trust in their technological foresight like I used to.

In the bigger scheme of things, I tend to be more skeptical that programming
paradigms like this really are revolutionary in general. Programming paradigms
are interesting ideas, but I no longer see them as some forward march of
progress that is paving the way to a golden age of technology.

I feel a little silly that I once thought this way, and a little silly for
once being as passionate as I was for Mozilla.

~~~
jonchang
I think you're confusing the implementation with the idea. XUL wasn't the
right path forward for bringing web technologies into the desktop as we can
see with the failure of XULRunner but a ton of apps are written today with
Electron and HTML5. E4X was an interesting idea bringing XML into Javascript
as native objects, but the ultimate implementation lives on as JSX with React.

~~~
sfink
As someone who had to maintain E4X within SpiderMonkey: sadly, that's another
great example of the wrong technological path. JavaScript is too dynamic, it
gives you too much rope to hang yourself, and E4X was apparently not designed
with that in mind. It was _so_ nice when we removed E4X and didn't have to
worry about `x` being an object during a lookup `obj[x]`.

To give an example of the flavor of issue: when building an array (even from a
literal), you couldn't push a series of values to the stack and then construct
an array out of them, because with E4X between elements 2 and 3 you might end
up invoking arbitrary code with access to the array so that it establishes a
setter on element 4 and adds a `valueOf` hook to what you're passing as
element 5, but oh wait that's the same object you already inserted as element
0, and anyway the array might be frozen now and... (I'm making this up; I know
the issues were similar to this but I probably don't have the details quite
right.)

E4X was a rich, rich source of security bugs. I'm sure a simplified form of it
is possible and would be quite cool, but that niche is already filled now with
JSX for better or worse.

------
filmgirlcw
This is a great article but it saddens me that it had to be written because
all these years later, community members are still mad their extensions don’t
work.

I guess I’ve underestimated all these years that what David described as the
problems with XUL and the reasons it had to go away weren’t commonly
understood. As the post states, it was clear as far back as 2010 (and honestly
earlier), that XUL extensions were both Firefox's killer feature and also the
reason that it got its ass kicked by Chrome (and to a lesser-extent, Safari).
Extensions were amazing but the tax it created for performance, development,
and security ended up becoming what made the browser so slow. Chrome and
Safari didn’t have extensions but they had speed and built-in features that
replicated many of the most popular extensions. And once Chrome added
extensions support — and support that didn’t require that add-on development
tax — it was over.

I found this bit of the post really telling:

> And yet, there was no choice for Mozilla. Every day that Mozilla didn’t ship
> Electrolysis was one day that Chrome was simply better in terms of
> architecture, safety and security. Unfortunately, Mozilla delayed
> Electrolysis by years, in part because of the illusion that the Firefox
> benchmarks were better enough that it wouldn’t matter for a long time, in
> part because we decided to test-drive Electrolysis with FirefoxOS before
> Firefox itself, but mostly because we did not want to lose all these add-
> ons.

>In the end, Mozilla decided to introduce WebExtensions and finally make the
jump towards e10s as part of the Quantum Project. We had lost years of
development that we would never recover.

This aligns with what has always been my personal view which is that Mozilla
waited too long to make the changes it needed to compete with Chrome and by
the time it finally did the hard thing and lose extensions and start over.

When you consider that there was still time after Chrome was released but
before Quantum where IE had the largest browser share (it wasn’t a long period
of time post-Chrome, but it existed), that’s indicates to me that there was
time both before and after Chrome's introduction for Mozilla to rip the band-
aid off and drop XUL for the greater good of the browser. After all, IE didn’t
have extensions in any comprehensive way, which could have given Firefox to
refactor and approach. Sadly, Mozilla waited too long.

But what really makes me sad is that there are still diehards mad that XUL
died. When to me, we should all be angrier that it was allowed to live as long
as it did.

~~~
panny
>Firefox's killer feature and also the reason that it got its ass kicked by
Chrome

5% faster page load still isn't a killer feature.

>Extensions were amazing

And the reason everyone who left used the browser.

>lose extensions and start over.

A smart company would never have done this. They would have maintained both to
see if anyone would use the new browser. Instead, they took their customers on
a forced march down a trail of tears.

Imagine if another company tried this. Imagine if Tesla said, "We know you
love electric cars. So today we're going to stop making them and sell hydrogen
powered motorcycles instead. They're faster! Sorry, we won't be making parts
for or supporting the cars anymore." It would be corporate suicide. Imagine
how angry the car owners would be, after they invested in the idea and the
charging equipment, only to be abandoned by the company.

It makes perfect sense to continue shipping the old product in the face of a
"new better" one. Apple continued selling iPods long after the iPhone arrived.
Killing the successful core product and releasing a new untested competing
product is an insane gamble. I can't see how Mozilla leadership ever thought
that was a good idea.

~~~
gvjddbnvdrbv
At least in your analogy no one comes to your garage and replaces your car
with a bike....

------
Animats
Over many years, I had to port an addon from Greasemonkey to XUL to Jetpack to
WebExtensions. The number of add-on users steadily dropped as the number of
Firefox users dropped.

Now, if you write a Firefox extension, and it's not a Mozilla-recommended
extension (something you have to beg for) anyone installing it gets a scary
notice:

 _" This is not monitored for security through Mozilla's Recommended
Extensions program. Make sure you trust it before installing."_

This is _after_ going through Mozila's approval and signing process. Unsigned
extensions won't install at all in the release version of Firefox.

Firefox extensions aren't something worth working on any more.

~~~
JanisL
> Firefox extensions aren't something worth working on any more.

Unfortunately I now totally share this sentiment, I had an extension that
delayed page loads in a realistic way to test slower connections. I started on
back when XUL was the way to do it but dealing with the churn led me to give
up. When XUL was being deprecated I ported to the newer way but I could tell
that the churn was starting to get annoying and that my enthusiasm had
changed. As much as I would have liked to continue work with that extension
with the recent changes I'm glad I gave up when I did.

I'd really like to see something change to make working on extensions feel
like it's more worthwhile again. Do people think that things are likely to
stabilize in the next few years?

~~~
dralley
The entire point of switching to WebExtensions was that things could be
stabilized permanently.

------
Santosh83
Let's be clear on one thing that seems to be perpetually discussed whenever
there is a Firefox thread: what has lead to its declining usage.

It is _not_ removing XUL 'power' extensions and replacing them with 'neutered'
WebExtensions mechanism.

It is _not_ choosing to closely align with Chrome in terms of UI/UX and
functionality.

It is _not_ the letting go of Brendan Eich and the newer (much criticised)
management.

It is _not_ because of Mozilla foundation highlighting a few 'social justice'
issues here and there.

The decline of Firefox is because of _one thing only_ \- the enormous
marketing and engineering clout of Google and their utterly ruthless,
relentless, anti-competitive pushing of Chrome across Android and all their
web properties and even through ads all over the world.

More specifically, it is their _bundling_ of Chrome as the default, preset
browser on the world most popular mobile operating system that really swung
the tide decisively in their favour. Once ordinary users got used to Chrome on
Android, they would naturally seek out the same browser on their laptops and
desktops, to minimise interoperability issues and maximise familiarity.

And while pre-installing Chrome on Android (and by the way, it is pre-
installed even on most laptop/desktop purchases by "helpful" OEMs - such is
its viral reach) may not be strictly illegal as per anti-monopoly laws
(because alternatives are 'freely' available on the default app store), the
fact remains that if a program that comes with the OS is "good enough", the
very vast majority of users will not bothering changing it, and thus Google
managed to cripple all other browsers while still subtly side-stepping any
potential lawsuits.

So the decline of Firefox is in my opinion a social/political phenomenon and
nothing to do with its technical competence or extendibility vis-a-vis Chrome.
It is certainly a more than competent drop-in replacement for Chrome (unlike
say w3m or NetSurf), but _who_ will bother to do the replacement in the first
place, as long as Chrome continues to be "good enough" (which is does
excellently) and it doesn't outrageously hurt the user base by some
extraordinarily shocking screw-up (and Facebook shows, even such odious abuse
will be condoned by the user base by and large when the network effects are
too big).

~~~
lenkite
My friends and I stopped using Firefox after they broke our favourite XUL
extensions. So did my parents. So did many, many developers I knew.

Everyone moved to using Chrome and never went back. Breaking XUL dropped
Firefox adoption _considerably_. But folks who did this don't want to accept
it.

XUL extensions gave Firefox unique power which it lost and never regained
back. Firefox chopped off its powerful , special tentacles and grew flimsy,
poor hands back. Firefox defanged itself.

~~~
The_Colonel
Your favorite XUL extension broke so you "solved" that by migrating to a
completely different browser which also doesn't provide the desired
functionality.

Something doesn't add up.

~~~
lenkite
At the time, Chrome had Chrome Apps. If you recall, several XUL extension
authors quit in disgust and started developing chrome apps. Google wasn't
considered 'evil' at the time...

Firefox had a unique, special power which differentiated it and Mozilla chose
to kill it. No wonder its browser share dropped like a stone.

~~~
The_Colonel
Chrome Apps were in no way replacement for XUL. They could not change the
behavior of the Chrome itself, they just opened their own window and did their
thing there. Not really an extension, more of a separate app.

To talk on more specific terms, which XUL extension did you replace with
Chrome App?

~~~
lenkite
I finally ended up using alternate tools since _even_ the replacement Chrome
Apps were pale imitations of what Firefox offered. The good ones needed to use
Nacl just to do basic stuff and still couldn't reach what XUL extensions
natively supported.

But I changed my browser to Chrome since Firefox lost its value proposition.
It had a differentiating factor of superior experience and features that it
chose to deliberately abandon.

------
hoseja
This feels analogous to videogame modding. You either let/don't prevent the
modders from messing with the very core of the game, which brings total
overhaulability but also total vulnerability and jankiness; or you give them a
nice modding API that, depending on how much effort you put into it might be
rather powerful, safe and and convenient but IMO is fundamentally crippled in
comparison to the former approach, it's as if you have to imagine all the ways
people might want to mod your game beforehand.

Also, I have this bad taste in my mouth from Mozilla getting all that Google
money just hours after sacking their developers, like it was a condition.

~~~
anoncake
Third option: You give them a nice modding API and let them access the core of
the game. That way you gain the benefits of a modding API without restricting
modders' creativity.

~~~
sgift
Only a third option if you don't care about all the problems the article tells
us about. Full access by third party developers and being able to update code
are simply at odds with each other. There's no way around it.

~~~
anoncake
That is simply not true.

~~~
Yoric
How so?

~~~
anoncake
Allowing addon developers to access private APIs simply doesn't prevent
Mozilla from changing them, or anything else. An unstable API is much better
than none at all.

------
roca
It's a good article, but in my experience explaining this stuff over and over
again in HN and other fora, people don't actually want to know. They have
their narrative and they're sticking to it.

~~~
zeveb
My issue is simply that I _want_ an extension mechanism which _I_ can use to
do anything to my browser. For me, 'extension security' means 'I must write
C++ to add the functionality I want,' and I never, never want to write C++.

~~~
sudosysgen
What prevents you from writing a patch for Firefox then? After all, it is one
of the great advantages of FOSS. At this level of power you'd likely have to
change the addon every upgrade anyways.

~~~
smegger001
because what you are purposing is fork a browser which is only slightly less
complicated than fork operating system and involves a major investment in
time/money to maintain.

~~~
newscracker
To whatever extent, there have been forks that are still alive today that
support XUL extensions. Pale Moon [1] is one of them.

[1]: [https://www.palemoon.org/](https://www.palemoon.org/)

------
moltar
I was pissed off and left Firefox for Chrome not because they removed XUL add
one, but because they didn’t have a good replacement.

Chrome extensions are ugly and have no unified design. They are glorified web
pages in a floating window.

I liked XUL because it provided a framework for extension authors and
extensions felt like part of Firefox.

I eventually returned to Firefox and I find the extensions to be not so
terrible.

------
rayshan
This may be an unpopular opinion: I'm very grateful for all browsers to switch
to WebExtensions. To me, for the web to win as a platform, standards are a
must.

I'm a new WebExtension indie dev. I just launched my first extension on the
Chrome, Firefox, Edge stores. Opera is in review. Safari 14 took 15 minutes
and 1 commend, just waiting for it to drop. I couldn't have shipped this
quickly by myself if not for the WebExtensions standard. It leaves me time to
focus on building what users want and telling users about what I built. Yes I
did have to settle for less developer power and control. I'm totally ok with
it.

Feel free to AMA!

[0]
[https://twitter.com/rayshan/status/1292270249362956288](https://twitter.com/rayshan/status/1292270249362956288)

~~~
0xffff2
>To me, for the web to win as a platform, standards are a must.

What does that mean exactly? What are the other platforms that the web is
competing against?

~~~
ebruchez
iOS and Android native apps with their walled gardens.

~~~
0xffff2
Hmm. As a crotchety old man (well, I'm 32, but still), I hadn't even
considered mobile. I was thinking Windows/macOS/Linux native apps as the
probable alternatives.

In either case though, I think this is just one more reason to hate Web
Extensions. I don't want browsers to win over native applications. (Of course
"applications" that are little more than a bundled browser are even worse,
whether on mobile or desktop.)

~~~
rayshan
@ebruchez is right. Also by win, I really mean to compete head-to-head with
the native platforms. I love a good native app as much as anyone. The recent
Epic vs. Apple fight shows that we need more open alternatives like the web
platform. Ones that are free to develop for and free to distribute. I'm
looking at you Apple, charging me $99 for a developer account just to
distribute a Safari 14 web extension in the app store.

------
BoppreH
Funny seeing this here, I just switched to Vivaldi yesterday because of this.

I really wanted to use mouse gestures and Vim-like controls again, and the
WebExtension version of those addons is not nearly reliable enough.

The problem seems to be that those control extensions can only work by
injecting Javascript into webpages, which (1) takes a moment to work when the
page is loading, and (2) doesn't work in New Tab page. The effect is that even
basic shortcuts like "next tab" fail to work often enough that I'm willing to
switch browsers.

------
giovannibajo1
Thanks for the article, it provides very good insights.

In the article, there are a couple of passes that mention “benchmarks” where
Firefox was faster than Chrome. It sounds like those benchmarks, albeit I
assume they were correct, were actually providing a distorted reality of what
“fast” actually means, because I distinctly remember people (including myself)
switching to Chrome in early days because it was simply objectively faster. It
sounds like the existence of those benchmarks have had a net negative on
Firefox: it provided a false confidence that the browser was “fast”, and
possibly delayed the refactorings that eventually managed to really speed up
Firefox again.

You mention that Chrome used “UX tricks” but I assume what this means is that
Chrome developers were actually driven by more correct benchmarks: the ones
that actually translate to a better experience for the end user.

Since I’m always intrigued by the topic of false benchmarking and how complex
it is to do correct benchmarks that don’t fall into traps, I’d love to hear
what those benchmarks you mention were measuring, and if you agree that they
gave a false assurance to the Firefox team.

~~~
Yoric
To summarize, we were benchmarking for throughput: how long between the time
you click and the time the operation terminates. For a long time, we
absolutely crushed Chrome on most of these benchmarks. Firefox started faster,
loaded pages faster, switched between tabs faster, JavaScript executed faster,
downloads were faster, ...

Chrome developers were benchmarking for responsiveness: how long between the
time you click and the user interface shows that something is going on. And
that's all that end users actually see. Chrome showed its initial window
faster (although it took more time until you could actually do anything with
it), was slower at loading pages (but stopped its throbber earlier), slower at
switching tabs (but the screen changed faster to show you that it was
switching tabs), ...

Which ones were the "correct benchmarks" remains an open question, but it's
clear which ones the users perceive/remember as being faster!

Of course, the better architecture that Chrome used meant that they eventually
got faster at throughput, too, on computers that had sufficient RAM.

------
thinkingemote
We were told why they had to remove these extensions when they did so.

they also said that they would replace the APIs soon.

That they (still) haven't replaced them is why we are still angry with them. A
failed promise.

We don't need to know why they made this change, we need to know when their
promises will be kept.

------
_pdp_
My company and I have no interest in supporting Firefox in the future and yes,
I still feel betrayed when they dropped XUL. Many people did.

Even with WebExtensions, the Firefox extension review process is substantially
lacking compared to the kind of developer experience I get with Chrome. The
exact same extension takes a few seconds to release on the Chrome Webstore,
vs. the laborious process I have to get through when releasing on Firefox.

The last straw for me was when the Firefox Extension reviewers asked me to
provide a full-size package so that they can compile the extension themselves
to compare if it matches the one that is submitted and if the output differs
by some characters due to, let's say the order of the keys in a dictionary,
though, it gets rejected. It does not matter if you have been supporting this
extension for many years. It does not even matter if you are shipping the same
code to Chrome and Firefox as well.

For companies that develop desktop-grade applications using web technologies,
the only natural choice is Electron. It is stupid, for sure, because it forces
developers to ship large binaries but what are the alternatives. QT? GTK?
Please. The most popular non-native desktop applications are either based on
Electron, Java, or some custom UI framework.

XUL had the chance to be the better cross-platform UI, and it was for some
time until it was killed and with that, it lost an unmeasurable amount of
developer time and future loss of productivity and a chance to be an actual
alternative rather than a copycat.

As many others already pointed out, Firefox is Chrome, except that Chrome is
still faster.

The demise of Firefox will hurt many at a personal level but frankly, it will
hardly have any effect on the world because at the end of the day,
WebExtensions are portable and Chrome is the pioneer in this space.

~~~
aftergibson
That might be very frustrating as a developer, but considering the amount of
malware distributed on the Chrome Webstore this review process makes me want
to use Firefox more.

~~~
_pdp_
I work in Security. This process produces no substantial results. They should
invest into automation not some ill thought manual review process. This is
part of the reasons why the Firefox extensions store is in decline. It is
enough to look into the numbers to get the full picture.

~~~
Yoric
In my experience, automating JavaScript analysis is a pipe dream. _Maybe_ this
could work if Mozilla forced add-ons to use TypeScript, but I feel that add-on
developers wouldn't enjoy being asked to switch.

------
phendrenad2
A great read. However, this part remains unfulfilled:

> we still haven’t taken the time to explain in-depth why we had _no choice_
> but to remove XUL-based add-ons.

I'm still waiting for an acceptable explanation. The author basically says
"XUL was too vulnerable to security problems and crashes" but why couldn't it
be left in? I think the real answer is a mix of "We don't have the developer
resources (despite millions in revenue every year) to work on it, those
resources are going to develop stuff like Pocket" and "We know better than the
users, and the bug reports are tiresome, so let's lock it down and disallow
people from using XUL addons"

This all happened due to pressure to compete with Chrome, but I think in doing
so, Firefox lost it's uniqueness and became just another Chrome follower
rather than a contender for web leadership.

~~~
Yoric
> The author basically says "XUL was too vulnerable to security problems and
> crashes" but why couldn't it be left in?

There's an entire section called "The problems with XUL" that attempts to
respond to this question (and another one called "The problems with XPCOM").
Do you feel anything is missing in either section?

------
gwbas1c
As a developer, APIs changing and going away is a part of life. Apple
deprecates APIs on macOS and iOS all the time. Even the concept of porting
from an older to a newer OS is quite common.

Everyone rewrote DOS applications for Windows 3.x, then Windows 95, then
Windows NT; Everyone rewrote applications for Apple II, MacOS classic, then
OSX.

But, when I read this article, it exposes a clear need for powerful 3rd party
browser APIs; even though the API may change between browser releases. (This,
BTW, is what happens on Mac. If you develop a MacOS application, every year or
so you need to tweak it.) Also, there's a clear need to install 3rd party
plugins that can do things to screw up the browser. (This, BTW, is why desktop
computers let you install whatever you want, and why you can sideload on
Android.)

------
kwoff
XUL in my memory is a kind of tragedy. It seemed to me to represent a future
where GUIs could be programmed on any platform using an HTML-like language.
Previously you had to individually write GUIs as applications, using languages
like C++ or Java. Then web applications became more popular, and XUL seemed
like it could sort of unify all the special applications some day. By roughly
2010, I think HTML5 was taking away some of the appeal of XUL, and at the same
time the increase in popularity of smartphones led to a reversion to
specially-built "apps". I hope some day there will be a popular "browser app"
that everyone builds apps on.

~~~
Yoric
Mozilla made the conscious decision of supporting open standards, which meant
pushing for and contributing to HTML5 instead of extending XUL.

But yeah, there's still nothing quite as powerful as XUL.

------
orange8
> One of the topics that came back a few times was the removal of XUL-based
> add-ons during the move to Firefox Quantum. I was very surprised to see
> that, years after it happened, some community members still felt hurt by
> this choice.

Know your users. If I wanted to use chrome, I'd have used it. What made
Firefox Firefox was its powerful addon eco-system. Now its just a poor chrome
imitation.

------
wejick
When this kind of topic comes up, people are starting to talk about X things
then at the end they say:

1\. That's why I'm using/stopping using Firefox a while ago

2\. I hope Firefox can be hanging in there, but I don't want to touch it

3\. Oh look that's cool new project is awesomen, but I'm sticking with Chrome

It's just interesting to see

~~~
Karunamon
1 is understandable all on its own.

2 can be explained by a feeling of betrayal. Mozilla's target user isn't me
anymore, and quite frankly isn't most of the HN readership either. At least
Chrome is the devil I know. Chrome's privacy "issues" are well known and
documented, and are fairly trivially worked around. I'm not too worried about
them claiming to be for privacy and then one day silently installing an addon
that invades it. And that's not even getting into the addon mess. Or the other
addon mess, where their nannying resulted in the _worldwide_ breakage of _all_
addons for _all_ Firefox users.

3 can be explained for similar reasons as 2. I know where I stand with Chrome,
and I already got more-or-less forcibly kicked out of the Firefox camp.
There's a level of certainty here that doesn't exist with FF or whatever the
new upstart browser is - I don't have this nagging fear that Google is going
to do something with Chrome to make it more annoying or less useful. That is a
very real fear I have with Firefox, and it's one that's been borne out
repeatedly ever since addongate. If there's a choice between an option which
gives the user more control and and option which gives the user less or takes
some away, Mozilla usually picks the latter.

------
simula67
Not trying to armchair quarterback here, just speculating for entertainment

> Around this time, Mozilla started paying serious attention to Chrome. Chrome
> had started with very different design guidelines than Firefox:

> * at the time, Chrome didn’t care about eating too much memory or system
> resources;

> * Chrome used many processes, which gave this browser heightened security
> and responsiveness by design;

> * Chrome had started without an add-on API, which meant that Chrome
> developers could get away with refactoring anything they wanted, without
> this development tax; as Chrome introduced their extension mechanism, they
> did it with a proper API, which could usually be maintained regardless of
> changes to the back-end;

Was it possible to do this inside Mozilla? Release a new browser with
different branding that does not have these handicaps. Then, let the
marketplace decide which browser to pick. If it won out, announce publicly
that ongoing investment would be on the new browser.

~~~
jonchang
This sounds like a pretty bad financial and strategic plan. So you suggest
that Mozilla should have concurrently developed two browser engines, doubling
the cost of its engineering while also competing with itself?

~~~
throwanem
Like what they did with Servo?

~~~
jonchang
Servo was always a research project, and not a full browser replacement
intended to compete with Firefox. As the article states, many components of
Servo eventually ended up in Firefox.

------
lemoncucumber
There is no XUL, only Dana.

------
fouc
> And then, as someone pointed out on reddit, I realized that we still haven’t
> taken the time to explain in-depth why we had no choice but to remove XUL-
> based add-ons.

> * very quickly, add-on developers realized that anything they did could
> break anything else in the system, including other add-ons and Firefox
> itself, and they often had no way to prevent this;

> * similarly, anything Firefox developers did could break add-ons, and they
> often had no way to prevent this;

> * also, some of the changes that Firefox needed to remain competitive with
> Chrome were going to break most add-ons immediately, possibly all add-ons in
> the longer term;

> * oh, and by the way, since add-ons could do everything, they could very
> easily do anything to the operating system, from stealing passwords to
> pretending to be your bank.

\---

It's a really long article with lots of background and technical detail, so I
felt it safe to include a larger summary of the basic points than I normally
would.

~~~
jolmg
>> * also, some of the changes that Firefox needed to remain competitive with
Chrome were going to break most add-ons immediately, possibly all add-ons in
the longer term;

This is probably the most important point. The other points apply to almost
any software that supports addons, including emacs, vim, zsh, etc. and they're
not really an issue.

>> * very quickly, add-on developers realized that anything they did could
break anything else in the system, including other add-ons and Firefox itself,
and they often had no way to prevent this;

So they're careful. Any add-on that breaks other stuff doesn't really get
adopted. Emacs shares the same namespace for everything. Addon developers just
namespace their stuff by putting a prefix on their identifiers. It's not
really an issue even for them.

>> * similarly, anything Firefox developers did could break add-ons, and they
often had no way to prevent this;

So don't change Firefox so drastically. Well, I'd say it's nice for software
to be stable, but web browsers are a good exception to that. If Firefox didn't
try to keep up with Chrome, Chrome would probably have greater dominance.

But yeah, other software would just be more stable. When a change needs to be
made, the benefit is weighed against the potential of breaking addons, but I
imagine that's probably OK with addon developers as long as the change was
reasonable.

>> * oh, and by the way, since add-ons could do everything, they could very
easily do anything to the operating system, from stealing passwords to
pretending to be your bank.

Most times, addons are almost like any other program, and should be judged
accordingly before installing. I imagine even after the restrictions were
placed on addons, they're probably still capable of quite a bit of malice.

~~~
danShumway
> Emacs shares the same namespace for everything. Addon developers just
> namespace their stuff by putting a prefix on their identifiers. It's not
> really an issue even for them.

I use and love Emacs (Spacemacs), and I am probably never going to move to
another editor.

BUT as someone who maintains a Spacemacs config, no, Emacs addons break each
other all the time. It's not just a namespacing problem, it's which events
you're hooking around or interrupting, it's which system features you're
changing that other addons rely on.

This kind of organized chaos works out OK in Emacs because I can read the
source code of the offending Spacemacs layer or script and wrap around it to
get it playing nicely with the rest of my setup. Emacs has very good debugging
tools built into it, and you can hack on the editor _in the editor_. It also
has a fairly decent community of people online who will help you debug configs
as long as you're not being too annoying about it. This all ends up being
pretty important, because you are going to need to debug configs.

Emacs expects you to be a power user that knows how to program, and if you are
a power user that knows how to program, there are advantages to that. But even
with those advantages, the sheer amount of time I've wasted getting EXWM to
play nicely with other workspace addons...

I just think there's benefits and tradeoffs to both approaches, and I wouldn't
be so quick to dismiss the engineers who decided that their users shouldn't
need to learn how to program to keep a functioning set of addons running in
their web browser.

~~~
Reelin
My question is then: where's the hackabale power user browser implemented in
something like Common Lisp with a REPL, hot swap debugging, and built in
disassembly tools?

~~~
ChrisSD
To be honest I'm surprised Emacs isn't a browser yet. It does everything else.

~~~
throwaway_pdp09
It has a browser, eww
([https://www.gnu.org/software/emacs/manual/html_mono/eww.html](https://www.gnu.org/software/emacs/manual/html_mono/eww.html)),
and I think others.

eww doesn't work very well yet. Try it for fun only. And it's slow. Pretty
certain it does cookies but not js.

I think there's an emacs web browser which delegates the actual mechanics to
something external, and only acts as a front end for display/interaction.
Never tried it.

~~~
ravar
I would love to know about this mythical browser, the web is one of the last
things i don't have in emacs. I would dearly love to fix this.

~~~
throwaway_pdp09
[https://html.duckduckgo.com/html?q=emacs%20%22web%20browsers...](https://html.duckduckgo.com/html?q=emacs%20%22web%20browsers%22)
get you
[https://www.emacswiki.org/emacs/CategoryWebBrowser](https://www.emacswiki.org/emacs/CategoryWebBrowser)
as the top link.

In the latter EAF isn't a web browser despite what it says. Have a look at the
others. Piggyback browsers aren't going to be sophisticated, that's just how
it is.

------
gcb0
> addons can change things and break the browser.

Good. That's a feature. I _install_ addons. It's not a site i visit with no
consideration.

This is the same thinking of apple. People install random apps so let's
restrict apps to the point the user cannot have a text editor on their phone!
meh! This is all dumb!

Now it is impossible to have the choice to install an addon for tweaking
hidden options. Everyone should live with the crap that is about:config and
user.js (or only about:config, because they thought user.js too dangerous on
mobile too!)

I trust an open source browser by random people, why not an open source addon
that gives me the functionality i _need_?

~~~
Yoric
Did you read the rest of the article?

That was not a summary of why the old model could not be kept, just of why it
was promiscuous.

------
superkuh
Browsers that split off because of the killing of XUL and establishment of the
Firefox walled garden continue to operate using XUL and the giant (and still
improving) ecosystem of add-ons that defined what Firefox was. There are no
problems even with a ten thousandth of the resources that Mozilla has.

Mozilla removed XUL and all the power features because they were incompatible
with building a chrome clone that could protect users from themselves. They
did this because market share became more important than features and the vast
majority of people don't want or even understand that their browser can be
customized.

------
causality0
_The XPCOM-based extension mechanism was mostly dropped (we still use it
internally)_

See, that's the rub. Many of us would choose to have add-ons that break every
time the browser updates, or delay browser updates until our mission-critical
extension is updated. You didn't give us that choice though. You said "do it
the way we want you to do it or piss off." Looking at Firefox's 3% market
share, most of us chose the latter.

~~~
Yoric
Our experience is that add-on developers didn't like that. Only the few add-on
developers that actually made money from their add-ons could afford to rewrite
their code every 6 weeks.

Clarifying the article.

------
noomen
A couple of years ago I swore I would never leave ff, but they decided to just
neuter the add-ons and remove most of them. So I didnt think twice. Moved to
waterfox, and then to Palemoon. I'm happy.

I'm sad they're losing, but they need to be adults about it and do what needs
to be done. I and many others are waiting to go back as soon as they fix
things.

~~~
calcifer
This comment is seemingly a reaction to the post's title and doesn't address
(or even acknowledge) the contents of article. Do you disagree with the
technical rationale the author has presented?

~~~
sprash
The content of the article does not really make a technical argument. It just
says "XUL can not be fast, because I said so". The code of Firefox has always
been a historical grown mess with a lot of loose ends that need to be
entangled. I'm convinced that a XUL version can be made fast as well if you
spend the appropriate amount of engineering hours on it.

~~~
Yoric
(article author) Pretty sure I didn't write that :)

