
WebExtensions FAQ - jtgeibel
https://wiki.mozilla.org/WebExtensions/FAQ
======
sugarfactory
The author of Tree Style Tab has commented (in Japanese) on the change to
deprecate add-ons making use of XUL. [1]

Roughly what he said might be summarized as follows (sorry if I misunderstood
his intention): Tree Style Tab is useful because the add-on changes the
behaviors of the tab globally. That way, it can cooperate with other tab-
related add-ons whose authors didn't intend to make the add-ons work with TST.
Therefore providing the Sidebar API doesn't help because you can't expect add-
on authors to write code just to make add-ons work better with TST.

[1]:
[https://twitter.com/piro_or/status/635078508981555202](https://twitter.com/piro_or/status/635078508981555202)
[https://twitter.com/piro_or/status/635079271032090624](https://twitter.com/piro_or/status/635079271032090624)
[https://twitter.com/piro_or/status/635079995371556864](https://twitter.com/piro_or/status/635079995371556864)

~~~
ZenoArrow
Consider the long term strategy.

At this moment in time, Firefox relies on XUL for both the Firefox UI and its
extensions. Mozilla wants to move away from using XUL. What's the sensible
approach for this?

In my opinion they're doing exactly what they should.

Step 1. Offer new extension APIs that are compatible with other browsers and
decpreciate XUL.

Step 2. Encourage existing XUL-based extensions to be rewritten using the new
APIs.

Step 3. After the majority of well used extensions use the new APIs, rework
Firefox to drop XUL and use web technologies for the UI.

Step 4 (Not confirmed, but could happen). After the new Firefox UI is stable,
offer lower level APIs to give further control over the UI.

I can't see a better way of moving away from XUL.

~~~
wldcordeiro
I think a smarter approach would be introduce this new API and only deprecate
the portions of XUL that haven't been replicated in the new API. Once you
reach parity you do the rest as you suggest.

~~~
ZenoArrow
Depreciating functionality doesn't mean the functionality goes away
immediately, it just means it's not recommended to use.

Mozilla isn't stopping people from using XUL by depreciating it, they're
suggesting that developers should avoid it, as it'll eventually be taken away.
The two extension systems will both be available until a sufficient portion of
Firefox extensions have been migrated over to the new APIs.

Or to put it in another way, good news, they're doing what you said!

~~~
joshuacc
I think you mean deprecating, not depreciating. :-)

~~~
ZenoArrow
Yes. :-)

------
examancer
Currently developing a Chrome extension I was dreading porting to Firefox. I
am glad this is coming. Microsoft is also promising a mostly-Chrome-compatible
API for Edge browser extensions.

This will mean my extensions for all three browsers can mostly share the same
code. Since they use pretty standard HTML/CSS/JavaScript much of the code will
also be shared with my app's traditional web services. This sounds like a huge
win for bringing rich, native-like experiences to all browsers.

Would be great to see all browsers support a common extensions API. I hope
WebExtensions is that API.

~~~
jakozaur
Got similar experience. Writing your first extension for Chrome is reasonable
easy, but it is nightmare for Firefox.

I'm glad developers (Edge, Firefox) copy the good model, rather than trying to
reinvent the wheel. Even without strict compatibility it would be much easier
to do support many browsers, since plugin platform will be conceptually
similar.

------
mnarayan01
I like Firefox. A _lot_. And I think there are a number of ways that the core
(i.e. non-extension based) functionality is superior to that of e.g. Chrome.
That said...the reverse is also very much true.

When Firefox loses the extensions which require XUL (whether fundamentally or
merely to avoid rewrites) I doubt its upsides will outweigh its downsides for
me anymore. They may surprise me, and even if they don't they still might
increase usage with _other_ people, but right now I am sad.

~~~
greyskull
> And I think there are a number of ways that the core (i.e. non-extension
> based) functionality is superior to that of e.g. Chrome

Like what? Genuinely curious.

~~~
ishansharma
I am a Firefox user and there are couple of core functionalities that keep me
with it instead of Chrome(or Opera/Safari)

1\. Tab Groups: This is a must have for organizing tabs and keep me sane with
30+ tabs open. 2\. Lazy loading: I am not sure if Chrome has it or not but FF
doesn't load a tab content until I switch to it. I can regularly have a lot of
tabs open without all of them using resources.

~~~
gioele
> 2\. Lazy loading: I am not sure if Chrome has it or not but FF doesn't load
> a tab content until I switch to it.

This is usually transparent to me. Except when I am on a train and realize
that all the tabs I have opened in the background have never been loaded. :(

For this and other reasons I have removed tabs from my workflow, now I use 90%
maximized or half-screen windows. It is also easier to alt-tab between them.

~~~
hvis
You can simply uncheck "Don’t load tabs until selected" in the General section
of Preferences.

------
TazeTSchnitzel
The mention that they plan to remove XUL usage within Firefox (which is a good
idea) is interesting. That's an extra justification for the change of
extensions approach (the one we knew before was e10s).

Looks like they realised that to keep moving forward, clean up technical debt
and fix longstanding issues, they'd unfortunately break almost all extensions
in the process. And if that's the case, they might as well switch to a better
API while they're at it. It's painful, yes, but Firefox is still a slow,
unstable and memory-guzzling behemoth, where all your extensions break on
every update. This won't change if they stick with single-process, XUL, XPCOM
and the existing extension model.

I am optimistic. I think Firefox can and will survive this. Look how well
Apple's Mac OS to OS X transition went. Mozilla are willing to help people
port extensions. And their timeline is probably unrealistic, but it can be
pushed back. In two or three years, Firefox will be a world-class browser
again, and we will look back at the panic we had now and laugh.

~~~
justinmk
> In two or three years, Firefox will be a world-class browser again, and we
> will look back at the panic we had now and laugh.

I was hoping Servo would be their flagship in 3 years :/

~~~
kibwen
Servo is just the browser engine, an alternative to the component known as
Gecko in modern Firefox. Mozilla isn't going to drop the Firefox brand even if
they do end up replacing Gecko with Servo (which is hardly guaranteed). Though
if anything, the move here makes it more plausible that such a switch could
happen, because the whole XUL situation is probably the single largest blocker
for a Servo-based Firefox. A standardized extensions API would also give Servo
a free extensions ecosystem with minimal effort, especially if Mozilla pursues
a GUI based on browser.html which could be shared with Servo immediately.

~~~
cpeterso
> Mozilla isn't going to drop the Firefox brand even if they do end up
> replacing Gecko with Servo

Microsoft rebranded IE as Edge to jettison both technical debt (like ActiveX)
and IE's bad reputation. Conveniently, IE and Edge both have blue "e" icons so
users are not confused. :) I wonder if Mozilla could successfully launch a
Servo-based browser product with a new name to distance it from Firefox's
historical reputation for memory leaks and broken extensions.

~~~
sanxiyn
Doesn't Firefox have a reputation for using less memory than other browsers
these days?

~~~
icebraining
I don't think so, the reputation still hasn't matched the reality :)

