
Add-ons in 2017 - nachtigall
https://blog.mozilla.org/addons/2016/11/23/add-ons-in-2017/
======
hucker
Extensions is currently the only thing FF is better than the competition at,
and they scrap it to copy Chrome APIs... I just can't understand why they
would scrap XUL-based extensions before their new APIs reach feature parity.
The day pentadactyl stops working is the day I stop using firefox.

~~~
Yoric
Well, XUL-based extensions are not scraped yet. They will, at some point in
2017, but we're not there yet.

The reason to scrape them is simple: the total API surface of XUL-based
extensions is pretty much all of the internal APIs of Firefox, which means
that any change anywhere in the code of Firefox breaks some extension
accidentally. That's a compatibility burden that Mozilla could afford when the
only competitor was IE, but it makes the development of Firefox much less
nimble than that of Chrome & co. So a new, less invasive and more future-proof
API is sorely needed.

~~~
the8472
> is pretty much all of the internal APIs of Firefox,

But that's also what makes them more powerful than any other extension API.

If your box is airtight then there is no out-of-the-box thinking.

An almost trivial example: Internal APIs can inspect the _current_ (as-
enforced) sandboxing flags of an iframe. Which is not the same as the
sandboxing HTML attributes on the frame, because those can be changed without
effect after loading and also due to inheritance of sandboxing effects.

This tiny tiny tidbit is useful when making content-filtering decisions.

And it is just one among countless others.

~~~
Yoric
Indeed, it's difficult to achieve a perfect balance here. That's one of the
reasons the WebExtensions team has been very actively discussing with add-on
developers to try and prioritize which APIs should be created/ported to
WebExtensions.

I don't remember specific numbers, but I seem to remember that pretty much all
the extension points that had been requested by add-on developers were at
least somewhere on the TODO list of WebExtensions. I hope that by the end of
2017, they will all be available, with a much cleaner API than their XUL/XPCOM
counterpart, better tests and much better survival chances.

Of course, some of the changes will require pretty drastic reimplementations
by the developers. For instance, going from js-ctypes to the native bridge
will require full reimplementation in a different programming language. On the
upside, js-ctypes was really painful to use and the native bridge will let you
use a much better language for the task. Say Rust :)

~~~
the8472
The native messaging API is not useful for _addon developers_. They only cater
to application developers that ship a companion addon to their application.

js-ctypes allowed an addon to access already-present native libs on the the
host machine or bundled with the addon itself. Messaging only works if you can
get users to install some external application in addition to your addon,
which is a too-tall hurdle for small extensions.

From my perspective those barely comparable.

> That's one of the reasons the WebExtensions team has been very actively
> discussing with add-on developers to try and prioritize which APIs should be
> created/ported to WebExtensions.

You are taking requests to keep existing uses supported, mostly for big,
already established addons. My concern extends beyond that. Simply by having
access to internals anyone can currently develop _novel_ uses, even if they
initially do not have a userbase. Those can only be prototyped by access to
internals. Someone might not even have an idea if they don't know an API
exists that could be leveraged to do it.

In other words, "I can't let you do that, Dave" API design can stifle
creativity.

And it also introduces a bias in favor of already entrenched extensions, which
is less open than the current approach.

~~~
Yoric
> js-ctypes allowed an addon to access already-present native libs on the the
> host machine or bundled with the addon itself. Messaging only works if you
> can get users to install some external application in addition to your
> addon, which is a too-tall hurdle for small extensions. > > From my
> perspective those barely comparable.

I haven't checked, but I seem to remember that you can provide a platform-
specific binary as part of an add-on, spawn it from WebExtensions and then
communicate with it through the native bridge. Building/shipping one binary
per platform is annoying, but the rest is infinitely better than using js-
ctypes. I should know, I've been one of the first users of js-ctypes and I
still shudder at the thought :)

> In other words, "I can't let you do that, Dave" API design can stifle
> creativity.

True. On the other hand, this is the kind of paradigm shift that was
implemented by operating systems ~20 years ago (more in the case of Unix) and
so far, improving the safety and security of operating systems has generally
played in favor of users and creativity, not against them.

This doesn't mean that there is no space for lower level, MS-DOS/Apple II-
style hacking – I'm doing exactly that these days. But still, separating both
sounds like a good idea to me. YMMV.

> And it also introduces a bias in favor of already entrenched extensions,
> which is less open than the current approach.

Good point. I seem to remember discussions about how to have an "unsafe"
extension mechanism that would make it easier to experiment with non-standard
APIs. I haven't checked myself, but I believe that this mechanism has been
published, as an extension called "the WebExtension Extension" or something
like that.

~~~
the8472
> On the other hand, this is the kind of paradigm shift that was implemented
> by operating systems ~20 years ago

