Exactly. Once all your front-end is in html, including the part that manages tabs, nothing prevent a WebExtension to implement TreeStyleTabs.

Also note that the same extension support is landing in Firefox OS (we are working on the missing apis), and will let you install the same extensions everywhere.

I understand people mourning xpcom access. You can do fun things with that, but I've also seen my share of horrors when I was reviewing add-ons (let's override the http protocol handler, what could go wrong!).

if i wanted something that has limited addons like chrome, why wouldn't I just run chrome, rather than some inferior "me too" edition?

I choose firefox because of the power of its addons, this is a huge issue for me as a user.

And yes, I know that you will be consulting with addon authors about api functionality, but i guarantee tons of stuff is still going to be lost...

>And yes, I know that you will be consulting with addon authors about api functionality, but i guarantee tons of stuff is still going to be lost...

Not to mention all the potential extensions that nobody has thought up yet that will no longer be possible and probably never will be. The ability to experiment and try out new ideas that nobody had thought of before is what gave us a lot of the extensions people use today. An API that tried to imagine all the possible features people might need and then locked down everything else would have prevented a bunch of the extensions that are popular today.

This problem exists for the web in general though (being a tightly controlled sandbox where only features agreed on by all the vendors are allowed). So I think Mozilla is probably institutionally incapable of understanding the problem, since it undermines the central mission of the entire organisation - which is to convert all end user software into software that runs in a vendor controlled sandbox. People who appreciate the creative cost of tightly controlled sandboxes probably wouldn't go to work for Mozilla.

Except for people losing interest in developing for the platform due to all the API churn. By the time all this lands no one will care to implement TreeStyleTabs.

Seeing the vibrant plugin ecosystem revolving around Atom makes me cautiously optimistic for Firefox's future prospects. Implementing the entire interface and plugin system in standard Web technologies will also make plugin development more welcoming to web developers who found XUL development too archaic.

In fact, I'm one of those developers, and the first thing I'd do in post-XUL Firefox would be try to create a Tree Style Tabs alternative.

Atom was a new program though so people started from scratch and had no pre-existing code-bases (unless you count ST3 ports), whereas here Mozilla's change would drive many developers away because they would now need to rewrite addons entirely for the new API or if the API doesn't support what their addon did they're SOL. It seems like a bad way to go about it, they shouldn't deprecate the API till there's feature parity in the new API.

Feature parity is a meaningless term. Extensions currently have access to the entirety of Firefox internals. That huge internal surface couldn't be stabilised without stopping development entirely.

Couldn't that internal surface be gradually phased out? Make an API that gives you full access to it, then piece-by-piece replace the full access with safer replacements?

I think I would introduce the new APIs through Jetpack (which has a formal separation between the extension proper and the APIs it uses, but ships the implementation for both). Once an extension uses only stabilised APIs (APIs taken from chromium could stabilise first, assuming there aren't too many abstraction leaks), label it as Forward-Compatible on AMO (similar to restartless addons). Help the top extensions port, and start breaking internal APIs more aggressively. Maybe start measuring the latency introduced by cross-process wrappers (assuming the extension that uses them can be determined at runtime), and warn about extensions that use them. The perception that Firefox is slow largely comes from that kind of compatibility hack, and people would probably make an informed choice to speed up their browser.

They needed to roll this out before they made any changes to extensions!

If I had a nickel for every time the existing solution was deprecated and the "right" solution wasn't ready yet...

The trouble is that they aren't planning to wait to switch to browser.html. They're deprecating XUL extensions now, without switching to an HTML-based UI first.