~~~
oblio
I've definitely seen a lot of discussions where Chrome is considered a memory
hog compared to Firefox. At least in the last 2-3 years.

------
Guzba
I work on an extension for Chrome, Opera, Safari, and Firefox that's pretty
widely used. Firefox (Jetpack) is so different from the rest that I basically
hate working on it.

I get that some people may love XUL and whatever, but having never used it, I
can't really comment. All I do know is that Jetpack (which Firefox has been
pushing) is a sorry excuse for a way to build extensions after you've worked
with Chrome. I really hope WebExtensions makes my life easier soon.

~~~
drethemadrapper
They (Moz. dev team) have now even gone wild by hiding the Addon SDK from
developers. It's not on their servers but buried in github, covered by several
versions of a new app./development tool. It took me a long time to locate it.
It all appears that they don't want us to use it (perhaps because of the cfx
they are deprecating for jpm). Yet, a developer needs it to upgrade or develop
their (new) extensions ( xul->bootstrapped extension with/without the sdk
lib.). On another note, extension development is now like a node app. dev. --
their directory structures now look like. It's funny yet interesting
(standardizing addon dev.??).... This whole gospel about the SDK is a way of
hiding the details/core of the FF browser from developers - ending the use of
XUL/XPCOM, going HTML, e.t.c. Perhaps, Moz. needs to help make extension dev.
easy for 'web designers'.

~~~
asmicom
I can confirm the increase in difficulty of writing FF extensions these days.
There is no ONE go-to source for information.

------
hackuser
Also, NoScript developer Giorgio Maone's take on WebExtensions:

