
The Future of Developing Firefox Add-ons - zawaideh
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
======
scottjad
A funny comment on the post:

"BTW, if you really want to show us that you trust this much in these new
WebExtensions, the first ones to appear at AMO should be Pocket and Hello.

Remove that code from the core Firefox and put it where it always should have
been: an extension that anyone interested can easily install."

And a more serious comment from a developer of DownThemAll!:

"I was thinking of abandoning add-on development for a while now, mostly
because of the Walled Garden signing approach that went live, which I strongly
objected to and still strongly object to… I might have come to terms with it,
once I see it play out in an actual implemention…

But “deprecating” XUL-based add-ons with XPCOM access takes the cake. Once
that happens, I will abandon ship for sure. Simply because I cannot continue
developing most add-ons at all as they will not and cannot fit into any
“WebExtensions” API. The flexibility of what XUL-based add-ons can do IS the
major selling point of the Firefox add-ons ecosystem and therefore IS one of
the last remaining selling points of Firefox itself that isn’t purely
ideological. In comparison, the APIs that Chrome and competitors offer, that
the Firefox Jetpack/ Add-on SDK offers, are just… toys.

To give a little background about myself to show that I’m not just the random
hater shooting a drive-by comment: I wrote some more or less successful add-
ons in the past, including DownThemAll!, and reviewed many, many add-ons as an
AMO volunteer."

