+++ This bug was initially created as a clone of Bug #1123261 +++ Did not want to clutter the previous bug further, thus opening a new one for a slightly different goal. (In reply to Tim Taubert [:ttaubert] from Bug 1123261 comment #3) > This seems perfect for an add-on and very unlikely to become core > functionality. Closing a tab and retrieving its state is easy, implementing > a good UI to expose restorable tabs is probably a tad harder. There are extensions like UnloadTab (https://addons.mozilla.org/de/firefox/addon/unloadtab/?src=search), however they are marked as experimental, use private/unstable APIs (many no longer work due to changed APIs), or use some obscure mechanism to trigger the behaviour, which breaks other addons. Having an easy to use, public and maintained API to unload a tab would enable addon authors to explore both manual and automatic options to hibernating tabs without breaking other stuff in Fx or Addons. The API surface can be trivial: some.object.hibernateTab(aTabObjectOrId); some.object.restoreTab(aTabObjectOrId); AFAICS the latter functionality should already exist somewhere. The former should essentially do the same that session restore does for all tabs / windows: Retrieve and store the state of the tab and unload it (transition it to the same state it is in when I enable "restore on demand", restart Firefox, and have not navigated to the tab yet). Any UI / interaction should be implemented by an addon. Maybe this is something that can be implemented in the Addon SDK (ni? :efaust)? This API should also be used as the building blocks for Bug 675539.
As far as I could tell last time I was working on an add-on which wanted to use the latter functionality (sometime in the FF17ESR days, I believe), that functionality did _not_ exist in any form that was accessible outside of the core. There was a JS function which looked like it should do exactly what was needed (though I don't recall the function name), but it was private, and not accessible from an add-on by any path which I could identify. The specific functionality I needed was to restore an unloaded tab without switching to it in the process, because switching to a tab has potentially-user-visible side-effects - such as scrolling the tab bar if enough tabs are open, and (depending on reaction speed) briefly flicking over to display the momentarily-selected tab. As a maintainer of an existing (incomplete, and therefore currently semi-private) add-on which does in fact provide a UI for something resembling this (in more limited form due to the lack of such an API) already, I am very much interested in seeing this functionality made available officially.
I think this is far too low-level to expose via the add-on SDK module system specifically, and it'd be a loss if we didn't expose it any other way. If we do this at all, we should just expose the relevant sessionstore bits. Whether that's a good idea, I'm not sure. Tim, thoughts?
Flags: needinfo?(evold) → needinfo?(ttaubert)
We have ss.getTabState() and ss.setTabState(). The latter doesn't load the tab right away and just restores the state if the tab is non-pinned, not selected, and restore_on_demand=true (which is the default). Just as we discovered in bug 675539, there is no way to safely unload tabs. We might lose state and information. Exposing an API that pretends this would be a safe operation does not make sense.
From the duplicate bug 1156788: (David Rajchenbach-Teller [:Yoric]) > There are a number of great add-ons that let us unload tabs to save memory usage. I'm not quite > sure how they do that, but I'm pretty sure that's at least somewhat hackish/slow. > > It would be quite useful to introduce an API for doing this cleanly. Oh, and this would also > let us implement bug 1146948. > > (I also suspect that there are applications for the upcoming self-help feature)
Does https://bugzilla.mozilla.org/show_bug.cgi?id=1322485 resolve this now?
(In reply to Ruben Petersen from comment #8) > Does https://bugzilla.mozilla.org/show_bug.cgi?id=1322485 resolve this now? Yes.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1322485
You need to log in before you can comment on or make changes to this bug.