Tab session history (back/forwards)

UNCONFIRMED
Unassigned

Status

()

Toolkit
WebExtensions: Untriaged
UNCONFIRMED
5 months ago
2 months ago

People

(Reporter: Alex Vallat, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [design-decision-needed][sessions])

(Reporter)

Description

5 months ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20161130004019

Steps to reproduce:

I would like to request an API to access and manipulate the session history (back/forwards) for tabs (areas currently covered by nsISHistoryListener, nsISHistory and nsISHistoryInternal)

The functionality that would be required to support my addon (https://addons.mozilla.org/en-US/firefox/addon/backtrack-tab-history) is:

* Ability to iterate over the session history for a tab, returning serializable entry objects
* Ability to add entry objects to the session history, including those that have been returned from iteration on a different tab, and those that have been deserialised
* Ability to manipulate the current entry pointer (or alternatively to add entries both forwards and backwards from the current position)
* Ability to listen for and intercept session history navigation. It must be possible to detect going forwards or backwards or directly to a session history entry, and to prevent that navigation from occurring (and substitute alternative behaviour).

It would also be very helpful if those entry objects could have persistent IDs of some sort, so that on restoring a tab (either from undo close, or from session restore) some continuity of history entry objects can be kept.

For completeness, it should also be possible to remove entries from the session history.

Updated

4 months ago
Whiteboard: design-decision-needed

Comment 1

2 months ago
Does the session API cover some of this?

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/sessions
Flags: needinfo?(bugzilla)
Summary: WebExtensions API request: tab session history (back/forwards) → Tab session history (back/forwards)
Whiteboard: design-decision-needed → [design-decision-needed][sessions]
(Reporter)

Comment 2

2 months ago
No. The sessions API allows you to retrieve and restore recently closed tabs or windows, and to restore them. It is unrelated to tab session history.
Flags: needinfo?(bugzilla)
To be discussed at 2/21 WebExtensions triage meeting. 

Agenda: https://docs.google.com/document/d/1H4sjnRFc87NZXZsM6XIgwWaoV2bdRFepiG28G7WzgPs/edit
Flags: needinfo?(amckay)
Flags: needinfo?(lgreco)

Comment 4

2 months ago
I think Luca said that we could do a lot of this with a combination of the existing WebNavigation APIs in combination with sessions. If that's the case figuring out exactly what is requested would be nice.
Flags: needinfo?(amckay)
(Reporter)

Comment 5

2 months ago
I don't see anything in the WebNavigation API that would help. The only thing that appears even remotely related is the onHistoryStateUpdated event, and that's a rather specialist event for determining when the URL is updated without actual navigation. Not really relevant here. As I posted before, the Sessions API is not related to this either.

For figuring out exactly what's requested, I'm not sure I can make it any clearer than how I laid it out in the first post. At a higher, conceptual level, what is required is control over existing ordinary entries in the back/forwards history list. Not just to add new custom entries (the html5 history API allows this), or to navigate to existing ones.

Comment 6

2 months ago
The webNavigation API has the onHistoryStateUpdated (that is fired when a webpage, or one of its subframes do not navigate to a different document, and it is not related to a change to the reference fragment), and the onReferenceFragmentUpdated (that is fired when a webpage, or one of its subframes, changes the fragment identifier).

By listening and collecting the navigation details from the webNavigation.onCommitted event and the two events above, it should be possible to build something similar to a "serializable history", at least of any tab (and its subframes) created after the addon has been installed and enabled.
 
These 3 events support the transitionQualifier property (https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webNavigation/transitionQualifier), and its value is "forward_back" when the navigation is related to the history.

The combination of the above features should be enough to allow this part of the described needs: "Ability to listen for and intercept session history navigation. It must be possible to detect going forwards or backwards or directly to a session history entry"

On the other hand, the webNavigation API (nor any of the other available API) can "prevent that navigation from occurring (and substitute alternative behaviour)".

As Alex pointed out in Comment 5, a subset of the history manipulation described can be achieved with the help of a content script and the history API available in the webpage itself (https://developer.mozilla.org/en-US/docs/Web/API/History_API).
Flags: needinfo?(lgreco)
(Reporter)

Comment 7

2 months ago
Building a parallel history seems like a very strange and complex approach to use, and would not meet the requirements in any case. A history entry is far more than a URL and title, as I'm sure you're aware.

When I talk about serializable history entries I mean taking a complete existing history entry and producing a serialized object from it that can be used to recreate that same history entry.

This request is not about the ability to add special custom entries to the history list. It is about the ability to access, copy and manipulate the actual entries in the history list. If the API is not sufficient to take some entries in a tab's session history and copy them into another tab's session history such that they are identical in the new tab to the old, then it is of no value to this use-case.
You need to log in before you can comment on or make changes to this bug.