Upcoming changes to the chrome.history API

[Oliver Dunk]

Hi all,

In an upcoming version of Chrome, the data returned from the chrome.history API will be changing.

In particular, chrome.history.getVisits() and chrome.history.search() will return data from other devices that have been synced to the local history database. This may result in more history entries and higher visit counts.

This is part of a larger change in Chrome to sync the history database. Experiments are currently being run with a plan to look at launching over the coming weeks/months.

If you have any concerns, please do let us know.

[Robbi]

Question:
Will the two methods in the future return pages based on the connection state to the browser profile?

I mean, if I'm not connected I only get the local data of the browser being worked on,

whereas if I'm connected I get the data merged with the other devices or will I always get the merged data ?

If the expected behavior will have to be the latter then it doesn't make me jump for joy.

In this case it would be useful to have a new property in the first parameter of these two methods which indicates whether you want to extract only the local browser data or the aggregated one.
This would also guarantee backward compatibility

The "search" method could became something like that;
 query ( object )
    text ( string )
        A free-text query to the history service. Leave empty to retrieve all pages.
    startTime ( optional number )
        Limit results to those visited after this date, represented in milliseconds since the epoch.
    endTime ( optional number )
        Limit results to those visited before this date, represented in milliseconds since the epoch.
    maxResults ( optional integer )
        The maximum number of results to retrieve. Defaults to 100.]
    device: ( optional string )
The source device(s) from which retrieve the pages. Possible values: "local" , "all"  Default to local.

[Oliver Dunk]

Hi Robbi,

Would you be able to share some more about your use case?

If I understand correctly, you're saying that you would prefer for this to be based on the network state? I will check, but my understanding is that this is not how it works. Instead, sync happens periodically and you will see synced data returned from the API regardless of if you are connected to the network.

Notably this would match the results shown in other places like the chrome://history page.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Robbi]

> Would you be able to share some more about your use case? <

Sure, I'm migrating an extension which replace original new tab  ("chrome_url_overrides": { "newtab": "myPage.html"})

The most common thing that this type of extension does is to show a more or less large list of the "most visited sites" and the "last visited pages".

So far the "last visited pages" list was related to the visited pages of the profile used in the browser we are workin on (profile connected or not).
If the API history will change in the future, I understand that I'll have to expect a larger list because it will also include pages from other devices.
The thing, (I state again), doesn't make me so happy.
So I thought I'd suggest adding a parameter in the extraction query that actually allowed us to extract (as we've done up to now) only the pages visited through the browser of the current device.

I hope I explained myself better

Best regards

[Oliver Dunk]

Thanks for clarifying. It sounds like you're not specifically interested in the behaviour based on network access, but more generally want to be able to filter these results out?

Is your extension a public one you can share the link to? No worries if not, but that would be useful when sharing with the rest of the team.

I think exactly how it would be implemented is worth discussing more but I agree that some sort of new parameter in query/results could be a way to address this.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Robbi]

> ...but more generally want to be able to filter these results out? <

In my opinion the decision to filter the results out should be mostly up to the user and secondly to the developer and the default choice should be "take local data only"

Maybe I'm not understanding the ultimate goal of the upcoming changes, or maybe I'm assuming something is wrong.

Browser history (as far as I know), can only be synced with the user's consent.
Let's say I normally use 4 different devices, 3 of which have browsing history sync turned on.
On the fourth device I haven't activated synchronization so I would expect NOT to see any of the pages visited on the other 3 devices (but also as output from the history API) .

Are these statements correct?

> Is your extension a public one you can share the link to? <

Sorry, it's a private extension that run over a intranet (my organization).

https://chrome.google.com/webstore/detail/cut-the-rope-2/kffpbnnhonkfnnjcbgeegicphjkoenaj

If you want to get a rough idea of how it works there is a short video in the "Overview" tab

[Jackie Han]

1. What about delete/add operations?

Does the delete operation(deleteAll, deleteRange, deleteUrl) be synchronized to the remote device, i.e. history items are deleted on both devices or only local data are deleted?

2. If convenient, could you introduce its synchronization mechanism?

For example, how to sync for new records,  how to sync for deletion operations, and how to resolve conflicts when merging.

3. If a page is only visited on a remote device at the moment, the `HistoryItem` can add a new property (e.g. item.remoteVisited) to indicate this is a remote record?

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/a8b87cc4-73db-4a3a-9d34-9b3c2335ca82n%40chromium.org.

[Oliver Dunk]

Hey again,

Thanks for keeping the feedback coming.

Robbi, I think everything you've said is accurate. Without history sync enabled I wouldn't expect your history to be uploaded or for your device to download history from other devices.

In general, wanting to filter out these entries makes sense. I've opened https://github.com/w3c/webextensions/issues/380 to discuss this in the community group and we're having some chats internally.

Jackie, delete operations will affect both local and remote data (this applies to all of the different mechanisms i.e range, URL...).

If convenient, could you introduce its synchronization mechanism?

Are you just curious for some information on how this works, or are you asking to be able to control it from the API?

If a page is only visited on a remote device at the moment, the `HistoryItem` can add a new property (e.g. item.remoteVisited) to indicate this is a remote record?

That sounds like a reasonable request that we could also look at if we update the APIs.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Randy]

I have an extension that lets users search and analyze their history. Many users over the years have wanted the extension to access synced history, so this news is both very surprising and very welcome.

Is it possible to have some kind of opaque device id attached to the VisitItem? In my case, users may want to analyze or search history from a particular device. This would also mean allowing search() to query a specific device id (possibly getVisits() too?).

It would also be useful to have some way to identify that history from a new device has been synced. Maybe a method that returns all the device ids that currently exist in the local database?

Thanks!

--Randy

[Oliver Dunk]

Hi Randy,

Thanks for the feedback!

Would you agree that it would be fair to categorize all of this under feature requests? I definitely think it's something we should look at and I'm not saying we shouldn't - but I want to first prioritize making sure this isn't a significant regression for anyone.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Jackie Han]

Does the above setting (chrome://settings/syncSetup/advanced) decide whether to sync history?

On Wed, Apr 19, 2023 at 5:46 PM 'Oliver Dunk' via Chromium Extensions <chromium-...@chromium.org> wrote:

--

[Oliver Dunk]

Yes, I believe that's the one :)

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Jackie Han]

Thanks Oliver.

From this answer's revision, I know Chrome has supported sync history at least from 2013. So, what I understand is that the history sync feature in Chrome has been around for 10 years, but in the past chrome.history API only returned local history, and now it will return both local and remote history.

[Oliver Dunk]

I think it's slightly more than that but most of my focus has been around the extension changes.

You're right that for an extension developer, the only change should be around the chrome.history API.

Beyond that, Chrome had some history syncing but remote history was handled separately in a variety of places, whereas I believe we are now trying to make the majority of the history APIs internal to Chrome treat them as the same.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Oliver Dunk]

Just to share a quick update, starting in Chrome 115 we have added an isLocal field to VisitItem: https://developer.chrome.com/docs/extensions/reference/history/#type-VisitItem

This should hopefully provide a way for most extensions to adapt to these changes if needed by filtering out visits from other devices.

Appreciate all of the discussion we had in here leading up to this.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB