1409754 - Add access to history.VisitItem and history.HistoryItem by ID in the history by API

Status: RESOLVED WONTFIX

(WebExtensions :: General, enhancement, P5)

Description

[Noé]

Hi,

The history API for web extension could be a bit more flexible.

As far as I understand the API, it's not possible to access a VisitItem from its id.

Use case example: gathering all the visits to a page and extract how the user ended up on this page.

Its possible to gather all the visits to a single page with history.getVisitis().
Each history.VisitItem has a visitId and an optional referringVisitId.
This referring id identifies the previous visit.
However from this id, it's not possible to access directly the corresponding visitItem.


In the same way, I could not find a way to access an history.HistoryItem by its id (typically stored in history.VisitItem).


Noe

Comment 1

[Caitlin Neiman [:caitmuenster]]

Hi Noé, this has been added to the agenda for the WebExtensions APIs triage meeting on March 13, 2018. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1b4r8z964_Est_mbSYUx9jtRt-HTtXgu-EAzM_3yr7ww/edit
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 2

[Caitlin Neiman [:caitmuenster]]

This is tentatively approved, pending follow up by Shane on the following issues: 

* Are IDs a supported feature? 
* Will they continue to be a supported feature?

Comment 3

[Shane Caraveo (:mixedpuppy)]

My primary concern here is whether the history db will change in some way that will conflict with adding query/get/etc based on a history item id.  IMO it makes sense to add that or something to handle the use case.

Specifically, querying using nsINavHistoryResultNode.pageGuid/visitId/fromVisitId.

https://searchfox.org/mozilla-central/source/browser/components/extensions/ext-history.js#62

Comment 4

[Marco Bonardo [:mak]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #3)
> My primary concern here is whether the history db will change in some way
> that will conflict with adding query/get/etc based on a history item id. 

Let's go back a bit to where we started from.
The visitId and referringVisitId have been added just to cope with Chrome APIs.
While visit ids are unlikely to go away from Places, they are not unique ids, and as such they are mutable. If you collect and store a visitId, we can't assure that after some time it will still point to the same visit as before.
To ensure immutability, we should add a unique id to each visit, and relate visits using that. It would be *very* expensive on our side, thus we are unlikely to.
The Chrome APIs themselves don't seem to provide any tool to do anything with these ids, I wonder if it's for a similar reason. Personally, I would have not exposed them in the API.

Anyway, we should clarify in the API documentation that visitId and referringVisitId are valid FOR THE CURRENT SESSION, if we didn't already.

With this premise, it would be interesting to collect more use-cases, because it's possible the requests can be served better than allowing to query a mutable id. IF POSSIBLE, I'd consider id and referringVisitId "legacy" and rather expose something more useful to cover the use-cases.
Otherwise, if we decide to allow querying for them, we should make really clear that if you need to store info about a chain of visits, you are on your own, we won't ensure immutability of these ids.

(In reply to Noé from comment #0)
> Use case example: gathering all the visits to a page and extract how the
> user ended up on this page.
> 
> Its possible to gather all the visits to a single page with
> history.getVisitis().

So, considered you have all the visits, and each visit has a transitionType that tells you HOW that visit happened, would it be enough to have a referringVisitUrl in addition to referringVisitId? Do you need to actually walk up the full chain of previous visits?
Knowing a bit more about the expected use-cases may help designing something more specific.
Knowing the url of the referringVisit is useful for a single lookup, but not to rebuild a chain.
I wonder if visitItem could have a lazy getter or a method to get the chain of referring url/transition (that is what matters, ids are not really necessary).

Comment 5

[Shane Caraveo (:mixedpuppy)]

Noé, could you outline the use case more?  See comment 4.

Comment 6

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958