WebExtensions FAQ | Hacker News Reader

WebExtensions FAQ

wiki.mozilla.org

177 pointsjtgeibel126 comments

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/635079271032090624 https://twitter.com/piro_or/status/635079995371556864

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.

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.

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!

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

Yes. :-)

The long-run solution will be when mozilla removes XUL entirely, and switches to browser.html

https://github.com/mozilla/browser.html

In the short run, perhaps try an ESR release?

https://www.mozilla.org/en-US/firefox/organizations/faq/

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.

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.

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.

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

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.

Surely any maintained XUL related addons will survive this change, due to being maintained, no?

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.

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.

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

On one hand, that link provides pretty strong (implicit) evidence that plenty of stuff won't be possible after the switch away from XUL, whether or not Tree Style Tabs is possible.

On the other hand, Tree Style Tabs is far and away the biggest extension I care about, so that link does provide me with some level of hope. For which I genuinely thank you.

On the third hand, my cynical take is that apparently Mozilla really does take community feedback into consideration. When making a wish list of things that could potentially happen in the future to put on a wiki page. I've also heard that it's possible that Pocket could be moved to an extension.

> On one hand, that link provides pretty strong (implicit) evidence that plenty of stuff won't be possible after the switch away from XUL, whether or not Tree Style Tabs is possible.

From the FAQ, there's a proposal for a way to do things that require the same level of access that the browser chrome has here: https://discourse.mozilla-community.org/t/proposal-native-js...

To me it seems like a decent way to say "Hey, here's an explicitly unstable way to do things that aren't possible with WebExtensions, and hopefully we can eventually get those things into WebExtensions, or you can just live your life as you do now with no hard promises about compatibility."

> On the other hand, Tree Style Tabs is far and away the biggest extension I care about, so that link does provide me with some level of hope. For which I genuinely thank you.

You're welcome! :D

> On the third hand, my cynical take is that apparently Mozilla really does take community feedback into consideration. When making a wish list of things that could potentially happen in the future to put on a wiki page.

I could talk about this _forever_, but the short version would be: That's not a false criticism of Mozilla in recent times, but it's also not entirely true. Hacker News, r/firefox, and others are very vocal minorities compared to our greater userbase. Sometimes we really need to listen more and change our plans and be more open than we have been, but sometimes the people doomsaying everything we do might have a different opinion if they had all the details and metrics and info (knowing how to navigate Mozilla to find info about something is a skill in itself).

> I've also heard that it's possible that Pocket could be moved to an extension.

I dunno if we've specifically made that decision yet, but it is certainly one of the primary candidates for Go Faster: https://wiki.mozilla.org/Firefox/Go_Faster

> The entire point of announcing WebExtensions so early...

Their current schedule only gives a year to build an api, mature the api, get a significant number of popular ported addons, and deprecate their old api. There will either be mature apis and many casualties, or half-conceived apis and lots of addons that will need to be changed with these apis.

With enough time and design, I'm sure this move would result in many positives at the cost of some negatives. But this time frame is just too short for such a huge undertaking.

I agree that the timeline is rather short. I think it's totally possible for the Firefox team to achieve their goals within that time period, but whether addon authors can keep up is not as clear to me. We'll just have to see how it goes; I don't see why they couldn't extend the timeline if it turns out to be too short.

It really depends how many resources mozilla puts on this internally, which from what I've been reading may actually be quite a bit. But I don't think they'd move the schedule any more than a few releases, there will likely be a whole bunch of addons ported at the last minute, and they likely need the motivation.

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

Awesomebar for one.

Being able to just type in the random things you remember from a url / title (I think it combines them) and have FF narrow down the alternatives, -fast, is something I haven't found in any other mainstream browser.

Another aspect is it doesn't automatically send everything you type to google (I don't worry to much but it is a nice touch.) Maybe the average user is confused by having a separate search field in addition to the address bar but I like it. (And yes, you can search from awesomebar as well, although there is no suggest feature.)

