transparently "closing" tabs and restoring them? (resource minimization)

[TheOverpassArsonist]

Apologies if this has been asked already or is documented somewhere (tbh I'm sure it probably has, but I can't find the right search terms to draw it out if so) but I was curious if there is a way to transparently save/open tabs without removing them from the tree.

In other words it would be like a grade higher than tab-suspension; instead of simply suspending the tab you would save it to disk, close it outright, and then re-open it only once the tree is unfolded. (or, for even lazier loading, only once the specific tab is clicked on, hovered over, etc.)

In theory this can be done with bookmarks, and to be honest if you were a responsible human being you probably would, but I'm more of a 4-digit-tab-count kind of person and having it as an integrated feature would be a huge convenience boost for me. In my defense, bookmarks do have a hefty convenience penalty both in directly using them and in the fact that they don't stay updated, requiring you to manually make sure they're in sync. It's not entirely laziness either, I just tend to end up searching and looking into tons of different topics and trying to keep a bookmark catalog of all of the things I've looked into or wanted to look into neat and orderly would be impossible practically speaking. (Still, I'm not delusional that once your in the 4 digits of tabs you might be a digital hoarder.) Even if you only have a dozen or so tabs though trying to restore them all simultaneously can cause connections to be dropped since it can look like a DDOS, so restoring from a local copy of the page instead would also mitigate that issue since you wouldn't necessarily need to ping their server to restore the tab from the cached state on-disk. In theory something like this would allow TST to open a basically arbitrary amount of tabs without issue since it's not actually "opening" any of the tabs at all, but rather loading a list of the tabs that it had open and only quering the tabs that it needs to actually open on-demand when the tab content is needed, otherwise keeping it as a phantom-entry that looks like it's there and open without actually demanding any resources.

While tab suspenders can reduce the resource usage of a tab, they still keep that tab open as far as I understand it. (admitedly most of my experience here is with chrome derivatives so maybe firefox has a different architecture that allows for this to be done way more efficiently) If silent tab culling was built into / integrated into TST though then since TST manages tabs itself it could display the tabs as if they were all there without incurring any overhead since they could be completely closed in actuality. Now, there are obviously going to be some storage space implications involved in doing that with too many tabs but, speaking at least for myself, I would be more than content giving several dozen gigabytes to my browser if it meant seamlessly being able to handle an arbitrary amount of tabs. (well, near-seamlessly, things like Youtube where the content is explicitly network-dependent might have issues)

I'm not sure how doable this would be based on how things are written behind the scenes, but at least for me it would be an insanely huge overhaul and I imagine this sort of behaviour would help others quite a bit too, even if they are responsible human beings who know what a close button is.

(note : this would definitely conflict with the default horizontal tab bar as I understand it, I don't think there is any easy way around that and I'm under no delusion that there is. With that said, keeping the horizontal tab bar in sync with TST is already a non-starter since it's just fundamentally so much more limited, so I don't think that would constitute a huge issue. It at least doesn't to me and I can't imagine it would to many others either)

[piroor]

The idea looks beyond the project scope of TST, so I won't implement it as a built-in feature of TST. But it's OK to provide APIs required to implement a helper addon for that, if it doesn't break TST's concept.

treestyletab/webextensions/sidebar/scroll.js

Lines 391 to 410 in a740926

	for (const id of insertIds) {
	if (STICKY_SPACER_MATCHER.test(id)) {
	const spacer = document.createElement('li');
	spacer.classList.add('sticky-tab-spacer');
	spacer.setAttribute('data-tab-id', RegExp.$1);
	win.containerElement.insertBefore(
	spacer,
	win.containerElement.querySelector(`.sticky-tab-spacer[data-tab-id="${referenceTab?.id}"]`) ||
	(referenceTabHasValidReferenceElement &&
	referenceTab.$TST.element) ||
	null
	);
	continue;
	}
	SidebarTabs.renderTab(Tab.get(id), {
	insertBefore: referenceTabHasValidReferenceElement ? referenceTab :
	win.containerElement.querySelector(`.sticky-tab-spacer[data-tab-id="${referenceTab?.id}"]`) ||
	null,
	});
	}

