22 ms·

WebExtensions FAQ

177 points by jtgeibel 11y ago

phaed 11y ago
Yeah, no thanks. After that line in the sand the CEO drew supporting radical feminism, I don't see myself touching another Mozilla product. Not planning on updating any of my extensions.
- untog 11y ago
  Yes, how dare he say that an employee being abusive towards another employee is unacceptable. How very dare he.
  - phaed 11y ago
    > Employee: When she and the rest of her blue-haired nose-pierced asshole feminists are gone, the tech industry will breathe a sigh of relief > CEO: "When I talk about crossing the line from criticism to hate speech, I'm talking about when you start saying 'someone's kind doesn't belong here, and we'll all be happy when they're gone.'" > CEO: So if and when we identify who this person is, if they are an employee, they will be fired. And regardless, either way, they are not welcome to continue to participate in the Mozilla project. It is not who we are. Notice how he says when someone says "someone's kind doesn't belong here, and we'll all be happy when they're gone." is hate speech. Yet in the next sentence he says the very thing about the anonymous employee's kind. The only difference here is that she is a radical feminist, and the employee simply expressed his relief at her kind leaving, as she was a permanently offended well known bully of a supervisor and a source of stress for everyone under her. It is funny how people are not allowed to openly have a negative opinion of another person if they are a "protected" class or just not a white male. When you stand up for the bully simply because they are feminist, you know something is wrong. Either way this all left a bad taste in my mouth. I won't be supporting this organization any longer.
    - JoshTriplett 11y ago
      https://en.wikipedia.org/wiki/Paradox_of_tolerance https://en.wikipedia.org/wiki/Paradox_of_tolerance If you're tolerant of everything, including intolerance, you end up supporting intolerance. Or, in short, it's perfectly fine to kick people out for being hateful. There's no inconsistency or hypocrisy in that position.
      - cpeterso 11y ago
        People are getting hung up on pedantic definitions of "hate speech". If we say "hostile work environment" instead, then the anonymous poster's behavior clearly crosses the line. The response is not unique to Mozilla. Big companies like Google have probably encountered similar situations. Mozilla is just more open about it.
    - foiboitoi 11y ago
      Can't you use the browser without supporting them? I don't like the hypocrisy either but I love the browser (mostly). I do wish the engineers got back into management positions instead of these clueless politicians.
      - TazeTSchnitzel 11y ago
        Engineers don't necessarily share your political leanings.
        foiboitoi 11y ago
        I don't care about their political leaning. Politics doesn't belong in the work environment, especially for management. That includes every "political leaning". Not just the ones we don't like.
        TazeTSchnitzel 11y ago
        No, you do care about political leanings. There's always going to be office politics. What you perceive as "politics" is politics you dislike.
protomyth 11y ago
"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.
- ender7 11y ago
  Everyone knew what the feedback from existing extension authors would be. Asking for "feedback" that you know you're going to ignore seems more disingenuous that just admitting that you have to make a decision they don't like.
  - hobs 11y ago
    I don't think they admit that in the document. I am a bit cranky over the entire thing, while I can understand the devs think this will be cleaner code, it sounds like a lot of time spent on working on things to get back to the status quo. From the article: "It sounds like you've made decisions without community input, why?" "We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity. We need to find a way to do that. We have announced WebExtensions and the deprecation as early as possible so that we can get feedback from the community on how to make the transition. We know that WebExtensions will need to be improved. To innovate will require input and assistance from the community, which we are actively seeking. The path for WebExtensions will evolve in the coming weeks, months, and years, and we want the developer community to be a big part of that evolution." Let's break this apart a bit. They think its a necessity, so they did not ask others? I don't think this is anything but ignoring the question. They then go on to ask for help so that they can spend a bunch of time to return us to a status quo with less working extensions today, and continue to say that you should postpone development for a Firefox extension if you are thinking about working on one, "for a few months." Might as well start targeting Chrome since you cant even rely on FF to have a reliable API to even build a new extension against for a year. Not to mention all the time and energy spent learning XUL's magical inner workings all gone to rot. I guess there must be some HUGE technical impetus for this, because from my personal user perspective it seems mind bogglingly wasteful of time and resources.