> Being able to just type in the random things you remember from a url / title (I think it combines them) and have FF narrow down the alternatives, -fast, is something I haven't found in any other mainstream browser.

Chrome has exactly the same feature. You can disable Google Instant, too, but it's actually a really useful feature.

Common misconception I guess[0]: Chromes version is not the same. (Unless I am seriously wrong.)

Try to type

   new com <part of title of something you read on hn today>

to test. On FF and PM this just works but on Chrome I still don't think it works.

[0]: which might explain why not everyone is using the better browser :-P

That has always worked for me on Chrome. On the other hand, chrome lets me use the websites own search without setting up anything. For example:

you [tab] searches on youtube. news [tab] searches hn. I've never set it up and works with almost every site I've performed a search on.

Does "new com webex" work for you in Chrome? It won't offer anything but a Google search for me. On Firefox it'll either offer to switch tab to here if it's still open or it'll find this in history.

I agree Chrome's site search thing is awesome, but how did you teach it to use the new HN one?

EDIT: Chrome settings -> manage search engines. Very impressed with the list of those it's stored automatically. Point stands that it doesn't seem to relearn though when one changes.

yes it does: https://www.dropbox.com/s/ku9zzet28pzjcc9/Screenshot%202015-...

That works for me on Chrome. The misconception might be on your side ;-)

Just tried it in Chrome and it has the exact same behavior as FireFox.

When I do this in chrome, it opens a new instance of the page. In Firefox, it switches to the tab you're searching for.

Safari does this, as does Chrome. For example, typing "webex" will show this discussion as one of the autocompletion suggestions.

Safari will suggest also suggest things like Wikipedia articles and popular sites. Similarly, if I type "imdb michael mann", Safari will suggest "Search imdb.com for michael mann".

Firefox's location bar is arguably much worse than both Safari and Chrome — it won't really autocomplete anything except "search Google for this" and bookmarks/history. Safari also leaves the search standing in the location bar when you submit it, whereas Firefox replaces it with an obscure, unreadable google.com URL.

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.

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

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

I don't know how people can live without Tab Groups. Usually I am working an 5 to 10 different "projects" and for each project I have a tab group with everything from 3 to more than 20 open tabs. Based on the project I am working on I can just switch to the correct set of tabs.

I could do something similar with bookmarks but that would be way slower and not as comfortable.

I do this manually (in FF) with one window per project, and N tabs per window. Works well enough even without extensions.

How do you do the per-window-stuff? Do you use a different firefox profile for each window? And how is it handled if one window is closed?

In this setup you just have to be careful to quit FF rather than close a specific window.

There is a Chrome extension called FooTab that does #2. Maybe Chrome will add this functionality at some point. I have heard that they are working on unloading tabs when many are opened at once.

Specific: If an anchor element has its download attribute set, Chrome won't display any indication at all that it has been clicked until the server responds (at least AFAICT).

Circumstantial: In most cases I prefer the way Firefox handles runaway scripts. Though when it fails, it fails hard.

There are many others, though like I said...I doubt they'll out weigh Chrome's advantages sans the existing extension ecosystem.

I use a few heavy user interface customization extensions:

1. Tree Tabs: this extension lays out my tabs stacked vertically on the left of my window. I can fit upwards of 50 tabs in a window before I have to scroll the tab list. This is great for managing big research or documentation sessions without the squinting in Chrome. The APIs necessary for tree tabs are not yet in chrome, although there is some discussion now of a sidebar API.

2. Vimperator: this extension provides a very powerful vim-like interface, including a .vimperatorrc file. I don't use any more of the advanced features like that, but it is excellent for keeping my hands totally on the keyboard as I switch between Tmux splits, vim windows, and my browser. There are several vimperator-inspired plugins for chrome, some of which are passable. However, vimperator is a lot faster than Vimium, and the interface is more concise and vim-like. A big difference is the UI for opening links: in Vimperator, you press `f` to enter follow-link command mode. Each link is assigned a number by page order; you filter links by typing letters, and can follow the first link by pressing `enter`. So to submit this text form, I would press `esc` to return to normal mode from edit mode, then press `f`, and then type "rep<enter>" to filter links to reply, and then click it. It's rather natural, and easy to click the right link.

