Allow accessing back-forward history for each tab

NEW
Unassigned

Status

P5
enhancement
2 years ago
17 hours ago

People

(Reporter: ntim, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: triaged[sessions][tabs][design-decision-approved])

Attachments

(1 attachment)

(Reporter)

Description

2 years ago
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.
Flags: needinfo?(ntim.bugs)
(Reporter)

Comment 2

2 years ago
(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
Flags: needinfo?(ntim.bugs)
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?
Flags: needinfo?(ntim.bugs)
(Reporter)

Comment 4

2 years ago
Yep.
Flags: needinfo?(ntim.bugs)
Whiteboard: triaged[sessions][design-decision-needed]
Whiteboard: triaged[sessions][design-decision-needed] → triaged[sessions][tabs][design-decision-needed]
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#

Updated

2 years ago
Priority: -- → P5
(Reporter)

Updated

2 years ago
Summary: Add tab history related info to Session object and a way to restore tab history → Allow accessing back-forward history for each tab
(Reporter)

Comment 6

2 years ago
Filed bug 1381922 for modifying/restoring the tab history.

Comment 7

a year ago
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.
(Reporter)

Comment 8

a year ago
(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
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?
Flags: needinfo?(cneiman)
(Reporter)

Comment 10

a year ago
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).
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?
Flags: needinfo?(cneiman)

Comment 12

a year ago
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.
Severity: normal → enhancement
Whiteboard: triaged[sessions][tabs][design-decision-needed] → triaged[sessions][tabs][design-decision-approved]

Comment 13

a year ago
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 hidden (me-too)
Comment hidden (me-too)
Comment hidden (me-too)

Updated

a year ago
Blocks: 1427928
Comment hidden (me-too, spam)
(Reporter)

Comment 18

a year ago
Going to try and look into this.
Assignee: nobody → ntim.bugs
(Reporter)

Comment 19

a year ago
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 hidden (mozreview-request)
(Reporter)

Comment 21

a year ago
Stuff to add before this is ready for review:
- Add automated tests
- Adding tab history for session restore tabs (convertFromSessionStoreClosedData method)
Comment hidden (mozreview-request)
(Reporter)

Comment 23

a year ago
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

a year ago
(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.
Duplicate of this bug: 1450115
Duplicate of this bug: 1321365
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
Flags: needinfo?(ntim.bugs)
(Reporter)

Comment 28

11 months ago
(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.
Flags: needinfo?(ntim.bugs)

Updated

9 months ago
Product: Toolkit → WebExtensions
(Reporter)

Updated

7 months ago
Assignee: ntim.bugs → nobody

Updated

3 months ago
See Also: → bug 1381922, bug 833791

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.