Proposal: Distinguish local/synced items in History API

[oliverdunk]

We are making some changes in Chrome to begin exposing synced history items in the chrome.history API: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/lBpRw_Te4tw/m/jwRxMBBaAAAJ

It could be useful to add a new property to VisitItem to indicate if an item was visited locally or came from sync.

Opening this for discussion.

[zombie]

Overall we're supportive of this proposal. Small point of discussion might be whether by default, the results of chrome.history.getVisits() should include remote visits or not.

I want to follow up to investigate what's current behavior in Firefox.

[Rob--W]

During today's meeting I asked about the meaning of the id property, because its existence in the API is currently incomplete. It exists but cannot be used to query anything. With local history, id can easily be unique, stable and consistent across browsing sessions. With sync'd history, it would be very desirable if the id maintains these expected properties. From the implementation POV, if collisions with local history ids cannot be avoided, then a way to add an unambiguous tag, e.g. "sync-device-[actual-id-here]".

FYI: I previously elaborated on the incomplete "id" in the history API in a comment at https://phabricator.services.mozilla.com/D167492?id=674672#inline-924336 :

should the history api have a new method (e.g. history.get()) like with bookmarks.get()?

That could be a future enhancement. It's not clear to me why the history API returns an id that cannot be used anywhere else.

The API originates from Chrome, which was implemented here: https://bugs.chromium.org/p/chromium/issues/detail?id=22952

It links to a design document that's 404 right now, but an archived version is available at https://web.archive.org/web/20111103015124/https://www.chromium.org/developers/design-documents/extensions/history-api

That archived version does show that there was an intent to add a way to search by ID.

In any case, the addition of a way to query by history ID is independent of the menu feature requested here.

[oliverdunk]

With local history, id can easily be unique, stable and consistent across browsing sessions. With sync'd history, it would be very desirable if the id maintains these expected properties.

Confirmed that this will remain the case with synced history in Chrome. The only exception is that these are local IDs so they are not guaranteed to be the same for the same history event on two different devices.

[oliverdunk]

We have implemented the isLocal field in Chrome 115+: https://chromium-review.googlesource.com/c/chromium/src/+/4496401