In Vimium, each link is assigned two letters (which are easier to type than numvers), but you can't filter links. There's a lot more squinting at the little labels to type the right thing. Plus, it's easy to fat finger the link text with no recourse.

> n Vimium, each link is assigned two letters (which are easier to type than numvers)

Are you sure you can't change that in Vimperator? I use Pentadactyl (can't even remember why I chose it over Vimperator) and i can just do `set hintkeys=asdfghjkl`.

You can make vimperator work like vimium but not the other way around.

FF still has bookmark tags, right? Living without them on Chrome is not pleasant.

This. They are one of my most loved feature on Firefox.

Firefox is not from Google.

This is its biggest upside and I suspect that I'm not the only one who sticks to FF pretty much exclusively because of it. I am even willing to look past their shenanigans with Pocket, EME, Loop, featured tiles and all other "for the sake of our users" crap Mozilla keep on stuffing into the browser. One thing is pretty obvious though - Mozilla now don't really give a damn about "community". They do what they want to do and the only deterrent is a risk of lash back from said community, rather than their approval.

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.

> 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 :/

Servo would replace Gecko, not Firefox.

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.

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

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

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

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.

Firefox has a pretty good reputation among users and web developers, despite risks of hitting bad extensions. Their problem amont end users is more the relative obscurity vs the big 3 commercial browsers. IE on the other hand has been a swear word for years.

I hope not. Mandatory extension signing requires handing over proprietary code to some random dude and trust them to not accidentally leak it, just to run it on your own computer and now this.

App store app require signing : I've never, ever, got to handle anything beside the binary (and the eventual code/uri to test it). I don't see why it would be different here.

Mozilla explicitly wants to have a system where the extension is uploaded to them for signing, unlike the Apple / MS Authenticode systems where the developer gets a certificate to sign locally.

https://wiki.mozilla.org/Addons/Extension_Signing (look for "not hosted")

If you just want to run it on your own computer, you can replace the sign check certificate (or build Firefox without this feature altogether). Signing is for protecting other users.

> Firefox is still a slow, unstable and memory-guzzling behemoth, where all your extensions break on every update.

Using dozens of extensions, this has not been my experience or the experience of many others I know. I believe the problems with extensions breaking and memory consumption were solved years ago; AFAIK tests show Firefox' memory consumption is less than Chrome's (in part because of the single-process model) and performance, at least a little while ago, was slighlty better. I haven't experienced, seen, or read about instability.

I experience frequent crashes in Firefox.

I don't think it's to do with extensions, though. I'm saying XUL, XPCOM and the single-process model hurt Firefox's maintainability and performance.

Crash IDs? https://support.mozilla.org/en-US/kb/mozillacrashreporter or email at HN username at mozilla dot com

    bp-9ae5ccb2-a36f-48f7-b649-648712150822
        22/08/2015	15:49
    bp-63bbf3d2-c39f-43ee-ad31-d8e812150820
        20/08/2015	19:18
    bp-816c2b7e-fa1a-422c-96ff-3b5e92150810
        10/08/2015	20:43
    bp-6ab2fecb-4d9a-4606-8b82-8bcbf2150804
        04/08/2015	15:49
    bp-f44c1dfa-ceff-4545-9296-497d12150729
        29/07/2015	18:13
    bp-2666bb07-a39d-43fc-ab4f-e65b62150718
        18/07/2015	22:32
    bp-8105e9f9-8f75-40bb-bda7-183f32150709
        09/07/2015	23:09
    bp-6b2109ed-a735-4ba1-9e89-c6aca2150707
        07/07/2015	20:43
    31FE13CD-B070-45CB-B157-5D04B0CB675F
        28/06/2015	11:31
    bp-bcc85795-d492-4315-8c2b-43e6e2150627
        27/06/2015	16:25
    bp-5ea95a70-01c4-4f39-b77f-6eba42150622
        22/06/2015	19:21
    bp-494b2943-ce7d-41e2-b7d7-75ae42150617
        17/06/2015	18:10
    bp-8b587d12-1fb5-4a03-91cf-1edd62150616
        16/06/2015	19:19
    bp-82493a68-01af-4c3c-9249-4853b2150616
        16/06/2015	18:08
    bp-80e2046a-e546-4a69-981a-776bd2150612
        12/06/2015	21:59
    bp-033f153d-3fd9-41fb-8b52-b9fdf2150530
        30/05/2015	03:25
    bp-ae103aba-4db2-40b7-bb09-731d62150528
        28/05/2015	17:05
    bp-d76b7a06-884c-4c34-9e1e-b40d72150520
        20/05/2015	20:33
    bp-6e67abea-846e-43e3-9f5d-a3abe2150508
        08/05/2015	23:24

