Seeing as how there is an api in place to have a built in sidebar in firefox, plenty of tab and window API methods available, a way to hide the horizontal tabs at the top of the screen and the developer of treeStyleTabs saying that they will be able to move to webextensions fine... I fail to see how this will be inferior to an XUL extension. Can you elaborate on how the old tree style tabs is different other than using XUL?

Unrelated, but the fact that the developer doesn't get the extension AMO approved and uses eval() all over the place should give some pause as well.

He uses eval in safe ways, according to the developer. So I think your argument is mout unless you can point the unsafe uses.

Now, the real question is: "why isn't Firefox developing a default Tree Style Tab?"

I think at this point enough people are using it, and it has proven to be a better way to browse.

He may well be using it "safely" but it still is a string that is being evaluated so it has many inherent drawbacks.

> Now, the real question is: "why isn't Firefox developing a default Tree Style Tab?" > > I think at this point enough people are using it, and it has proven to be a better way to browse.

Not sure there are enough users to justify taking actual mozilla engineers off core problems that are everyone's problems. There is a maintenance burden and associated cost for every feature that mozilla adds to their core product. I think they would rather make the browser extension backend robust enough to allow for those types of extensions without sacrificing stability, performance, and security.

>Unrelated, but the fact that the developer doesn't get the extension AMO approved and uses eval() all over the place should give some pause as well.

He does, it is in the official add-on site, but their approval process is slow, and a few times a Firefox update has broken it and I've had to download the update from the dev's site because it takes a long time to update on the official site.

Just because it's on the site doesn't mean that it's approved... it's marked experimental by the developer to not require a full review with the caveat that any experimental extension is inherently more risky than a reviewed one. The developer lists a few reasons why they don't do the full review and one of those is that they use eval() and that the review takes longer than they deem acceptable. I just said it should give a little bit of pause not that you should wholesale reject using their extension. I just looked over his code and it's quite a lot of code for something that should be fairly straightforward.