No. Kernel modules can be installed at runtime. The user just has to grant the
application the necessary privileges.

This means OS developers do not try to attempt to "strike a balance" between
power and safety. They allow both, the unsafe stuff merely requires a fairly
simple opt-in.

This is the whole crux of the issue. I do not mind security measures, as long
as there is a bypass. Mozilla has taken the - in my opinion extremist -
position that even bypasses cannot be allowed because they know what's best
for users.

> I haven't checked, but I seem to remember that you can provide a platform-
> specific binary as part of an add-on, spawn it from WebExtensions and then
> communicate with it through the native bridge.

I am not aware of any such feature. This used to be true for bootstrapped
extensions, but not for webextensions.

> I haven't checked myself, but I believe that this mechanism has been
> published, as an extension called "the WebExtension Extension" or something
> like that.

yes, only works on dev edition though.

------
nv-vn
And this is how Mozilla goes out. Their last remaining reason for existence is
being destroyed. They've already gotten rid of Thunderbird, Tab Groups, full
themes, and more, but left us with the things nobody wanted (Pocket, Hello,
etc.). They've also slowly let performance go in many places, seemingly.

A few years ago, I switched to Firefox for precisely the set of features
they've axed. It was also much faster than the alternatives for me, used much
less RAM, and rarely locked up. Since then, I've seen performance decline, RAM
usage ramp up, and watched the browser lock up nearly once every hour. At this
point, I'm probably just gonna go to Chrome. What's the point if Firefox is
just gonna be a shitty clone?

~~~
MrBuddyCasino
>> performance decline, RAM usage ramp up

Thats what they want to fix by getting rid of XUL, among other things.

~~~
weaksauce
Poorly written addons were precisely the reason that firefox got a bad rap in
the past. I hope webextensions being more common and restricted will help this
out.

------
_pdp_
The decline of XUL started around 2009. I spent months building a very complex
app around XULRunner only to find out that Mozilla had no interest to support
the technology in the future.

So I decided to leave the platform and put my efforts on native and web and
frankly it was a good decision.

The WebExtensions API is no match to XUL and XPCOM but I only hope that now
that we have Mozilla behind the technology we will see further API
improvements.

~~~
sudshekhar
> I decided to leave the platform and put my efforts on native and web

For the sake of curiosity, did you create extensions as side-projects/startup
ideas? Do people pay for extensions or are we talking about patreon funds here
(Or startups like pocket whose extensions are ways to get more crowds).

~~~
_pdp_
It was a desktop app that was based on top of XULRunner and yes it was for
profit and people payed for it. I have no experience with selling extensions
but I would imagine it is a very hard market to crack unless it is targeted
towards enterprise customers.

Based on my experience, I can only advise not to base your entire business
model on browser extensions as you will become dependent on platform moves
(again unless enterprise).

------
morinted
I'd love some figures on whether the main popular extensions will continue
working, as well as how many in the Firefox Add-ons site are already web
extensions.

I'm curious about my mains:

\- Classic theme restorer

\- uBlock

\- DownThemAll

\- Markdown Here

As I'm already using electrolysis, I know Markdown Here basically doesn't
work. How I can check whether things will break or not.