[https://blog.mozilla.org/addons/2015/08/21/the-future-of-
dev...](https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-
firefox-add-ons/comment-page-1/#comment-218580)

~~~
wvenable
I use Tab Mix Plus for multi-row tabs in Firefox. It's so important to how I
browse that it's the main reason why I use Firefox. If it goes away, then I
have no reason to use Firefox.

~~~
Tobu
Tab Mix Plus is explicitly mentioned as something they'll support:
[https://wiki.mozilla.org/WebExtensions#Additional_APIs](https://wiki.mozilla.org/WebExtensions#Additional_APIs)

~~~
wvenable
Lets be clear; they won't be supporting Tab Mix Plus. They will be providing
an API that might allow something similar to be built by someone. This is a
good thing but nothing is guaranteed.

~~~
brighteyes
It's not guaranteed, but they said they are hiring people to work with addon
developers to update their addons. It seems very likely Tab Mix Plus would be
on the top of that list, since it's already mentioned as an addon they want to
work in the new model.

------
shock
> The Beta and Release versions of Firefox based on 42 and above (Beta 42 will
> be released at the same time as Firefox 41) will remove the preference that
> allows unsigned extensions to be installed, and will disable and/or prevent
> the installation of unsigned extensions.

This is very bad news for me. I'm a power user that prefers the balance of new
features/chance of breakage that the Beta channel offers and I take full
responsibility for the addons I install and the security decisions I make. I
don't need Mozilla to be "defending" me in this case.

~~~
nine_k
_«The Nightly and Developer Editions of Firefox based on 42 and above will
retain the preference to disable signing enforcement, allowing the development
and /or use of unsigned add-ons in those versions»_

So I think running the Developer Edition (which I expect to be much more
stable than Nightly) is probably your best bet.

~~~
shock
The thing is, I'm not a web developer and I don't think I should be forced to
use the Developer Edition just so I can remain in charge of what I install in
my browser. Now that I'm writing this it occurs to me that after this change
it's not really _my_ browser anymore, is it?

~~~
hew
I hear you on the control thing. You mention you are a power user above so my
two cents is that likely puts you outside of the user base Mozilla covets. In
the last couple years, the words "Firefox" and "power user" went hand-and-hand
but I'd wager Mozilla would trade customer bases with Google in a heartbeat.

FWIW, the Developer Edition feels pretty lean and mean. I haven't tried since
I am a web developer, but it looks like you can remove most or all of the
parts that make it web developer-y if you are so inclined.

~~~
Animats
_" You mention you are a power user above so my two cents is that likely puts
you outside of the user base Mozilla covets."_

Mozilla's business model needs users who can't figure out how to turn off
Yahoo search. That pays for their new Firefox offices on the waterfront in San
Francisco.[1]

[1]
[https://www.google.com/maps/@37.7895991,-122.3883498,3a,36y,...](https://www.google.com/maps/@37.7895991,-122.3883498,3a,36y,261.2h,88.58t/data=!3m6!1e1!3m4!1smc9fpZTq_-
zg0zkcnud46g!2e0!7i13312!8i6656)

------
__david__
So on the one hand I love that they're moving forward. Sometimes it's good to
get rid of cruft (and boy is XPCOM crufty). On the other hand, the rich
extension ecosystem is one of the highlights of Firefox.

I honestly don't know what I'll do if my TreeStyleTab extension is disabled. I
lucked out because the Beta version has the preference to use unsigned
extensions. But that extension is so fundamental to my Firefox experience that
if they remove that preference in the new version then I think I'll have no
choice but to turn off updates and live with my current version indefinitely.
And that doesn't make me happy.

~~~
jasonhansel
Furthermore, I doubt that such extensions will work without XUL/XPCOM, at
least if WebExtensions work like Chrome extensions.

~~~
nwah1
That's why they're also working on browser.html so vigorously

[https://github.com/mozilla/browser.html](https://github.com/mozilla/browser.html)

Web standards are fully capable of rendering entire user interfaces now. GUI
toolkits are just needless dependencies for web rendering engines.

~~~
fabrice_d
Exactly. Once all your front-end is in html, including the part that manages
tabs, nothing prevent a WebExtension to implement TreeStyleTabs.

Also note that the same extension support is landing in Firefox OS (we are
working on the missing apis), and will let you install the same extensions
everywhere.

I understand people mourning xpcom access. You can do fun things with that,
but I've also seen my share of horrors when I was reviewing add-ons (let's
override the http protocol handler, what could go wrong!).

~~~
throwaway2048
if i wanted something that has limited addons like chrome, why wouldn't I just
run chrome, rather than some inferior "me too" edition?

I choose firefox because of the power of its addons, this is a huge issue for
me as a user.

And yes, I know that you will be consulting with addon authors about api
functionality, but i guarantee tons of stuff is still going to be lost...

~~~
anon1385
>And yes, I know that you will be consulting with addon authors about api
functionality, but i guarantee tons of stuff is still going to be lost...

Not to mention all the potential extensions that nobody has thought up yet
that will no longer be possible and probably never will be. The ability to
experiment and try out new ideas that nobody had thought of before is what
gave us a lot of the extensions people use today. An API that tried to imagine
all the possible features people might need and then locked down everything
else would have prevented a bunch of the extensions that are popular today.

This problem exists for the web in general though (being a tightly controlled
sandbox where only features agreed on by all the vendors are allowed). So I
think Mozilla is probably institutionally incapable of understanding the
problem, since it undermines the central mission of the entire organisation -
which is to convert all end user software into software that runs in a vendor
controlled sandbox. People who appreciate the creative cost of tightly
controlled sandboxes probably wouldn't go to work for Mozilla.

------
keypusher
Disabling unsigned extensions without any opt-in is a terrible decision.
Putting up barriers to entry for addon developers in a browser that survives
primarily based on the addon ecosystem is suicidal. Addon developers do not
want to run unstable alpha channel builds, they don't want to have to manage
multiple profiles, they don't want to build Firefox from scratch because the
version they need is not available via a package manager. I really don't care
about the rest of these changes, but they need to rethink their stance on
unsigned extensions.

~~~
nocman
I agree.

One possible workaround would be to provide a way to add keys from which you
would accept extensions. Then as part of the extension development process,
you could sign your extension with your key when you are ready to install it.

If the issue Mozilla is _really_ concerned about is security, this should be
an acceptable solution.

~~~
coldpie
I think you have a good idea, but

> If the issue Mozilla is _really_ concerned about is security, this should be
> an acceptable solution.

I don't know what you're implying here. That they're not concerned about
security? What are they concerned about?

~~~
nocman
No, indeed I do hope that security is the primary thing they are concerned
about.

But it is _possible_ they have other motivations (like control). I hope that
is not the case, but I think it would be foolish to not even consider the
possibility.

------
shinratdr
Long time coming, the FF extensions system has been a security risk and a
development burden for years. Yes, it offered unique advantages, at a
significant cost though.

Judging by the number of users on Chrome, it's hardly a dealbreaker change for
most. Signing & locking down extensions is a necessity. Anyone who has to deal
with the user side of IT will attest to that.

You can't bury your head in the sand and expect the problem to go away or wipe
your hands of it and insist users should know better. The fact of the matter
is, browser extensions are one of the most common malware attack vectors
nowadays and vendors should be concerned about that.

It's going to be an unpopular change amongst hard-core Firefox users and FF-
only extension developers, but you can't let diehards force you to drown with
the ship. They'll live and find a way. It's regular users who will happily
jump ship to Chrome, Edge and Safari without a second thought.

~~~
nightpool
Chrome doesn't sign extensions though, and getting them listed isn't anything
more specific then a 5$ charge—how can you judge whether its "hardly a
dealbreaking change" based on that?

~~~
shinratdr
Chrome has moved quite steadily towards only installing extensions listed in
the Chrome Web Store, which results in roughly the same restriction.

[http://blog.chromium.org/2015/05/continuing-to-protect-
chrom...](http://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-
from.html)

Each vendor is moving at their own pace and in their own way, but the endgame
is clear. With that comment, I was also referring to the depreciation of XUL
more than the signing requirement.

~~~
nightpool
No, its absolutely not. The new firefox addon signing requirements are a
hundred percent more restrictive then the requirements to get listed on the
chrome store.

~~~
rctgamer3
Wrong. Chrome IS more restrictive, they don't allow non-Chrome Store add-ons
AT all. With Mozilla's implementation all non-AMO add-ons need to do is go
through the automated signing process. Which only takes a couple of minutes,
at most.

~~~
nacs
> they don't allow non-Chrome Store add-ons AT all

This is wrong. You can drag and drop an extension into the Chrome extensions
folder (or enable the developer mode in the extensions page) to install any
extension in Chrome.

~~~
TazeTSchnitzel
You used to be able to. You can't now.

~~~
chr1
You can, it just shows a warning about developer mode.

------
kibwen
Standardizing the basic means of browser extension is something that I've been
eagerly awaiting ever since Microsoft announced that Edge will support both
Firefox (Jetpack) extensions and Chrome extensions. But how will future
versions of Firefox handle the extensions that just can't exist in Chrome,
such as NoScript and Tree Style Tabs?

EDIT: I'm also excited at the idea that this could give Servo a running start
at an extensions story, since Servo will never in a million years support XUL
or XPCOM and hence all non-Jetpack Firefox addons are destined to fail there
anyway.

~~~
micro-ram
I use ScriptSafe (formerly ScriptNo) in Chrome similar to NoScript on Firefox.
Also check out uMatrix.

[https://code.google.com/p/scriptno/](https://code.google.com/p/scriptno/)

~~~
jb613
For one, it only a subset of Noscript: "A simple extension that brings ___SOME
OF_ __NoScript 's functionality to Chrome"

Secondly, in order to achieve its goal, it's relying on a hack:

    
    
         ...
         if (getElSrc(this) && getElSrc(this).toLowerCase().substr(0,11) != 'javascript:' && getElSrc(this).toLowerCase().substr(0,17) != 'chrome-extension:')
         ...
    

Not taking anything away from this extension, just that this illustrates what
everyone's saying - concerns about reduced functionality.

------
slasaus
"A major challenge we face is that many Firefox add-ons cannot possibly be
built using either WebExtensions or the SDK as they currently exist. Over the
coming year, we will seek feedback from the development community, and will
continue to develop and extend the WebExtension API to support as much of the
functionality needed by the most popular Firefox extensions as possible."

So to all extension developers leaning on the current permissive features or
XUL/XPCOM, please contact Mozilla and help them with finalizing their
WebExtension API in the upcoming year.

Also, in the future if all XUL in Firefox is replaced by browser.html, there
might be full customization options again based on html/css/js (thanks to
nwah1 for pointing that out).

------
_wmd
As a decade+ Firefox user I think this is fabulous news, not because it'll be
easier for Chrome exts to come to Firefox, but because the old extension 'API'
was a heap of junk and made it trivial for third parties to really gum up
Firefox internals. Also huge kudos to Mozilla for not bikeshedding some
new/slightly incompatible API, which I'm not sure Google would have been
capable of. :)

Chrome's API is much better designed, I suppose, because they had the first
chance in 15 years to actually sit down and design a modern/safe API for this
specific purpose. XPCOM just exposed JS to endless unsafe internal Firefox
interfaces.

~~~
adamc
Chrome doesn't have nearly as many useful plugins. If Firefox ends up that
way, I'll probably use something else...

------
shwetank
We at Opera have called on for a single (or at leat a shared) API for making
browser extensions, which I think will benefit the developer community
immensely (instead of making one set for each browser).

I think now the time is right to take a look again at NEX
[https://dev.opera.com/blog/introducing-
nex/](https://dev.opera.com/blog/introducing-nex/) and standardising core
parts of browser extensions.

------
simonster
It used to be that Firefox extensions could have the same capabilities as
Firefox itself. It seems that this move is relegating them to second-class
status.

Here's a list of things missing from the Chrome/WebExtensions API that our
extension currently does:

\- Customization of the browser UI beyond a single, simple toolbar button or a
few other specially implemented widgets.

\- Reading/writing arbitrary files to the file system. There is
chrome.fileSystem, but it's limited in what it allows, and it isn't available
to extensions, only Chrome apps.

\- Interfacing with other applications. This typically requires using
platform-native APIs, which was possible with js-ctypes
([https://developer.mozilla.org/en-US/docs/Mozilla/js-
ctypes](https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes)). Chrome
has a socket API, but it's not really the best way to do IPC, and it isn't
available to extensions anyway.

\- Some kind of SQL database. Firefox has an SQLite interface (MozStorage),
but it's not part of the WebExtensions API. Chrome actually has WebSQL, but
Firefox never implemented that (with good reason, IMO; it's tied to a SQLite
and shouldn't be used on the web). I guess you'd better like IndexedDB.

\- Native-looking UI widgets. This is certainly possible to do in HTML, but
it's not always so easy. For example, we have yet to find any reasonable HTML-
based replacement for our tree view that's both visually appealing on all
platforms and reasonably performant with thousands of items. (If you have
suggestions, let us know!)

I guess Mozilla's viewpoint is that, since everyone is already supporting
Chrome, they don't need these things. However, for our extension, the
difference between the Chrome and Firefox implementations is that the Chrome
implementation needs to talk to a separate app, while the Firefox
implementation can do everything itself. Firefox used to give us a very
powerful toolkit for writing apps, the same toolkit they used to create
Firefox. Now it looks like all we'll have is a toolkit for writing simple
browser extensions.

I think many people use Firefox because they can customize it the way they
want to. Soon you won't be able to customize Firefox any more than Chrome.
Maybe Mozilla is banking on Servo being so fast/secure that people will use it
over Chrome even when all the other advantages are gone.

~~~
pdkl95
> relegating them to second-class status

That's the _goal_. "Web apps" are always going to be 2nd class apps, because
it is _insanity_ to allow the spoofing of the native UI. The security sandbox
will always have significant restrictions, by definition. If you don't like
this, _write a native app_ instead.

> Reading/writing arbitrary files to the file system.

Are you _trying_ to open up a massive security hole? Filesystem access is
banned on purpose. Writing an extension in a way that guarantees arbitrary
filesystem access cannot be exploited through some complex interaction with
the rest of the browser environment is probably impossible (see: the Halting
Problem). It would certainly fail in practice.

Seriously, stop treating the browser as the OS+desktop. If your platform
doesn't offer any true "native" access that has the features you want, then
take that up with the platform's vendor.

~~~
the8472
> Are you trying to open up a massive security hole?

Firefox extensions run in a privileged context. They essentially are not
really different from components of firefox itself.

Firefox components can obviously access the filesystem. So can extensions.

An extension in itself is not any more a security hole than firefox itself.

> Seriously, stop treating the browser as the OS+desktop.

While I agree with you there, what's needed to get to that point would be
browsers actually talking to the native environment more. Pipes, sockets,
filesystem access (chroot-style) even limited process launch capabilities.

If web or extension APIs allowed that it would be far easier to integrate with
native instead of having to build it straight into the browser.

But that just addresses the "app" kind of extension.

Other extensions instead customize the web browsing experience. For example if
you have a file form and want to do automation (filling in the right files?)
then you already need access to the file system. This has nothing to do with
native apps and yet needs access to native resources.

~~~
dingaling
> Firefox components can obviously access the filesystem.

Which is a hole that should be plugged.

Beyond its home subdirectory and a tmpfs Downloads location an Internet-
connected browser should be prevented from writing anywhere.

Bonus points for preventing read access to non-runtume locations too. Not only
prevent bad data from coming in but prevent good data from being sucked out.

~~~
simonster
Sandboxing extensions' access to the file system would be acceptable. We could
work with that, just as OS X app developers have. But Chrome and the current
WebExtensions API don't allow extensions _any_ file system access beyond what
webpages get.

------
superkuh
Well, this is all terrible. They mention having to use the nightly or
developers releases instead of their walled garden versions. But both of those
are unstable and very crashy. And how likely are they to keep the unbranded
version up and updated as time goes on?

And getting rid of the entire firefox add-ons community is just insane. The
add-ons are what makes firefox good. It's why people use Firefox. I guess if
they just want us to use Chrome this series of changes will work great.

~~~
charlesism
I don't have sufficient command of the English language to fully express how
strongly I disagree with this. I have an extension which I made for Chrome and
Firefox. The Chrome version basically consists of a single Javascript file,
and a tiny json file with about 15 entries. I spent perhaps an hour to learn
the basics from scratch. I don't have space here to describe all the crap I
went through to get the same extension working on Firefox - and I was using
their _easy_ API. The Firefox extension development process is one of the most
confusing, complicated, experiences I've ever had on a computer. Good
riddance!

~~~
__david__
Nobody said Firefox was _easy_ to develop add-ons for, the GP said _" The add-
ons are what makes firefox good"_. The add-on API itself might be arcane and
confusing and horrible, but you basically have access to _everything_. Since
the entire browser is written in XUL, add-ons can override and recreate
anything at any level.

The end result is that Firefox users have a much wider array of add-ons to use
(despite the add-on system being somewhat crazy by today's standards).

~~~
charlesism
Well I disagree with him/her there too. What _made_ Firefox good was that it
was a lightweight, simple browser, that rendered content exactly the same on
three OSes. It's still my main browser, but that's only because I want less
Google in my life, and because Safari aspires to be a motion picture instead
of a tool. But I haven't considered Firefox actually "good" since probably
2010, or whenever it was that they dumped a bucket of LSD on the interface.
Since then it's become a bloated mess.

If someone wants to add toolbars and skins, etc, I suppose the new API would
disappoint. But it's hard for me to relate, because I'm not that adventurous.
The ones I really care about, generally AdBlock and privacy extensions, just
interact with web content, not chrome. That sort of add-on is just as
available on Google Chrome.

~~~
superkuh
Tell it to NoScript.

~~~
charlesism
Ha, well you do have a point there.

------
jasonhansel
I switched to Firefox in part because XUL-based extensions can heavily
customize the user interface. Things like Tile Tabs, Tab Mix Plus, and other
extensions have been extremely useful to me. Despite my dislike of XUL as a
language, I'm sad to see XUL extensions go; I suspect that WebExtensions will,
like Google Chrome extensions, be much more limited.

In fact, I had always hoped that FF would move in the opposite direction, and
split itself apart into a bundle of extensions, so that even more
customization could be possible.

I've also always enjoyed being able to run the latest versions of extensions,
which sometimes take a while to get Mozilla's approval.

Are there any plans to maintain a fork of Firefox that will not include these
changes?

~~~
jasonhansel
In short, I would like to find a web browser that follows the Unix philosophy
to a greater extent than Firefox/Chrome/IE.

~~~
GFK_of_xmaspast
wget piped to less.

~~~
Qwertious
To state the obvious, that won't have Javascript support.

~~~
GFK_of_xmaspast
Javascript is not compatible with the Unix Philosophy.

------
super_mario
And this is how Google killed Firefox. Why do people use Firefox? For
extensions. What breaks extensions, frequent updates and extension API
changes.

Google managed to suck Mozilla into frequent releases and now extension API
changes that make Firefox yet another generic easy to substitute browser. Wow,
just wow.

~~~
uxcn
Frequent releases aren't a bad thing, per se. Although, huge API changes like
this, without a valid plan for supporting existing ones a large community
depends on seems like a disaster in the making.

The impression I get is that Mozilla wants to be more involved in the user
experience around their codebase, but personally I preferred firefox's lack of
involvement. I think the UI is poorly designed and getting worse, but as long
as it was easy to modify, it wasn't an issue. The real value in firefox for me
is gecko. Most other things largely get in the way, and it seems like that's
what's becoming the focus.

I can understand the need for a better designed add-on API, but there should
probably be a non-compulsory reason for people to switch.

------
nocman
"we will require all extensions to be validated and signed by Mozilla starting
in Firefox 41"

I hope there is an "opt out" option to this for people who know what they are
doing. I understand the reasoning behind it, but what about an extension I
write just for myself that I don't wish to share with Mozilla? I don't
particularly like having that option taken from me.

Yeah, I know, I could edit the source and work around it -- but based on past
attempts to just _build_ firefox, that could be a real pain.

~~~
the8472
There will be unbranded builds that provide that option, branded builds will
enforce signature verification.

~~~
nocman
Are you referring to iceweasel? Or are you referring to an unbranded build
provided by Mozilla?

I honestly don't remember any other browsers that have the Mozilla branding
removed, but I haven't really tried to find any.

~~~
lol768
Mozilla will provide these unbranded builds in the en-US locale.

See "What are my options if I want to install unsigned extensions in Firefox?"
in the FAQ for more info:
[https://wiki.mozilla.org/Addons/Extension_Signing#FAQ](https://wiki.mozilla.org/Addons/Extension_Signing#FAQ)

------
mrbig4545
It doesn't mention addon permissions, which I would assume is something
WebExtensions has, since that's how addons work in chrome. At least I hope
this is the case, lack of permissions in firefox addons is a little scary, and
probably one of the reasons I have the minimum addons installed

Anyone have more info on this?

~~~
snowwolf
Same permissions model as Chrome -
[https://wiki.mozilla.org/WebExtensions#Permission_Model](https://wiki.mozilla.org/WebExtensions#Permission_Model)

~~~
mrbig4545
Excellent, that's what I wanted to hear! Thanks

------
fra
I worry that extensions that implement their own navigation and user
experience will no longer be possible.

I use Vimperator extensively and would hate to see it go.

Chrome does have Vimium, but it is quite clunky and limited compared to the
couple of Firefox solutions.

------
tetraodonpuffer
I was under the impression that add-ons like ublock / umatrix were possible
only in firefox due to its very permissive add-on model, if mozilla is going
to deprecate XUL / XPCOM would it mean this kind of add-on won't be possible
anymore?

~~~
snowwolf
uBlock - [https://chrome.google.com/webstore/detail/ublock-
origin/cjpa...](https://chrome.google.com/webstore/detail/ublock-
origin/cjpalhdlnbpafiamejdnhcphjbkeiagm)

uMatrix -
[https://chrome.google.com/webstore/detail/umatrix/ogfcmafjal...](https://chrome.google.com/webstore/detail/umatrix/ogfcmafjalglgifnmanfmnieipoejdcf)

~~~
tetraodonpuffer
thanks for the clarification, I haven't looked at add-ons for other browsers
for quite a while, and at the time I remember discussions about adblock not
being possible to be done anywhere else like in FF due to the add-on model,
glad to see this does not seem to be the case anymore

~~~
falcolas
I think the big difference is being able to pre-emptively block/modify
requests, vs. changing what is displayed after the fact.

~~~
tetraodonpuffer
that was what I thought as well, however I went to the umatrix github page and
if you look at the top it links this page[1] that discusses how umatrix needs
permission to disable prefetching so no network connections are made for
blocked sites, which seems to imply it can do the pre-emptive blocking as
opposed to just hiding of elements.

I am wondering though now if I am mixing things up in my brain and the issues
were with safari add-ons as opposed to chrome/chromium: there is no umatrix
for safari[2] that I can see, ublock seems available but not ublock origin,
but I am not sure if ublock on safari just hides or actually pre-emptively
blocks.

[1]
[https://github.com/gorhill/uMatrix/releases/tag/0.9.1.2](https://github.com/gorhill/uMatrix/releases/tag/0.9.1.2)

[2]
[https://github.com/gorhill/uMatrix/issues/96](https://github.com/gorhill/uMatrix/issues/96)

~~~
gorhill
> umatrix needs permission to disable prefetching so no network connections
> are made for blocked sites

Disabling pre-fetching is to prevent a TCP connection to be established at
all, and this is something that needs to be also dealt with in Firefox -- it's
not just a Chromium thing. This ensures that no TCP connection is established
before it has been decided whether a network request must be blocked or not.

Chromium used to not be able to support the pre-emptive blocking of network
requests, but that has been remediated in 2012 with its webRequest API in
Chrome 17.

[1]
[https://developer.chrome.com/extensions/webRequest](https://developer.chrome.com/extensions/webRequest)

~~~
the8472
Which brings us back to the point that one cannot develop any new, unforseen
kind of extension unless you either have the option to directly interface with
the browser's internals or somehow get that API included in the browser.

------
Tobu
Great news. With the current system, firefox's stability, upgrade
compatibility and performance were entirely dependent on every author of every
extension I use being sufficiently careful. It meant a lot of periodic purges,
housekeeping, and reduced trust. I'm sure the overhead helped users move to
chrome, despite Firefox's vanilla install being lighter. Reducing the API
surface was a necessity.

Also, it takes a lot of effort to cope with the churn in internal APIs, and I
had to get rid of promising extensions like Pentadactyl because they broke too
often. With a smaller, stable API, that problem doesn't exist. I don't believe
that the current tradeoff of power vs responsibility was working out in the
majority of cases, and I've seen enough evidence in the form of lagging addons
and neglected ports.

~~~
the8472
> It meant a lot of periodic purges, housekeeping, and reduced trust.

> I don't believe that the current tradeoff of power vs responsibility was
> working out in the majority of cases,

For me those tradeoffs are worth it. Sometimes it means installing a beta
builds of an addon or nagging its developer on github or even finding a
replacement. But that's still better than not having the addons at all because
the APIs simply make it impossible to have them in the first place.

If mozilla separated addons into "uses stable APIs only" and "might break at
any time, we may even turn them off if they cause to many crashes" that might
allow users to choose which kind of model they want to follow.

~~~
Tobu
XPCOM has support for stable, versioned APIs, but no one cared about using
that subset since the rest was also available; it stagnated and the supposedly
unstable APIs ended up bearing the compatibility burden. Now there will only
be a supported subset, and the trickier stuff will require getting a patch
accepted instead of monkey-patching and letting the user cope with the
breakage. Your coping skills are above average, I've submitted patches too,
it's still yak shaving and not a very productive use of time. Working out APIs
is a hard problem, it should be handled as part of the development phase
instead of being completely disconnected.

------
annoyingdisb
WebExtensions is very good news. One of the biggest pains is to develop
extensions compatible both with FF and Chrome so it would make our lives a lot
easier.

------
fweespeech
The title is a bit misleading:

> We are implementing a new extension API, called WebExtensions—largely
> compatible with the model used by Chrome and Opera—to make it easier to
> develop extensions across multiple browsers.

This is basically the creation of a new, multi-browser API standard for
browser extensions. This isn't them just adopting a single competitor's
ecosystem. There is also a slim chance IE and Safari will join the plugin
ecosystem.

EDIT:

Ty mods, this title is more reasonable.

~~~
amyjess
> There is also a slim chance IE and Safari will join the plugin ecosystem.

You mean Edge. IE development is pretty much dead except for maintenance
releases, and it now exists solely to handle legacy websites (read: corporate
dinosaurs that rely on ActiveX).

~~~
fweespeech
Edge is basically IE in purpose and function. I don't really buy into the
rebrand.

------
mindcrime
Ya know, my initial reaction to this was pretty negative. As a developer, I
don't like the idea of losing access to a more powerful technique in favor of
a less powerful one. If I want to write an add-on, I _want_ XPCOM / XUL, etc.,
at least as an option.

However, giving it more thought, I think this might actually be a Good Thing
in the long-run. OK, it's a stretch, but hear me out... I've been a vocal
opponent of this whole idea of making the browser a poor man's operating
system for a while. I want a Web where browsers are really good at, well,
_browsing_ hypermedia, and other applications handle "application stuff". So
maybe, in a roundabout fashion, making it a little bit harder to extend the
browser even further, will encourage people to shift back to a model of
handing off some kinds of requests to an entirely different app, rather than
trying to shoe-horn the kitchen sink, bathtub, 3d printer, milling machine,
jumper cables, semiautomatic pistol, bandsaw, swimming pool, and clown suit
all into the browser.

Or maybe not. Hey, a guy can wish, right?

~~~
dragonwriter
I think the opposite is more likely: Firefox and Chrome using the same
extension mechanism -- and, inevitably, that means two-way chasing on
implementing APIs that prove useful -- means that even if the ability to do
more complex apps in Firefox falls in the short run, the ability to more
complex apps in the _browser_ in general (or, at least, Firefox, Chrome, and
their descendants and others who adopt the same framewoek) is going to
accelerate over a longer term.

~~~
mindcrime
Yeah, I'm afraid you're right. :-( But like I said, a guy can wish.

A more interesting question might be: "What would it take to slow down this
movement towards doing everything (and then some) IN the browser"?

------
dannysu
I still don't like that the AMO review process can take weeks and months.
Mozilla even says it themselves!

But hopefully with WebExtension and a permission model things will get easier
for getting through reviews.

------
Animats
_" A major challenge we face is that many Firefox add-ons cannot possibly be
built using either WebExtensions or the SDK as they currently exist."_

That's so Mozilla. There's a long history in add-on development of Mozilla
deprecating the old thing before the new thing works.

XUL/XPCOM had to go. The mobile browser, "Fennec", doesn't use it at all.

But the "Jetpack" API, the one Mozilla wanted everyone to use instead of
XUL/XPCOM, is apparently being deprecated as well. The announcement says it
will "continue to work", but the new API seems to be completely separate from
Jetpack. That probably means bugs in Jetpack won't be fixed, and bug reports
will be answered with "convert to (new thing)".

 _Mozilla AMO. Embrace the pain._

~~~
toyg
Jetpack was such a clusterfuck. Horribly documented, released while not ready
for prime time, missing basic functionality, and progressing as slowly as
Italian criminal trials. I can see the point of them starting from scratch.

It would have been nice if they had learnt their lesson and actually started
communicating changes _after_ they had something real to show, but alas, it
seems like they're doing the same thing, just a little bit faster (maybe).

~~~
Animats
" _Jetpack was such a clusterfuck. "_

Yes, and now that it pretty much works, after years of bug reports and nagging
to get bugs fixed, they're deprecating it.

------
amyjess
I'm really disappointed with them deprecating XUL extensions.

I use a number of extensions that extensively modify the UI (e.g. Tab Mix
Plus), and honestly I'd rather just stick with an older version of Firefox
than use Firefox without these extensions.

~~~
Tobu
They're using the WebExtension model of isolated extensions with permissions.
They're not going to limit themselves to any competitor's API, they'll build a
superset by consulting with the developers of popular extensions. Tab Mix Plus
being the 15th most popular extension, it's pretty certain they'll be
consulted on the new APIs.

Quoting from the announcement:

> A major challenge we face is that many Firefox add-ons cannot possibly be
> built using either WebExtensions or the SDK as they currently exist. Over
> the coming year, we will seek feedback from the development community, and
> will continue to develop and extend the WebExtension API to support as much
> of the functionality needed by the most popular Firefox extensions as
> possible.

------
neves
I loved this: " We would like add-on development to be more like Web
development: the same code should run in multiple browsers according to
behavior set by standards, with comprehensive documentation available from
multiple "

------
jaredsohn
>Blink-compatible API in Firefox called WebExtensions

Does anyone know why they are calling this API Blink-compatible rather than
Chromium-compatible? My understanding is that Blink is just the rendering
engine and extension code can be found within the main Chromium project.

My best guess is that they are referring to it this way since I think that
currently the list of browsers that use Blink is the same as the list of
browsers that use Chromium code and people are more used to categorizing
browsers based on their rendering engine rather than where the code
originated.

~~~
dragonwriter
> Does anyone know why they are calling this API Blink-compatible rather than
> Chromium-compatible?

That's a good question, since the two sources they link to (from Chrome and
Opera) both refer, directly or indirectly, to Chromium extensions, and neither
refers to "Blink" at all.

------
toyg
It looks like a bad case of Big Rewrite. Which is mildly unsurprising, coming
from an organization that was created to undertake a Big Rewrite; however,
after the dismal Jetpack experience, I'm surprised they want to do it all over
again, just harder and with no safety net.

How can you tell your own developer community "what you're doing now, it won't
be allowed next year; but what will be, we don't know yet"? You might as well
tell them to go home.

------
ajnin
We all know too well what happens when a backwards-breaking change is imposed
without strong functional justifications : most developers don't actually put
the effort to upgrade and as a result the vast majority of extensions break.
Case in point : python modules, after tremendous effort and years of waiting
about 2/3rd of the existing modules have been ported from python 2 to 3.

This is relatively "mitigated" in the case of add-ons because backwards-
incompatibility has become the norm so old add-ons are likely to break anyway
at some point, but this still seems like a very bad idea for Mozilla to kill a
large portion of their ecosystem in that single move, especially if in the
bunch are very differentiating extensions like Tree Style Tabs.

Justifying the decision by becoming even more interchangeable with Chrome is
especially baffling, what is the strategic point of this?

~~~
TazeTSchnitzel
Python 2/3 yielded very little benefit.

That's not the case for Firefox's migration: WebExtensions are easier to write
and work with other browsers.

------
thiht
>We have decided on an approximate timeline for the deprecation of XPCOM

Thank god, this undocumented crap is a nightmare to use

------
scottjad
They want to kill XUL for Firefox, so they must first kill XUL for add-ons so
that the add-on situation sucks so bad with XUL Firefox that people don't lose
anything by moving to non-XUL Firefox.

And once they kill XUL, they can kill gecko, the maintenance of which is the
bane of their job.

~~~
holygoat
That's not the plan.

We've identified that XUL is a growing impediment to Firefox's continued
success. Exactly what that means (there are dozens of reasons and dozens of
ways forward), and how we're going to tackle it, is a big topic that we're
digging into.

Yes, removing XUL implies that XUL-based add-ons are not going to last
forever. That doesn't mean there won't be a path from here to there: everyone
involved recognizes that add-ons are important, and we're increasingly going
to be shipping parts of Firefox itself using add-on mechanisms.

And I haven't seen anyone seriously consider killing Gecko: it continues to be
awesome, and one of the motivations for deXULification is to allow our
platform developers the freedom to only focus on supporting HTML UIs, not a
mix of HTML and XUL.

------
e12e
Uh-oh. The main reason I use firefox is vimperator. Followed by the open
source, easy to self-host sync framework, noscript and adblock.

One thing I don't see anything about wrt extensions is user control. If ff is
to remain relevant - signing extensions will need to come with a trust
management framework. I might want to run extensions signed by Debian and
myself - but not mozilla (in iceweasel). RedHat (or other vendor) might want
their unbranded ff fork to only use RedHat extstensions by default; maybe with
an option to also allow upstream ff signed exstensions.

Without that; I see no point in signing support in a free software product?

~~~
hackuser
Regarding Vimperator:

[https://billmccloskey.wordpress.com/2015/08/21/firefox-
add-o...](https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-
changes/)

~~~
e12e
Well, that's more regarding Noscript and Tree Style Tabs, actually -- it only
mentions vimperator/pentadactyl in passing. Either way, thank you for the link
-- hopefully the development of new APIs won't lead to a regression wrt. the
add-on ecosystem :-)

------
Illniyar
Frankly the only reason I keep using Firefox instead of Chrome is because of
TreestyleTabs.

If this change means TreestyleTabs will not work/won't get updated, then I
don't see myself continuing to use it.

------
reitanqild
We can talk about "only approved extensions" after they have taken time to
consider the pinboard extension.

For now I am happy someone have told me that Pale Moon exist.

------
serve_yay
> ... [cross-process object wrappers] are much slower than the equivalent DOM
> operations in single-process Firefox, and can affect the user experience
> negatively. Also, some accesses aren’t supported by the compatibility layer
> and will throw exceptions.

Hmm, that sounds... bad?

~~~
quotemstr
I don't see why cross-process XPCOM would have to be particularly slow.
Windows is built on cross-process COM.

~~~
TazeTSchnitzel
Windows isn't built on COM, Windows is built on Win32 which is a 1980s API
hurriedly updated to 32-bit.

------
jimmaswell
"This post really marks the final end of Firefox. The end of a truly robust
Add-On model is the only thing remaining at all that sets Firefox apart. The
Foundation’s constant running after being a Chrome-alike has finally run the
browser into the ground fully."

This comment hit the nail on the head.

Really in general the browser vendors are all killing the web day by day.
Maybe ~2004 to around 2013/2014 or so will be remembered as the golden age of
web browsers. NPAPI worked in major browsers, you were allowed to install
extensions without Mozilla or Google's permission, and Firefox had yet to
mutilate its interface in an attempt to be a Chrome lookalike.

------
antman
The last Symbian in Nokia phones was also very strict with signed
applications. I bypassed it, but it is my impression that most people did't
bother.

------
jpatel3
There used to be a time when I loved firefox..the new versions are slow and
sluggish. If I open the developer console, its super slow.

~~~
Tobu
The developer console can disable the cache so that you can edit websites
live, is that what you're seeing?

Also, I wonder if it's still slow if you restart with extensions disabled.
There's a lot of hidden interactions in the current model.

------
dafrankenstein2
though its late, security review is a great thing! (maybe firefox realized its
urgency after a major security flow found in Pocket.)

------
Nadya
"To make sure that some of our users are more secure, we're going to implement
a change that will cause some of our users to refuse to update their browser -
potentially making them less secure."

I've disabled updates in FF.

Palemoon removed Tab Groups and the addon is _extremely_ buggy and doesn't
restore properly when the browser crashes. Waterfox had several issues with
plugins I use.

I guess it's time to fork FF and maintain my own version, implementing
security patches as they come in?

~~~
catern
>I guess it's time to fork FF and maintain my own version, implementing
security patches as they come in?

AKA Iceweasel?

~~~
Nadya
Is Iceweasel able to be compiled on Windows? I don't see why they would
distribute/maintain it outside of Debian/*Nix distribution. Although maybe
they decided not to touch the makefile? (And any currently available
"Iceweasel for Windows" is hosted on malware sites.)

GNU IceCat could also be an alternative along the same lines, and I know for
sure that IceCat can be compiled on Windows and they distribute a Windows
binary.

The only problem being GNU IceCat doesn't seem to work on my work computer..

~~~
catern
I have no idea, but I'd guess not, sorry. But if you want to have control over
what your computer does, why are you using Windows? :P

~~~
Nadya
I want control over what my _browser_ does, not necessarily my _operating
system_.

I'm highly selective over my software as I require it to fulfill very precise
goals in the exact manner of my choosing. If it fails to do so, I'll find
better software.

For example, I have yet to find an image viewing software that is satisfactory
for my usage that exists for Unix distribution. I use an extremely niche,
unheard of software that is 'Windows Only'. It's so niche that searching for
the name of this software on Google only results in posts of me talking about
the software. (I decline to name for privacy reasons.)

My operating system is a platform to run software. I'd hop to Debian or Arch
in seconds if I could find existing software that meets my needs. While the
image browser is one example, there are more that do not exist to my desired
standards outside of Windows applications.

My desire for software that performs certain functions and in the manner I
want outweighs my desire for privacy from my government and control over every
system of my operating system.

ps:

I know your question was probably meant rhetorically.

------
Aardwolf
Well, that might make me look into SeaMonkey again...

------
tenfingers
You know, I had plenty of reasons to list about how useless signed extensions
are for what they're trying to achieve...

I'm even _already_ running an "unbranded" firefox in all my devices
(iceweasel, fennec), for the same reasons I have to run chromium, so I won't
even be _directly_ affected....

But there's only one thing I really want to say to Mozilla right now, as a
developer:

Fuck you Mozilla.

And there's another, as an user of which most extensions are unsigned:

Fuck you again, Mozilla.

aaah feels better.

~~~
jimmaswell
I agree, the web gets less and less open and free by the minute. It's actively
hostile to user choice half the time.

~~~
tenfingers
When Mozilla will decide, apple/google style, what is and what is not
acceptable as an extension for their browser, people will maybe realize that
this is just the tipping point.

But maybe that won't be necessary anyway. By adopting a very limiting standard
for extension development and dropping xul (which might be a good idea for
other reasons though), there won't be any significant difference between
firefox and (say) chrome. A few tweaks in the browser frame won't attract
masses of people. Switching from Chrome to Firefox on Android require a pretty
_big_ incentive.

Right now, I'm on firefox only for the extensions. I have really no other
compelling reasons.

------
pekk
It's only surprising if you don't understand that Mozilla's core mission now
is to promote a permanent JavaScript monopoly. Mozilla has committed to
blocking any technology which could ever offer equal support to any other
languages. Now they cannot even allow plugins unless they are based on
JavaScript. "The Web" used to mean web pages and HTTP, now "The Open Web" and
"Web Technologies" mean we are forced to work with a growing mountain of ill-
considered, weird and unsafe "bad parts" forever.

In a strikingly similar parallel dimension, vendors have applied pressure to
ensure that networked PCs would only run COBOL, and other languages could only
be supported by compiling to a subset of COBOL that inherited its semantics so
that nothing would ever be faster than COBOL. In that parallel dimension, this
restriction is known as "Open Web", although nobody knows what is open about
it.

~~~
skybrian
It sounds like you might not like JavaScript. You should know that there are
good languages that compile to JavaScript.

~~~
pekk
They have the same basic semantics as JavaScript.

It's not about that. Even if I liked COBOL, I wouldn't want a world where only
COBOL can be used. And it doesn't make sense that this world has to be
artificially enforced when there is demand for variety.

~~~
skybrian
Not sure what you mean by the "same basic semantics". I think the semantics of
Go and Elm are quite far away from JavaScript. Dart less so, but it's enough
to change the developer experience quite a bit.

I don't particularly like x86 instructions, but they also don't bother me that
often.

Granted that JavaScript isn't sufficiently hidden yet, particularly in
debuggers. That will take a few years. On the other hand, it's significantly
more readable than assembly and getting better, so as a compiler target
language, I think it will work out okay.

The forces here are no more artificial than the ones that made the industry
standardize on x86 and (later) ARM. Popular, accepted standards become more
popular when the barriers to alternatives are very high, as can be shown by
the people who tried and failed with strong alternatives.