Items in the sidebar are built with these lines, from corresponding tabs. So, it may be possible to implement the features you told by adding some codes here.

Sorry I have less motivation to implement APIs by my hand. i hope you or someone does that and sends a pull request to this project.

[TheOverpassArsonist]

Can't say I'm very good with JS unfortunately but if browsers don't start managing tabs better I might give it a shot eventually anyway just to see if I can make something work. (at least if no-one a bit better with JS tries to tackle it first that is) I imagine though that implementing a practical solution here would involve a lot more knowledge of web/browser stuff that I don't really have, but if I can find the time it might be worth trying to learn it since this has been bugging me for years and I can't say it looks like browsers are itching to start handling tabs any better on their own.

I'm currenly on Brave with The Marvellous Suspender and, while it works for resource usage, it still does actually keep those tabs open so on my laptop for instance the battery life difference between the tabs actually being closed and them all just being suspended is quite significant. (plus, it does actually refresh the tab when it reloads it which, as I touched on, can cause issues with DDOS protections as well) I used to use a tab manager extension but it appears to be unmaintained and, while I opened a PR to fix an issue it had with tab-groups, without it being merged it's a choice between either tab-groups or sessions and tab-groups are just too helpful. TST though kind of fills that gap for me, and since it's an entirely extension-managed tab system that is a lot more directly hackable it got me thinking about spoofing tab-entries and transparently closing/restoring them from disk, fixing both the organizational and management problems in one.

Out of curiosity, from the snippet you attached it looks like that's just directly rendering the tab-entry by iterating through a list of ID's, ("insertIds") does that ID list itself hide collapsed tabs, or is every tab iterated through even if it's in a collapsed group? I can't see any control logic in the loop to deal with collapsed tabs so are they just removed from "insertIds" beforehand? If so then it seems like so long as it was possible to spoof the "referenceTab" and maybe "Tab.get(id)" it would be fairly trivial to get 'fake' tabs to be rendered as if they were present. If I am right about that implementation though then it might require fairly wide access in order to get it to work seamlessly. (for instance to hijack the tab-clicking process to restore saved tabs from disk) I figured that the tab tree would be structured as an actual in-memory tree of some sort, with each tab being it's own instance of some generic "tab" object that contained most of the logic in it. If that were true then all it'd take to spoof entries is being able to manipulate the objects in that tree. Judging by that code snippet though it looks like that might not be accurate so I'd definitely need to take a closer look to see what'd actually be required for a good implementation here if I were to start on it. It's possible that it'd require changing so much it's just not practical to bolt it on via a plugin and it'd take a fork or writing another tree-based manager with this idea baked in from the start.

[piroor]

The insertIds is actually calculated from two lists of IDs "currently rendered in the sidebar" and "to be rendered in the sidebar", based on the diff's algorithm.

treestyletab/webextensions/sidebar/scroll.js

Lines 312 to 320 in a740926

	const toBeRenderedTabs = renderableTabs.slice(firstRenderableIndex, lastRenderableIndex + 1);
	const toBeRenderedTabIds = toBeRenderedTabs.map(tab => tab.id);
	const toBeRenderedTabIdsSet = new Set(toBeRenderedTabIds);
	for (const stickyTab of stickyTabs) {
	if (toBeRenderedTabIdsSet.has(stickyTab.id))
	toBeRenderedTabIds.splice(toBeRenderedTabIds.indexOf(stickyTab.id), 1, `${stickyTab.id}:sticky`);
	}
	const renderOperations = (new SequenceMatcher(mLastRenderedVirtualScrollTabIds, toBeRenderedTabIds)).operations();

So, we look to need to insert something operation here to modify "toBeRenderedTabIds".

[piroor]

And, yes, we'll need to do more things around handling of user operations in the sidebar: clicking, drag-and-drop, or more.