~~~
myfonj
You can consult [https://www.arewee10syet.com/](https://www.arewee10syet.com/)
; seems authors are mostly showing some efforts to migrate their extensions.
CTR: seems OK, uBlock: uBockO: seems OK, DTA: bug, but at least tries to be
e10s compatible, Mardown here: unknown (supposedly not compatible?)

You can try yourself: either install
[https://nightly.mozilla.org/](https://nightly.mozilla.org/) and load it with
your addons (it uses different profile) or use your stable one and look at
about:support page for "Multiprocess Windows" cell if it states 1/1 and does
not mention "(Disabled by add-ons)" you are covered. You can try some
about:config alterations [0] to force it if you are adventurous. In this case,
it might be nice to install "Add-on Compatibility Reporter" [1] for tracking
and sharing your findings.

[0] [http://superuser.com/questions/1096974/how-to-check-if-
multi...](http://superuser.com/questions/1096974/how-to-check-if-
multiprocess-e10s-option-is-enabled-in-your-firefox) [1]
[https://addons.mozilla.org/en-US/firefox/addon/add-on-
compat...](https://addons.mozilla.org/en-US/firefox/addon/add-on-
compatibility-reporter/?src=api)

~~~
majewsky
Careful. The e10s transition is a much smaller step than the move to
WebExtensions. To witness, notice how (higher up in this thread) the DTA
developer once again said that there will be no DTA as a WebExtension.

~~~
myfonj
Oh, thanks for pointing this out, I really mixed multi-process and
WebExtensions and diminished main XUL problem (which I oversimplified for
myself as "just problem of settings pages to be rewritten to HTML" what is
really wrong [0]).

As I understand it WebExtension is inherently multi-process compatible so (to
answer question below) the only extensions we know today will work next year
from arewee10syet.com are those marked as "compatible-webextension".

[0] Most of extensions I'm used to alters chrome visually or functionally:
calls external applications, changes hotkeys, so almost none of them are XUL-
free. But I still hope / believe Mozilla is not that insane and will achieve
consensus keeping the most important features for extensions authors available
in the end.

------
pasbesoin
There may be a lot of components and interests involved in this change.

As a user of, not developer for, Firefox with its extensions, it's this simple
for me: The day my existing extensions stop working -- the day neither they
nor an alternative under the new paradigm offer equivalent functionality -- is
the day I no longer have any reason to stay with Firefox.

I'm not saying, "Stop, wait, a user is unhappy!"

I'm simply saying that, as a perhaps sophisticated user with some more
advanced functionality, security, and privacy concerns, the set of extensions
I currently use is my only compelling reason for using Firefox over Chrome.

Well, that and Google/Chrome's current trend towards its own version of
Embrace, Extend, Extinguish wrapped within a panopticon.

I embrace the browser as the _user_ client. I'm glad to have security issues
addressed, but I also require that the browser do what _I_ want, and not what
-- a la Chrome, for example -- media interests want to dictate.

I'm watching 2017 with trepidation, and wonder whether and when something may
fork. Not unrealistically, though; I'm skeptical any fork is going to have the
resources and commitment to maintain a modern, full-featured browser in the
face of current and future... err, developments.

Maybe such a fork will, both of desire and of necessity, look instead towards
a bit of minimalism. Not doing "everything", but doing core functionality well
and securely.

I guess then we'd have to see whether the content farms with their
Javascript++, DRM delivered content, end up leaving such a fork too much out
in the cold for it to maintain sufficient interest and/or usefulness to keep
itself going.

------
Illniyar
As always, the only question for me is whether tree style tabs is going to
work with WebExtenstions.

If not, then say hello to people staying with firefox 56 for years.

~~~
tversteeg
There is a native vertical tab feature in Test Pilot, the downside is that it
doesn't support nesting (yet?).

~~~
Illniyar
What is Test Pilot? Another release channel?

------
anotheryou
Old or complex add-ons are what keep me with firefox. Will switch to
qutebrowser¹ and probably chrome as my backup for what the cutie can't handle.

¹keyboard goodness: [https://github.com/The-
Compiler/qutebrowser](https://github.com/The-Compiler/qutebrowser)

~~~
akkartik
Thanks for that pointer! I've been off Firefox for the past six months since
they broke my private feedreader extension[1]. I'd been using Opera but I'm
typing this out on qutebrowser.

[1]
[https://news.ycombinator.com/item?id=11287049](https://news.ycombinator.com/item?id=11287049)

~~~
anotheryou
It's still quite young and you feel it at times, beware :)

~~~
akkartik
Yes, I'm going in with eyes wide open :)

Some experiences:

a) Copying HN links doesn't work. All you get in the clipboard is "/item".

b) Google Drive is utterly unusable.

c) Facebook is mildly unusable. Rendering gets easily messed up.

d) No password management.

But these are fairly minor, I'm happy to use a secondary browser for them.

------
BoringCode
As an addon developer, this annoys me. I've had to port my addons to different
APIs twice in the last couple of years. Hopefully this is the end for a while.

------
dbalan
Slightly OT: There is another problem that most people seems to miss. Add-ons
in their current form in ff are tightly coupled to the browser to the point
that it's the browser itself. In the modern web, the browser knows too much
about you, and so does the add-on, and it's not unheard of them to explore
it[1]

How does that free webpage to PDF converter add-on make money? By selling your
web history of course.

[1] [https://www.google.de/amp/thehackernews.com/2016/11/web-
of-t...](https://www.google.de/amp/thehackernews.com/2016/11/web-of-trust-
addon.html%3famp=1)

EDIT: added OT tag

~~~
jhasse
Web history is also available to WebExtensions, so I don't see how this is
relevant to people missing XUL/SDK addons?

~~~
dbalan
Added OT tag, I was not comparing webextensions, pointing out, this is still
an unsolved problem.

------
newscracker
I hope the "end of 2017" deadline is flexible to change based on what's
supported and what's not supported for current extensions. As people have said
on the comments on the Mozilla blog post, Firefox will die without the popular
extensions, of which there are many. Even today, Firefox extensions are far
ahead of extensions on other browsers in what's available and how well they
function.