TazeTSchnitzel 11y ago
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 11y ago
  > 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 :/
  - lern_too_spel 11y ago
    Servo would replace Gecko, not Firefox.
  - kibwen 11y ago
    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.
Animats 11y ago
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.
mnarayan01 11y ago
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.
- RubyPinch 11y ago
  Surely any maintained XUL related addons will survive this change, due to being maintained, no?
  - steve-howard 11y ago
    It's possible that maintainers are willing to make small changes to keep up with recent versions of firefox but are not interested in a ground-up rewrite to accommodate a deprecated framework.
  - mnarayan01 11y ago
    I've heard Tree Style Tabs won't be possible. Given my limited knowledge this strikes me as plausible, but I haven't investigated it at all so don't take my word for it.
    - Osmose 11y ago
      See https://wiki.mozilla.org/WebExtensions#Additional_APIs https://wiki.mozilla.org/WebExtensions#Additional_APIs There's valid criticisms against WebExtensions, but the biggest misconception is that the capabilities of WebExtensions are set in stone and that X or Y addon "won't be possible". The entire point of announcing WebExtensions so early was to start getting feedback on what needs to be supported to make major and useful addons possible, and to start work on a way for experimentation outside of the officially supported spec to still happen.
DonGateley 11y ago
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 11y ago
  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/
Guzba 11y ago
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 11y ago
  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 11y ago
    I can confirm the increase in difficulty of writing FF extensions these days. There is no ONE go-to source for information.
examancer 11y ago
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 11y ago
  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.
- odiroot 11y ago
  As another cross-browser extension developer I too welcome this change. Firefox Add-on SDK was at best annoying and so inconsistent -- some APIs being sync and some async etc. I had to prepare an elaborate build system to have a single codebase (well, excluding Safari which is even worse). Now it'd be possible to move pretty far with Chrome/Firefox/Opera/Edge without the need to hack around the differences.
- flanbiscuit 11y ago
  Same here. Made my own personal extension on Chrome and was avoiding making it for Firefox because of how widely different it was. So I welcome this change. I'm sure it'll piss off some folks who have already put a lot of time into making a FF extension, you can't please everyone. I think in the long run this is a good thing. There is a library made by the guy who created the Reddit Enhanced Suite that helps you create cross browser extensions right now. I've never used it but it did look very promising: https://github.com/honestbleeps/BabelExt https://github.com/honestbleeps/BabelExt
kristofferR 11y ago
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.
- jacquesm 11y ago
  I couldn't get through my workday without tree tabs, it's the equivalent of an organized desk for me and without it I'd be thoroughly lost.
- steve-howard 11y ago
  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 11y ago
    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.
- icebraining 11y ago
  Same here; Tree Style Tabs and Vimperator are indispensable, new HTML/CSS/JS features are not.
- pvdebbe 11y ago
  Same here. I'm very concerned that the new framework might reduce the extensions' capabilities down to Chrome's level. It's highly unusable -- for instance, in Chrome/Chromium they don't allow the user to manipulate New tab page, and there goes all the Vimium bindings when you try to navigate it over.
hardwaresofton 11y ago
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 11y ago
  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.
hackuser 11y ago
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...
Qantourisc 11y ago
Say what is going to happen to Thunderbird's plugins ?!? Cause breaking those would actually be worse then breaking Firefox !
- TazeTSchnitzel 11y ago
  Thunderbird's in "community" development now. It'll probably keep with XUL and XPCOM and all that garbage forever.
TimeToTroll 11y ago
;D
sugarfactory 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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!
mrbig4545 11y ago
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
devsquid 11y ago
"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.
vdfs 11y ago
I hope they use the same API from Chrome for plugins like Flash.
- TazeTSchnitzel 11y ago
  NaCl, Pepper and PPAPI are never coming to Firefox, that's for certain. But web plugins are fast becoming obsolete, so it hardly matters.