Very likely to happen if I've been streaming video for a long period of time (playing YouTube videos, especially long ones).

> The mention that they plan to remove XUL usage within Firefox (which is a good idea) is interesting.

It's strange that XUL survives for so long. Adding an additional markup language to CSS, JS and HTML/DOM to be used for extension development has been bold. For some time, they would have had the chance to push XUL for general development (when Qt and WPF/XAML were not yet that much more modern).

Well, they did try to push it for other things. That was their original intention.

Of course, it didn't catch on, so Firefox was stuck with an obscure UI language only it used.

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.

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

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

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

https://hackademix.net/2015/08/22/webextensions-api-noscript...

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.

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

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.

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.

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.

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.

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.

Same here; Tree Style Tabs and Vimperator are indispensable, new HTML/CSS/JS features are not.

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.

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

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.

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.

I'm a complete outsider to Firefox development (a former housemate used to work for Mozilla on something other than Firefox, that's about it), but as someone with strong opinions on browsers and security and not very strong opinions on extensions, it seems pretty reasonable to me. I'm really not comfortable with the extent to which XPCOM lets you load native-code libraries and call functions in them, and I'm not really sure I see a way that you can have something that works like current XPCOM but also uses strong sandboxing. Firefox is neither sandboxed nor multiprocess, unlike Chrome, and while this may not yet matter in the marketplace it's very much a "long-term strategic necessity" -- the architecture's technical debt will start biting them in terms of security profile.

Meanwhile, the Servo folks (according to Google results for 'servo xul') seem to want to actively avoid XUL for Servo and are vaguely hoping to build the entire browser UI in HTML. If they make that work, then yes, the time and energy spent fighting with XUL will be a sunk cost, but I suspect most extension authors are familiar with HTML.

To be fair, these are both decisions you make if your primary priority is building the best web browser possible. There is an argument that Firefox has already lost there to Chrome and that's not a battle worth fighting, and the priority should be building the best extensible web browser possible: it's something Firefox is already much better at, it's something that's harder for Chrome to be good at (because Chrome has already done this rearchitecting, being a much younger codebase), and it'll let Firefox compete on niche instead of competing head-to-head. And, clearly, Firefox is not a smoldering security disaster today, so maybe things will be fine in practice with a more moderate approach.

If you take that worldview, then yes, they should be asking people who primarily care about extensions (developers and users). But if you don't take that worldview, if you ask people who care about browsers in general, they'll be supportive of this rearchitecture.

The "insufficient community input" criticism is a difficult one because it's one that people often use when really they just mean "I don't like it".

I don't think that fits the facts of this case, but then again, I haven't been monitoring the mailing lists. It does seem from developer reaction that it came at them cold.

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

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.

As a proposal before they made the decision. Getting input on an already made decision isn't input on the decision.

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

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.

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

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

Still no support for unsigned extensions? :(

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.

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.

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

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

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

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

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

could I port a chrome extension to firefox now?

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.

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/

Reply on news.ycombinator.com