[https://hackademix.net/2015/08/22/webextensions-api-
noscript...](https://hackademix.net/2015/08/22/webextensions-api-noscript/)

------
Animats
XUL/XPCOM have been on the way out for years, because Fennec, the mobile
version of Firefox, doesn't have them. Jetpack extensions work fine in both
desktop and mobile versions, though, and it seemed that the future was
extensions to Jetpack. Jetpack isn't all that great, but after five years, it
more or less works.

Being compatible with Google Chrome isn't very important. Extensions aren't
used much on Chrome. I have the same extension for Chrome and Firefox, and
Firefox usage is 100x greater.

------
hardwaresofton
Super glad to hear this -- I created a small chrome extension a while ago and
found it a joy to code (very easy, with a distinct lack of surprises), and
when I looked into creating a similar Firefox extension, the idea of learning
XUL was enough to shut down the idea of a port very very quickly.

Maybe I'm just lazy, but I was very surprised to find that Firefox would
create such a technology when more "open web friendly" solutions were
possible. I'm sure it's just that XUL is a vestige of a time when the web was
still young, but I am going to wait until Web Extensions are released before I
attempt to write any extensions for Firefox.

Are there any reasons to keep XUL around (other than lack of apps that were
written with it)? It doesn't seem like there are any unique features that
couldn't be reproduced using something like chrome's model...

~~~
kbrosnan
XUL will be around for a while. Porting the browser UI to HTML is not trivial.
There is a proof of concept on github but it is just that. The performance
tuning that has been done over the years for XUL desktop applications is not
matched by similar designs in HTML. That and extension compatibility are the
current reasons to keep XUL around in the short and medium term.

------
kristofferR
I really hope WebExtensions will be capable of the type of extensions that is
currently exclusive to Firefox, like Tree Style Tabs and DownThemAll, although
I doubt it.

If not I'll keep using the last version with proper extension support for a
long time, until an alternative comes.

~~~
steve-howard
I absolutely agree. This FAQ didn't answer the one Q that's most important to
me, which is whether providing enough power to remake Tree Style Tabs and
extensions like it is a goal.

~~~
Qantourisc
That seems to be answered in "Which add-ons will stop working when XUL/XPCOM
is deprecated?" Also a question in IRC someone basically said: noscript won't
work yet with the current API, and we are working with extension devs to make
things possible.

------
protomyth
"It sounds like you've made decisions without community input, why?"

I guess it's good that they acknowledge that they didn't get input from those
that write extensions before they made this decision.

~~~
cpeterso
When should they have asked for community input? They have announced the
project and are now responding to community input.

~~~
jacquesm
They can't really respond to community input because the key decisions have
already been made. They can only respond to criticism, but the time for input
is clearly _before_ making key decisions.

------
devsquid
"The Chrome extension API was designed to work well with process separation
and we are taking inspiration from it and copying functionality where it makes
sense. However, there will be differences, and the goal of WebExtensions is
not to copy Chrome or allow Chrome extensions to run unmodified in Firefox,
but to simplify cross-browser development by providing commonly-supported
methods and interfaces. We won't implement all of Chrome's APIs, and Chrome is
unlikely to implement some of the APIs we add. Imagine the APIs as a Venn
diagram. In the middle are cross-browser APIs for content scripts, tabs, and
windows. In the Firefox side are APIs for toolbars and other UI elements. On
the Chrome side are APIs for Google's cloud services."

Reading that made me extremely happy! I'm glad to see cross compatibility is
still a goal for browsers.

------
pasbesoin
For me, this boils down to, "Whose client is it?"

One reason I've liked and used Firefox is that, especially with extensions, it
has been more "my client".

Amidst all the noise over this change, I read into it that -- to some degree
-- it is becoming less my client.

Which, to me, seems like another step in Chrome's direction, where I've felt
that the client is increasingly the advertiser's client. (And the DRM pushers'
client, etc.)

Being _my_ client is what, for me, Firefox has had going for it.

It's _my_ PC. On which I wish to use _my_ client, handling and presenting data
in the manner in which _I want it handled._

------
Qantourisc
Say what is going to happen to Thunderbird's plugins ?!? Cause breaking those
would actually be worse then breaking Firefox !

~~~
TazeTSchnitzel
Thunderbird's in "community" development now. It'll probably keep with XUL and
XPCOM and all that garbage forever.

------
jasonhansel
Still no support for unsigned extensions? :(

~~~
azakai
The default builds won't support them, but there will be other builds you can
download that do. Also, Nightly and Dev will have an option as well.

------
paulryanrogers
As an extension author this is disappointing. For all the hate XUL gets, it
was a powerful tool to manipulate the UI. Hopefully the new API will be as
empowering as the old without the same risks. And ideally this will happen
before the old APIs are completely removed.

------
mrbig4545
I am looking forward to this. The way I see it, it's all preparation for
servo.

And I'm sure the extensions to the webextensions api will provide enough to do
what needs to be done

------
yoodenvranx
I _love_ the multi row tab feature of TabMix Plus. I hope something like this
will be possible with the new API.

------
vdfs
I hope they use the same API from Chrome for plugins like Flash.

~~~
TazeTSchnitzel
NaCl, Pepper and PPAPI are never coming to Firefox, that's for certain.

But web plugins are fast becoming obsolete, so it hardly matters.

------
curiousjorge
could I port a chrome extension to firefox now?

------
DonGateley
As could be expected this has poked a hornets nest of opposition because of
its implications regarding backward compatibility of extensions we use. Many
of us are hoping for a fork based on the current release that will continue to
evolve and be maintained and which values backward compatibility first and
foremost.

Users can snapshot the current 40.0 release by copying the installation
directory and creating a cloned profile for it with updates disabled.
Personally I find the 42.0a2 development channel release to be backwards
compatible with all extensions and to have superior memory management.

~~~
geofft
Are you hoping for a fork more than you're hoping for all your extensions to
be ported (or reimplemented by different people) on the new model? I bet this
is super frustrating for established extension authors, but as a user, I bet
there are enough users that the demand will be there for all the common
extensions.

Anyway, if you're staying on an old release, _please_ use Firefox 38 ESR (or
switch to the ESR at Firefox 45, on the assumption that this change won't be
complete by March). Sticking with Firefox 40 and disabling security updates
seems like a terrible terrible idea.

[https://www.mozilla.org/en-
US/firefox/organizations/faq/](https://www.mozilla.org/en-
US/firefox/organizations/faq/)

