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.
Does the session API cover some of this? https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/sessions
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.
To be discussed at 2/21 WebExtensions triage meeting. Agenda: https://docs.google.com/document/d/1H4sjnRFc87NZXZsM6XIgwWaoV2bdRFepiG28G7WzgPs/edit
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.
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.
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).
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.