
Let’s Write a Firefox Web Extension - cpeterso
https://hacks.mozilla.org/2015/09/lets_write_a_webextension/
======
Mindless2112
So killing off XUL is great and all, but two of my favorite add-ons [1] [2]
are already planning to call it quits because the Web Extension API likely
won't be powerful enough. Tree Style Tab isn't far behind, I'll bet. These
add-ons are the reason I use Firefox.

It seems like Firefox is going to become just another browser.

[1] [http://www.downthemall.net/the-likely-end-of-
downthemall/](http://www.downthemall.net/the-likely-end-of-downthemall/) [2]
[https://github.com/sparhami/BeQuiet/issues/2](https://github.com/sparhami/BeQuiet/issues/2)

~~~
javajosh
Oh come now, that's not fair. Sure _XUL_ can't be the key to a good extension
mechanism. If devs stop writing (or choose not to port) it's because of the
economics of Firefox extensions, which is to say, _there are no economics to
writing Firefox extensions_. Except some minor reputation points and feel-good
points. (The exception, of course, being those add-ons that make a SaaS more
usable.)

Out of curiosity, if there was a Firefox App Store, how much would you pay for
Tree Style Tabs?

~~~
yellowapple
> Out of curiosity, if there was a Firefox App Store, how much would you pay
> for Tree Style Tabs?

Probably a few bucks. TST is pretty fundamental to my Firefox workflow.

~~~
Qantourisc
Well according to Mozilla TST has 100 000 users. At a few bucks that's 300
000$ I suppose that could be enough :) With that money you can even maintain a
separate Firefox patch-set to allow the plugin to work.

------
mindcrime
It would be pretty awesome if we can get to a place where browser extensions
are truly cross-browser. At least for some definition of "browser extension".

I'd be OK with a "common core" that's cross-browser, and the browser makers
continuing to support their own extension APIs as well, IF the "core" API
never becomes as powerful as the old, native APIs. I'd hate to see the native
APIs go away completely though, as I don't like the idea of artificially
restricting the range of possible plugins.

Then again, I am already annoyed by Chrome ditching NPAPI and leaving us in a
place where, AFAIK, you can't run the Java plugin in Chrome. OTOH, JWS still
works (I think) which is something at least...

~~~
FreakyT
To be fair, no one should be using Java applets in this day and age, and
hopefully this will finally kill them off for good.

~~~
drdeca
Though, now you can't make certain types of sockets in browser...

~~~
mmebane
Nor can you integrate with the local filesystem, or call native APIs. With a
hidden Java applet, it was pretty easy to make a full-fledged application that
just happened to have a web-based API. That's getting a lot harder.

Chrome extensions have an API called Native Messaging which is roughly the
postMessage API over stdin/stdout. It works, but isn't cross-browser.
Alternatively, you can start up a local server and make XHR or WebSocket calls
to localhost. However, both of those require the user going through an
external install process. Maybe, in the current security landscape, that's the
way it has to be, but it's kind of annoying.

------
kuschku
Now someone just needs to write a small converter that instantly converts an
existing Chrome extension for Firefox, and a script that allows people to
install from the Chrome market, too, and instantly the available extensions
for both browsers doubles.

~~~
nathancahill
It's been tried[0][1][2], but doesn't work very well. Similar to how PhoneGap
tries to create a cross platform solution, it will always feel kludgy compared
to developing with native APIs.

[0] [http://kangoextensions.com/](http://kangoextensions.com/)

[1] [http://crossrider.com/developers](http://crossrider.com/developers)

[2] [http://crossbrowser.com/](http://crossbrowser.com/)

~~~
kuschku
Well, with this new API Chrome extensions run natively in Firefox, if one adds
a single tag to the metadata json file.

So, doing this should be easy.

~~~
nathancahill
I wouldn't phrase it like that. Instead, Firefox is implementing a similar
extension API, which overlaps with Chrome and Opera's APIs. What you
described, "instantly converting an existing Chrome extension for Firefox" is
a long ways off.

There's a lot of gaps in Mozilla's implementation right now. To do anything
interesting (beyond cat gifs), you have to fall back to the old
QueryInterface/ns* APIs.

~~~
voltagex_
Are we still allowed to use the old APIs?

See [http://www.downthemall.net/the-likely-end-of-
downthemall/](http://www.downthemall.net/the-likely-end-of-downthemall/)

~~~
nathancahill
From the original post[0]:

> 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.

[0] [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/)

------
Tobu
At the moment there are more gaps than API and the debugging experience is
such that you have to go back and forth between Chrome (debugging any changes
you made) and Firefox (looking at the global console, checking that you're
within the small supported subset).

Recommending gulp is ridiculous overkill. Chrome loads files from disk
directly, Firefox plans to.

------
stewbrew
... and in FF50 they'll replace gecko with blink to be on par with chrome and
opera.

Seriously, I use firefox because of its addons, for which no equivalent exists
for chrome, e.g. downthemall, shelve, tiddlyfox. As it looks there is little
chance, these addons will continue to work with future releases of ff. So why
should I continue using FF?

------
lemevi
Any break from the XUL days are a huge plus. XUL gives you so much power but
is very unsafe for the users since anything goes and that system is also very
poorly documented. I sometimes had to look at the Mozilla source code to
understand what was possible with the XUL based extension system. Now that we
have a really great set of native dev tools inside Firefox maybe we don't need
XUL anymore? I say that because maybe something like Firebug isn't possible
without XUL.

------
mtgx
> _The only thing I would add is that while Mozilla is implementing most of
> the API that Chrome and Opera support, we’re not restricting ourselves to
> only that API. Where it makes sense, we will be adding new functionality and
> talking with other browser makers about implementing it as well._

At least focus on making it possible to do secure communications inside a
browser, where for instance you may not want to trust the service provider and
want to do the crypto locally. I know for instance that Nadim Kobeissi was in
the past praising Chrome for its packaged apps and how they allow better
security for Cryptocat than Firefox does. Make extensions such as Mailvelope
be at least as secure as native apps.

Focus on stuff like that rather than enabling extensions to change how the
browser looks, which likely introduce their own security vulnerabilities by
design (I know many have cried about stuff like that when you announced
deprecating the old add-on model).

Maybe even do that with browser components that are written in Rust. Speaking
as a Chrome user and very occasional Firefox user, the more Rust you use the
higher the chance you'll have to convert someone like me who cares about
security and continues to choose Chrome based on that. The sooner your
sandboxing architecture is on par with Chrome's the better as well.

Someone like me is not "just a niche". It's also the type of person that
recommends (evangelizes even) a browser or app to every single friend he has.
Don't forget that's exactly how Chrome "beat" Firefox, if I can say that - by
winning over the evangelists.

~~~
ferongr
Chrome won by being bundled as shovelware into Windows installers.

~~~
cpeterso
For example, Chrome was bundled in Adobe's Flash Player installer (in addition
to Chrome bundling the Pepper Flash plugin).

------
haddr
Really looking forward to some sort of interoperability between browsers
plugins between Chrome and Firefox. That would be really great. However my
intuition tells me thats going to be quite difficult. Not only from the
technical point of view but also the perspective of developers of existing
extensions... Would there be some common extension repository? What if someone
takes somebody else's Chrome extension and puts it in the FF repo as his own,
etc...

------
darklajid
Wait. Isn't that the browser¹ that requires you to use an online certification
process to install even your own addons/developments, unless you're on a
Nightly version and change a hidden setting? _skims the article_ Ah yeah, they
avoid the subject by using Nightly anyway due to the changing API. Note that
any build other than Nightly won't let you install unsigned extensions,
period. Not by changing about:config values or in any way for form I'd know
about.

①: Firefox fan forever. Since they decided that no, you are not allowed to
install your own build of Vimperator/TST etc. without a signature from
Mozilla, I'm looking for alternatives. Unfortunately there's no real
competition, it's either Chrome or FF - and FF seems to move into directions I
don't like.

~~~
kevingadd
You can install unsigned addons in Developer Edition. I've been using
Developer Edition as my primary browser for over a year. If you're the kind of
power user that needs to install unsigned extensions, it's a pretty reasonable
compromise...

You can always build release channel from source.

Adding a pref to release/beta for this would defeat some of the purpose of the
feature - bad actors always find ways to install their shitty extensions into
the browser. When the browser does signing checks before loading them, that
raises the challenge significantly vs. setting some prefs and dropping a file
in the right place.

Chrome has a similar extension policy. Edge probably will too. History has
shown that nothing less than this will cut it. :-(

~~~
darklajid
I feel that Developer Edition would solve my problem.

That said: Building FF from source takes ages. It's not something I like to
do, honestly, to build/package/install a couple of JS files.

And I do think that this is a crappy idea. Okay, require signatures if you
want to install something directly from the web, maybe? But if I point that
thing at a .xpi file, locally, let me install that. Hide it behind a flag in
about:config, but let me install that.

Saying 'ah, but someone might toggle that box for you' is weird and reminds me
of Raymond Chen's 'Wrong side of the hatch' security reports. If you can do
that, if your installer can mess with my about:config, why can't it f __* up
my whole system?

A free idea for malware distributors: Bundle your own release channel build of
FF and just remove the official one, keep the user's profile. Your MSI runs
elevated, I'm reasonably sure I could do that ~somewhat easily~, if you make
your money with shady stuff you're bound to make this work. Tada! Every
extension can be installed again, please add a couple useful and set a decent
home page.

The premise is crap. The implementation is unfortunate and follows the
premise.

(Again: Thanks for the DE hint. That's listed in [1] as well, I must have
missed that in the past and - Nightly isn't exactly what I want to run on a
daily basis. Or at least not as my main browser, a side by side install is
often present on my machines)

[1]:
[https://wiki.mozilla.org/Addons/Extension_Signing](https://wiki.mozilla.org/Addons/Extension_Signing)

~~~
kevingadd
Bad actors in this case are not exclusively malware authors. Among others,
they include the developers of Skype, Java, Adobe Acrobat, most antivirus
software...

EDIT: For a more specific example, at various points in the past local native
apps like uPlay have been exploitable such that random websites could drive-by
execute scripts or download malware. Pretty much any native app (legit or not)
could potentially load an extension or install a protocol handler that lets a
random website own your machine.

------
_ZeD_
from the article: >>> [...] I think it’s time to add a build script. I hear
that the go-to build tool these days is gulp, so I’ll wait here while you go
install that, and c’mon back when you’re done. (I needed to install Node, and
then gulp twice. I’m not sure why.)

what should have been:

I hear that the go-to build tool these days is gulp, but fuck gulp and use
make.

