1378651 - Allow accessing back-forward history for each tab

Status: NEW

(WebExtensions :: General, enhancement, P5)

Description

[Tim Nguyen :ntim]

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.

Comment 1

[Bob Silverberg [:bsilverberg]]

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.

Comment 2

[Tim Nguyen :ntim]

(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

Comment 3

[Bob Silverberg [:bsilverberg]]

Thanks Tim. Just so I understand, you are seeking tab history both for active tabs (those returned by the tabs API) and closed tabs (those returned by the sessions API). Is that correct?

Comment 4

[Tim Nguyen :ntim]

Yep.

Comment 5

[Caitlin Neiman [:caitmuenster]]

Hi Tim, this has been added to the agenda for the July 18 WebExtensions APIs triage meeting. Would you be able to join us? 

Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting

Agenda: https://docs.google.com/document/d/1gWszBunGAyOJ_V8_HMECXJuZ4Gd_HTM_M7xjDSwSxeo/edit#

Comment 6

[Tim Nguyen :ntim]

Filed bug 1381922 for modifying/restoring the tab history.

Comment 7

[Elhem Enohpi]

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.

Comment 8

[Tim Nguyen :ntim]

(In reply to Elhem Enohpi from comment #7)
> 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

Thanks for showing me this!

For reference:
- The proposal that's mentioned in the chromium ticket is here: https://docs.google.com/document/d/1ecws0EwqmfVFjWQhisZZnSxkrj6N9kWvhmLUZ9_cN0Q/edit
- The related google groups post: https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-extensions/tab$20history/chromium-extensions/GiCjBSHEEsg/va1UBTaBWoYJ

Comment 9

[Bob Silverberg [:bsilverberg]]

Caitlin, I am a bit confused. It looks like this was discussed in a meeting on July 18, but it's still marked as design-decision-needed. Was a decision reached at that meeting, as far as you know?

Comment 10

[Tim Nguyen :ntim]

From what I remember of the meeting, accessing the tab history was approved, but modifying the tab history needed more discussion (which is why I filed bug 1381922).

Comment 11

[Caitlin Neiman [:caitmuenster]]

Hi Bob -- it looks like I was out of town during that meeting, so unfortunately my memory won't do much good! :)  Tim, thanks for chiming in. Do we want to quickly confirm with Andy?

Comment 12

[Andy McKay]

As I remember the concept of accessing the history was just fine. We've scoped this bug to just accessing the history, so I think we are good to approve this one.

Comment 13

[Elhem Enohpi]

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.

Comment 14

[TheFly]

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.

Comment 15

[mozilla]

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.

Comment 16

[mark.s.phillips]

For what its worth, losing Session Manager is a deal breaker for me, and I cam currently hunting for alternatives to firefox.

Obviously I hope this gets resolved quickly.

Comment 17

[[e-mail]]

Please make this work. Thank you.

Comment 18

[Tim Nguyen :ntim]

Going to try and look into this.

Comment 19

[Tim Nguyen :ntim]

Some initial research into this:

This is how the back/forward context menu is populated:

https://searchfox.org/mozilla-central/source/browser/base/content/browser.js#3928

I suspect it's possible to re-use that same code for the API.

Comment 20

[Tim Nguyen :ntim]

Attachment: Bug 1378651 - Add tabHistory field in WebExtension Tab object.

Review commit: https://reviewboard.mozilla.org/r/216074/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/216074/

Comment 21

[Tim Nguyen :ntim]

Stuff to add before this is ready for review:
- Add automated tests
- Adding tab history for session restore tabs (convertFromSessionStoreClosedData method)

Comment 22

[Tim Nguyen :ntim]

Comment on attachment 8946004 [details]
Bug 1378651 - Add tabHistory field in WebExtension Tab object.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/216074/diff/1-2/

Comment 23

[Tim Nguyen :ntim]

The second part (adding the property on getRecentlyClosed) is now done.

Now, this just needs automated tests, which I'm currently working on.

Comment 24

[Worcester12345]

(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.

Comment 27

[[e-mail]]

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

Comment 28

[Tim Nguyen :ntim]

(In reply to [e-mail] 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.

Comment 29

[[e-mail]]

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...

Comment 31

[Rob Wu [:robwu]]

I have filed an issue in the WebExtensions Community group at https://github.com/w3c/webextensions/issues/203 to poll for interest in a cross-browser extension API to support this functionality. The next scheduled meeting where this can be discussed is tomorrow (in about 23 hours from now). If you are interested in participating in the live meeting, see https://github.com/w3c/webextensions/tree/main/_minutes#readme for instructions. Meeting notes of the meeting will be published after the meeting.

Comment 32

[john v kumpf]

FYI A good write-up (clear, detailed) of the value of having session manager add-ons that can save and restore (1381922) tab history is here:

https://old.reddit.com/r/firefox/comments/grs6a8/are_there_really_no_session_manager_addons_that/
Including this comment.

Also, for reference, the fairly popular "Tab Session Manager" addon has an issue entry for this problem here: https://github.com/sienori/Tab-Session-Manager/issues/27 (FYI: as of 07/26/2022 "Tab Session Manager" has 111,245 Users, 790 Reviews, and 4.4 out of 5 Stars on Firefox's addon site, and is "Recommended" by Firefox.)

(FYI you can vote for this bug by opening up "Details" at the top and clicking 'Vote', if you didnt know--I didn't ;)

Comment 33

[james]

Someone can correct me if I'm wrong, but I believe any full implementation will have to tie into the HTML History API (window.history). That API has pushState() and replaceState() methods that accept arbitrary data, so any session manager will need to be able to save and restore that information.

As an aside, one nice thing I noticed about the HTML history API is that the specification is loose enough that it could one day be extended to support lossless history trees. (Which Mozilla called trails when they were experimenting with them.) Any WebExtension tab history API should try to match that looseness in case there is such a future extension to the history API.