Session Manager (240 000 users) needs this bug to be able to make sessions persist across different sessions properly.
Basically, you're currently able to store full devices and restore them across as many sessions as you want, but the problem with that is, tab history doesn't get restored. browser.sessions.restore() only works for one session, not multiple ones.

Tim, can you please be a bit more explicit about exactly what you're looking for with this API? If you can describe what the API would look like, what data it would provide, and give some use cases for it, that would make it easier to evaluate.

(In reply to Bob Silverberg [:bsilverberg] from comment #1)
> Tim, can you please be a bit more explicit about exactly what you're looking
> for with this API?
At the moment you can't get or set the back-forward history of a tab, it would be nice to do that in the context of session managers.
> If you can describe what the API would look like, what data it would provide
A new field on the Tab or Session object called tabHistory containing HistoryItems inside.
tabHistory: [
HistoryItem { ... },
HistoryItem { ... },
...
]
or add a sessionId field to each HistoryItem from the chrome.history API.
or a new tabHistory namespace containing a bunch of APIs.
>, and give some use cases for it
Again, session managers want to restore tabs with their full history. Another interesting thing to do with the tab history would be implementing trails.
https://medium.freecodecamp.org/lossless-web-navigation-with-trails-9cd48c0abb56

Adding some more info on use cases and issues, from Google Chrome experience.
This same functionality was proposed and accepted for Chromium several years ago, and there's some relevant discussion about it in the bug below. A lot of work was done but unfortunately it's stalled and there's been no progress recently. That means that unlike Firefox, session manager extensions on Chrome/Chromium have never been able to restore tab history. But there doesn't seem to be any issue in principle with implementing it in Web Extensions:
https://bugs.chromium.org/p/chromium/issues/detail?id=41321
Some additional discussion related to the use case and many requests for it in the Session Buddy extension:
https://groups.google.com/forum/?fromgroups#!topic/sessionbuddy-discuss/l6zY2ZjGSYg
As there are plans for a Firefox version of Session Buddy, the ability to restore tab history could be a distinguishing feature for Firefox. Also this seems to be the last major issue blocking a port of the popular Session Manager addon to Web Extensions.

This bug's description talks about session manager extensions being able to restore history. If the scope was subsequently narrowed to just read-only access to history, that's not enough to enable that.
So just to be clear then, my comment 7 should apply to bug 1381922 instead. In other words, it's that bug's functionality which was approved (but still not implemented) for Chrome, and which seems to be the last major issue blocking a port or replacement of Session Manager.

Please fix this bug as for as for many users of Firefox it is an essential addon to its usability. Quantum needs this addon or extension. I am currently using ESR version despite its lack of speed and usability. Tab Session Manager just doesn't do it.

Same here, I will need to stay on ESR without proper session management. So please, please, priorities this issue. I have been using Firefox since it was still called Phoenix and for me personally this the biggest setback since then.

(In reply to Tim Nguyen :ntim from comment #23)
> The second part (adding the property on getRecentlyClosed) is now done.
>
> Now, this just needs automated tests, which I'm currently working on.
Are there non-automated tests to run? Have these been run successfully? Just wondering how that works, and how far along this is. Thanks.

Hi Tim, thanks for working on this.
Kris has marked this a duplicate of my bug1450115 which I think means that he believes the patch you're working on will accomodate this. After reading through your bug, I am not 100% sure, so I am posting this to make sure I get coverage from your patch.
I need to know whether the tab can go back or forward from its _current_ location in the history list. I believe you are working on returning an object containing the history list for the tab, but I am not even sure of that much. If so, would I be able to detect where the browser is currently pointed to in that list, ie at either end of the list? I would need that to emulate the .canGoBack() method.
thanks snuz.gary

(In reply to snuz.gary@gmail.com from comment #27)
> Hi Tim, thanks for working on this.
>
> Kris has marked this a duplicate of my bug1450115 which I think means that
> he believes the patch you're working on will accomodate this. After reading
> through your bug, I am not 100% sure, so I am posting this to make sure I
> get coverage from your patch.
>
> I need to know whether the tab can go back or forward from its _current_
> location in the history list. I believe you are working on returning an
> object containing the history list for the tab, but I am not even sure of
> that much. If so, would I be able to detect where the browser is currently
> pointed to in that list, ie at either end of the list? I would need that to
> emulate the .canGoBack() method.
The current patch returns a list and a pointer to the current tab history item, so yes, from this you can detect canGoBack/canGoForward.

crickets...
I just wanted to say that I filed bug1450115 because webextensions broke the capability that previously existed in the canGoBack()/canGoForward() methods of gBrowser. This also partially broke an extension of mine. That bug was marked a duplicate of this one, which is partially true - I'm certain that Tim's code would return the capability.

This bug is classed as an enhancement, but for my purposes, it fixes a regression. Can I use that somehow to increase the importance of this bug? It looks like the code has been written and just needs integration.

Thanks to anyone who knows how this would work...

You need to log in
before you can comment on or make changes to this bug.