[derefr]

I'm not clear on why you would want TST as an extension rather than built into the browser chrome. It'd be like wanting the tab bar, or the address bar, to be an extension. Those things belong in the browser chrome; they're what the browser chrome "layer" is for. Just dig into the Firefox code and add TST to the browser itself. (It wouldn't be all that much work; it'd just be 1. adding "parent" and "children" properties to tab model-objects; and 2. adding a TST sidebar view-controller, fed from the same data-binding that backs the regular tab bar.)

[michaelmrose]

It's pretty clear that people desire it as an extension because a good and functional extension exists whereas first party support in a browser does not. There are certainly good arguments for it being easier for it to be built in vs as an extension if you were building from scratch right this moment but such an argument misses multiple points.

An extension exists NOW that people enjoy using. Building THIS into firefox isn't a replacement for a robust extension interface unless you suppose that first party developers can think or implement all the good ideas that will ever come about.

People in truth give zero damns if its easier to implement or more elegantly done any more than they care if their tv is beautifully engineered because their priorities aren't yours. They care about functionality. Right now firefox seems to be lighter and even post quantum have better extensions. Throwing either of those out will cause it to cede more marketshare to chrome.

[derefr]

> unless you suppose that first party developers can think or implement all the good ideas that will ever come about.

Er, no. What I think is that becoming a "first-party developer"—when you already know as much about the internals of Firefox as is required to maintain an extension such as TST—isn't that hard. Firefox is a FOSS project, with internals that are well-maintained and well-documented, and the UI layer is abstracted out to make working with it easier for frontend engineers (which is why, unlike any other browser, you constantly see versions of Firefox with new "experimental UIs.")

> There are certainly good arguments for it being easier for it to be built in vs as an extension if you were building from scratch right this moment but such an argument misses multiple points.

I mean, that was my argument, yes. And I don't see how it misses the point, because I'm not coming at this from the perspective of a Firefox user, nor am I coming at this from the perspective of one of the existing TST maintainers. I have no dog in the fight of Firefox's extension system, because—at the earliest point I'd even start using Firefox—it'd already be a “fact of life” that it only has WebExtensions. I'd just have to take it as a given that you can't do what TST does (did) as an extension, and ask the question afresh: how do you implement something like TST?

And the answer is: natively, in the browser chrome, and thankfully so, because that's what TST should have done in the first place and it'll make many parts of the implementation a lot easier. (See my sibling reply.)

Though, also, never mind Firefox. I'm also coming at this from the perspective of a developer who would want to implement TST-like functionality for any FOSS browser. For example, TST-like functionality for Chromium.

The fact that TST already exists for "old Firefox" doesn't really matter. That's a different web-browser than the one we've got now, and no current browser lets you do what TST did at the extension level. I don't care about ideological arguments about whether they should let you; I care about the practical facts of how to go about having TST functionality in the present/future of the browser landscape.

[lucideer]

Not sure why you're being downvoted, I completely agree. This is absolutely something that I think should be in core.

There are some features that are rightly being removed from core in favour of being served by an extension (Container Tabs is a great example—one of my favourite and most-used features personally, but I prefer it in an extension for a few reasons). Better tab management is the opposite: this is something Firefox should work on getting right out of the box.

I get that unless/until it makes it into core, we need good, working, popular extensions to bridge the gap, and perhaps to convince core devs there's an audience, but that's no reason to stop asking for it.

Would also recommend people trial Vivaldi, or even Opera 12 (probably still downloadable from somewhere out there) to try out the general UI concept.

[IChrisI]

Given that Tree Style Tab has 7,500+ commits, 10 pull requests (200 closed), almost 400 issues (almost 1,500 closed), and the download is 5.6 megs (2.7 megs zipped), there may be more to it than your two-step solution.

[derefr]

Not necessarily. Sometimes 99% of the work of something is the patches you must make for a constantly-leaking abstraction that you introduced by solving the problem on the wrong layer.

For an example I've experienced personally: LinkedIn provides a data API... for a price. There are entire companies, however, that scrape LinkedIn's data instead of paying that price, and then try to work with the scraped data (which has been "baked down" through all sorts of views, localization, projections, etc.) as if it was the API data.

How much more code do you think such a scraper consists of, compared to an API client?

(The LinkedIn case is even worse because LinkedIn has stateful firewalls that actively thwart scraping, and these scrapers have to have code to trick the firewall, as well.)