API to query the navigation history of a specific tab

[Rob--W]

The tabs extension API currently has the goBack and goForward methods, which originated from a contributor at https://crbug.com/830622.

In Firefox, a feature request was filed to ask for the possibility of determining whether it is possible to know whether a navigation is possible, at https://bugzilla.mozilla.org/show_bug.cgi?id=1760523. The proposal is to introduce the canGoForward and canGoBack methods. While the implementation is straightforward, I believe that we can do better than adding a new method for every possible use case. The general underlying feature is the ability to access the back-forward history of specific tabs. That feature request was filed a few years ago and has amassed hundreds of votes at https://bugzilla.mozilla.org/show_bug.cgi?id=1378651, and one in Chromium at https://crbug.com/41321.

To avoid the unnecessary cost of retrieving this information, this information is not exposed via tabs.Tab by default, but via a new method, e.g. tabs.getBackForwardHistory(tabId) that returns a list of objects, with the properties url, title, favIconUrl and a boolean that indicates whether the entry is the current entry. Since the retrieval of favicons could be expensive and not all use cases may need it, I would also be in favor of an options parameter to the method that allows callers to opt in to receiving favIconUrl information. The tabs permission shall be required (either to use the method itself, or to read the url, title and faviconUrl properties).

Questions:

• Is there (cross-browser) interest in offering read-only access to the back-forward histories of specific tabs?
• Is the proposed API good as-is, or are there preferred alternatives?

PS. Beyond accessing the back-forwards history, there is also a request for modifying the back-forwards history, at https://bugzilla.mozilla.org/show_bug.cgi?id=1381922. Writing to the back-forward history is more involved, e.g. for session managers there may be a need to write scroll offsets and history.state. Writing to the back-forward history is out of scope for this issue, but if there is interest beyond read-only access, it may be useful to account for that possibility in the design of the read-only API.

[birtles]

To avoid the unnecessary cost of retrieving this information, this information is not exposed via tabs.Tab by default, but via a new method, e.g. tabs.getBackForwardHistory(tabId) that returns a list of objects, with the properties url, title, favIconUrl and a boolean that indicates whether the entry is the current entry.

Perhaps there's no useful overlap, but it might be worth considering if any parts of this should align with the proposed navigation API at https://github.com/WICG/navigation-api/blob/main/README.md. That API only applies to same-origin navigations, supports mutation of history, and doesn't expose things like the title, favicon, etc. so it might not be relevant.

[Rob--W]

The outcome of the discussion is generally favorable towards the feature, but there are concerns over potential privacy issues with exposing the history of individual tabs. More details are in the meeting notes at https://github.com/w3c/webextensions/blob/main/_minutes/2022-04-28-wecg.md, which will be available in once #206 is merged.

[Robbendebiene]

I just want to add that along with this API something like a tabs.goTo(int index) similar to the web History API should be added. While this API proposal does not necessarily rely on this method, looking at the use cases this API tries to solve/cover it becomes clear that jumping to a specific point in the tab history is one of the most common demands and tightly coupled to this feature.
One could argue that this is already possible using the web History API, which is true. However one reason tabs.goBack and tabs.goForward have been implemented is that using the web History API requires the usage of content scripts which in turn require additional permissions.