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.
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 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!
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.
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.
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.
At the end of the last contract with Google, Mozilla chose to change their default search provider to Yahoo in the US, and to various other providers in the rest of the world.
I'm guessing that [deleted] was about Google being the Firefox default search provider.
While it is not longer true, Firefox still uses them for SafeBrowsing, download scanning, geolocation, Loop authentication and as a source of jQuery for DevTools. If you are concerned about Firefox leaking information to Google, the tie-ins are still there.
Can you provide a breakdown of where the money is coming from? I haven't seen that kind of data which would actually show that Google isn't funding Mozilla at all any more.
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.
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.
> 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.
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.
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.
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.
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.
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.
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 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`.
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.
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.
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.
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.
> 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.
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.
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.
> 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).
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.
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.
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'.
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.
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.
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.
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 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.
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.
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.
"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.
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.
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.
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.
<disclaimer>I'm a Mozilla employee, though I never worked directly with Christie</disclaimer>
I don't know where you got that "she was a well known bully of a supervisor and a source of stress for everyone under her" but that doesn't match anything I've heard about Christie. Look at this guy comment history on reddit ( https://www.reddit.com/user/aoiyama), and maybe you'll change your mind.
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.
You know, it was not that long ago that being a hacker was, itself, a political position: you had thoughts on the power structures of the world and its borders, about US arms-control laws and their relationship to strong cryptography, about whether computer code should be subject to copyright or patent protection, about the FBI and J. Edgar Hoover, about voting technology and algorithms, about computer crime laws, etc.
Then, slowly, the hackers became engineers. The hackers' way of thinking, in many ways, became society's way of thinking, and it was easy enough not to express contrary political opinions. At which point it became easy not to express any at all.
I am an engineer, and what's a "manifesto"? Damn kids, dragging politics into our professional industry... they're all alike.
The idea that politics isn't conducive to a productive environment isn't strange. "Keep politics at home" is a phrase I've heard all my life. And it's advice that has deescalated many situations and got many non-productive time wasters back on track. I've been in (middle)management before, so I'm not just blowing smoke.
The idea that politics isn't conducive to a productive environment isn't strange.
No, just reactionary and hypocritical. You can't avoid politics, it's present in any social setting, and in any decision you make that affects others, particularly large groups of people (such as - Mozilla users). By shutting out debate, all you're doing is enforcing the political status quo.
Yeah, it's not uncommon for people who hold currently-centrist views to discourage dissent, to prefer de-escalating people's opinions, and to regard threats to their power and way of life as non-productive. All of those are way easier than defending currently-centrist views straightforwardly.
I'm not talking about government here. Sure fight the status quo of the government. I'm not applying centrist politics. It's neutralist, without left, right or center entering the equation. I know this never works when you're in HR, but it's not theoretical.
Yes there are work environments that deserve abundant politics, rebellion & real resolutions. But most people aren't working in Vietnamese sweatshops or diamond mines in the C.A.R.
Politics - Achieving and exercising positions of governance for organized control over a community.
It may be in many places & affect many things but it does not encompass everything. Absolutists are always wrong eventually (no matter how satisfying the quote is).
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.
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.
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