yoodenvranx 11y ago
I love the multi row tab feature of TabMix Plus. I hope something like this will be possible with the new API.
jasonhansel 11y ago
Still no support for unsigned extensions? :(
- azakai 11y ago
  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.
pasbesoin 11y ago
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.
curiousjorge 11y ago
could I port a chrome extension to firefox now?
paulryanrogers 11y ago
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.

177 points by jtgeibel 11y ago

phaed 11y ago

Yeah, no thanks. After that line in the sand the CEO drew supporting radical feminism, I don't see myself touching another Mozilla product. Not planning on updating any of my extensions.

untog 11y ago
Yes, how dare he say that an employee being abusive towards another employee is unacceptable. How very dare he.
- phaed 11y ago
  > Employee: When she and the rest of her blue-haired nose-pierced asshole feminists are gone, the tech industry will breathe a sigh of relief > CEO: "When I talk about crossing the line from criticism to hate speech, I'm talking about when you start saying 'someone's kind doesn't belong here, and we'll all be happy when they're gone.'" > CEO: So if and when we identify who this person is, if they are an employee, they will be fired. And regardless, either way, they are not welcome to continue to participate in the Mozilla project. It is not who we are. Notice how he says when someone says "someone's kind doesn't belong here, and we'll all be happy when they're gone." is hate speech. Yet in the next sentence he says the very thing about the anonymous employee's kind. The only difference here is that she is a radical feminist, and the employee simply expressed his relief at her kind leaving, as she was a permanently offended well known bully of a supervisor and a source of stress for everyone under her. It is funny how people are not allowed to openly have a negative opinion of another person if they are a "protected" class or just not a white male. When you stand up for the bully simply because they are feminist, you know something is wrong. Either way this all left a bad taste in my mouth. I won't be supporting this organization any longer.
  - JoshTriplett 11y ago
    https://en.wikipedia.org/wiki/Paradox_of_tolerance https://en.wikipedia.org/wiki/Paradox_of_tolerance If you're tolerant of everything, including intolerance, you end up supporting intolerance. Or, in short, it's perfectly fine to kick people out for being hateful. There's no inconsistency or hypocrisy in that position.
    - cpeterso 11y ago
      People are getting hung up on pedantic definitions of "hate speech". If we say "hostile work environment" instead, then the anonymous poster's behavior clearly crosses the line. The response is not unique to Mozilla. Big companies like Google have probably encountered similar situations. Mozilla is just more open about it.
  - foiboitoi 11y ago
    Can't you use the browser without supporting them? I don't like the hypocrisy either but I love the browser (mostly). I do wish the engineers got back into management positions instead of these clueless politicians.
    - TazeTSchnitzel 11y ago
      Engineers don't necessarily share your political leanings.
      - foiboitoi 11y ago
        I don't care about their political leaning. Politics doesn't belong in the work environment, especially for management. That includes every "political leaning". Not just the ones we don't like.
        TazeTSchnitzel 11y ago
        No, you do care about political leanings. There's always going to be office politics. What you perceive as "politics" is politics you dislike.

protomyth 11y ago

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

ender7 11y ago
Everyone knew what the feedback from existing extension authors would be. Asking for "feedback" that you know you're going to ignore seems more disingenuous that just admitting that you have to make a decision they don't like.
- hobs 11y ago
  I don't think they admit that in the document. I am a bit cranky over the entire thing, while I can understand the devs think this will be cleaner code, it sounds like a lot of time spent on working on things to get back to the status quo. From the article: "It sounds like you've made decisions without community input, why?" "We believe that moving Firefox away from XUL and XPCOM is a long-term strategic necessity. We need to find a way to do that. We have announced WebExtensions and the deprecation as early as possible so that we can get feedback from the community on how to make the transition. We know that WebExtensions will need to be improved. To innovate will require input and assistance from the community, which we are actively seeking. The path for WebExtensions will evolve in the coming weeks, months, and years, and we want the developer community to be a big part of that evolution." Let's break this apart a bit. They think its a necessity, so they did not ask others? I don't think this is anything but ignoring the question. They then go on to ask for help so that they can spend a bunch of time to return us to a status quo with less working extensions today, and continue to say that you should postpone development for a Firefox extension if you are thinking about working on one, "for a few months." Might as well start targeting Chrome since you cant even rely on FF to have a reliable API to even build a new extension against for a year. Not to mention all the time and energy spent learning XUL's magical inner workings all gone to rot. I guess there must be some HUGE technical impetus for this, because from my personal user perspective it seems mind bogglingly wasteful of time and resources.

TazeTSchnitzel 11y ago

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 11y ago
> 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 :/
- lern_too_spel 11y ago
  Servo would replace Gecko, not Firefox.
- kibwen 11y ago
  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.

Animats 11y ago

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.

mnarayan01 11y ago

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.

RubyPinch 11y ago
Surely any maintained XUL related addons will survive this change, due to being maintained, no?
- steve-howard 11y ago
  It's possible that maintainers are willing to make small changes to keep up with recent versions of firefox but are not interested in a ground-up rewrite to accommodate a deprecated framework.
- mnarayan01 11y ago
  I've heard Tree Style Tabs won't be possible. Given my limited knowledge this strikes me as plausible, but I haven't investigated it at all so don't take my word for it.
  - Osmose 11y ago
    See https://wiki.mozilla.org/WebExtensions#Additional_APIs https://wiki.mozilla.org/WebExtensions#Additional_APIs There's valid criticisms against WebExtensions, but the biggest misconception is that the capabilities of WebExtensions are set in stone and that X or Y addon "won't be possible". The entire point of announcing WebExtensions so early was to start getting feedback on what needs to be supported to make major and useful addons possible, and to start work on a way for experimentation outside of the officially supported spec to still happen.

DonGateley 11y ago

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 11y ago
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/

Guzba 11y ago

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 11y ago
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 11y ago
  I can confirm the increase in difficulty of writing FF extensions these days. There is no ONE go-to source for information.

examancer 11y ago

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 11y ago
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.
odiroot 11y ago
As another cross-browser extension developer I too welcome this change. Firefox Add-on SDK was at best annoying and so inconsistent -- some APIs being sync and some async etc. I had to prepare an elaborate build system to have a single codebase (well, excluding Safari which is even worse). Now it'd be possible to move pretty far with Chrome/Firefox/Opera/Edge without the need to hack around the differences.
flanbiscuit 11y ago
Same here. Made my own personal extension on Chrome and was avoiding making it for Firefox because of how widely different it was. So I welcome this change. I'm sure it'll piss off some folks who have already put a lot of time into making a FF extension, you can't please everyone. I think in the long run this is a good thing. There is a library made by the guy who created the Reddit Enhanced Suite that helps you create cross browser extensions right now. I've never used it but it did look very promising: https://github.com/honestbleeps/BabelExt https://github.com/honestbleeps/BabelExt

kristofferR 11y ago

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.

jacquesm 11y ago
I couldn't get through my workday without tree tabs, it's the equivalent of an organized desk for me and without it I'd be thoroughly lost.
steve-howard 11y ago
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 11y ago
  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.
icebraining 11y ago
Same here; Tree Style Tabs and Vimperator are indispensable, new HTML/CSS/JS features are not.
pvdebbe 11y ago
Same here. I'm very concerned that the new framework might reduce the extensions' capabilities down to Chrome's level. It's highly unusable -- for instance, in Chrome/Chromium they don't allow the user to manipulate New tab page, and there goes all the Vimium bindings when you try to navigate it over.

hardwaresofton 11y ago

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 11y ago
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.

hackuser 11y ago

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

Qantourisc 11y ago

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

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

TimeToTroll 11y ago

sugarfactory 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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!

mrbig4545 11y ago

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

devsquid 11y ago

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

vdfs 11y ago

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

TazeTSchnitzel 11y ago
NaCl, Pepper and PPAPI are never coming to Firefox, that's for certain. But web plugins are fast becoming obsolete, so it hardly matters.

yoodenvranx 11y ago

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

jasonhansel 11y ago

Still no support for unsigned extensions? :(

azakai 11y ago
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.

pasbesoin 11y ago

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.

curiousjorge 11y ago

could I port a chrome extension to firefox now?

paulryanrogers 11y ago

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.