------
bitL
If I can't use Ghostery, Blend In, No Resource Leak (or they are watered
down), I see no use for Firefox. Please Mozilla, don't kill some of your
biggest attractions! You copied UI from Chrome, now you are copying Add-Ons,
why would anyone need to use your product then? Aren't you shooting into your
own feet? When are you going to pull off Opera and just skin Chrome
differently?

------
Grollicus
Man I will be so sad if they finally manage to kill TreeStyleTabs

~~~
Manishearth
See
[https://news.ycombinator.com/item?id=13031013](https://news.ycombinator.com/item?id=13031013)
regarding Tree Style Tabs. I suspect it will work in the new system.

------
smonff
Firefox was supposed to be "slow" and they are trying to fix it radically with
projects like e10s and Quantum.

If the browser is able to eat my RAM a bit less, I would be quite happy to
have my add-ons off for some time.

------
Animats
_" By the end of 2017, and with the release of Firefox 57, we’ll move to
WebExtensions exclusively, and will stop loading any other extension types on
desktop. To help ensure any new extensions work beyond the end of 2017, AMO
will stop accepting any new extensions for signing that are not WebExtensions
in Firefox 53."_

Based on Mozilla's track record, that's too soon. It took about three years
after the announcement of the Jetpack API before it worked right.

------
dvh
RSS reader, Another RSS reader, Dictionary, something for user scripts, domain
white list, Another dictionary, Gmail checker, uBlock origin. 4 of those
extensions are my own. NIH much :(

------
Aardwolf
I'm a bit worried that some lesser known extensions will be unimplementable...
Would the following still be implementable?

"Open in Browser", which allows ignoring "content-disposition:attachment" to
display pdf/image/txt in browser rather than save to disk

"Android Text Reflow", which allows wrapping text to fit the screen on Android
after zooming in on a web-page

"Status-4-Evar", which adds back the status bar at the bottom of firefox

Thanks!

------
wiiittttt
Only accepting WebExtension based add-ons while not yet fully implementing the
Chrome API seems like it would lead to a large number of unsupported add-ons.

------
speps
Anyone knows about the fate of SeaMonkey? It's still based on XUL as far as I
know and supports a lot of existing Firefox extensions.

~~~
mgbmtl
There are constant references on forums to how they want to move away from
XUL, for both Firefox and Thunderbird. XUL works, but I feel like very people
are able to improve the guts of XUL, and that can be a huge risk for the
future of the project. Pale Moon seems to be the main contender willing to
maintain XUL, but presumably not improve it (changes to XUL can break
extensions).

As someone working on another free software project with an aging code base,
we see this debate all the time: limited funds, limited interest to maintain
the old core, but users rely on it. However, users also want performance
improvements, more reliability, new features... not to mention what do you do
when security issues pop up. At some point you need to cut your losses and
find a model easier to maintain.

~~~
hsivonen
Has anyone taken the Firefox security advisories since Pale Moon forked and
checked how well Pale Moon has addressed the vulnerabilities?

------
threepipeproblm
People inside institutions tend to have trouble admitting when they're wrong.
They basically don't do it. So I fear for the worst with this.

Could be some kind of effort to fork the code and have users who care about
Firefox rally around a non-hobbled version?

------
HemantPawar
So they are going to scrape their best selling feature. I'm just curious to
know why you will use Firefox over Chrome? Privacy from Google?

------
brudgers
What, if anything, does this mean for GreaseMonkey?

~~~
duskwuff
Tampermonkey works fine on Chrome, so probably very little.

~~~
brudgers
TamperMonkey is not equivalent to GreaseMonkey in terms of development
workflow because TamperMonkey stores scripts in a database and pretty much
requires use of its built in editor which is of 'built-in-editor' quality. On
the other hand, GreaseMonkey stores scripts in files and therefore allows any
editor/IDE to be used in the development workflow.

Because scripts are stored in a database, TamperMonkey does not play
swimmingly with GIT either. Finally, TamperMonkey is a third party tool that
from time to time asks for money. GreaseMonkey is open-source.

The TamperMonkey EULA:

 _Your right to use Tampermonkey continues until terminated by the Company,
which may terminate this Agreement and your license to use Tampermonkey at any
time, without cause and without notice. You may terminate this agreement at
any time by uninstalling Tampermonkey. This Agreement will automatically
terminate if you fail to comply with any of the terms of this EULA. Upon
termination, you agree to stop using and to uninstall Tampermonkey._

------
jmiserez
Wondering if/how Zotero and similar applications will exist beyond 2017. Will
they need to fork Firefox?

~~~
_lm_
Zotero will work the way it does with Chrome now: there will be a plugin that
integrates with Zotero Standalone, which will continue to be developed using
XULRunner.

I think this will be good in the long run--Zotero is complex enough to merit
being its own application, and separating Zotero and browser plugins will make
it easier to migrate Zotero off XULRunner at some point, if the developers
choose to do so.

