New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 35 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocked on:
issue 659310



Sign in to add a comment

Sync Should Sync Visits Database

Project Member Reported by mpear...@chromium.org, Jun 7 2013

Issue description


The omnibox ranking function nowadays depends on how often a URL is visited.  This means the ordering will not only depend on how many times the URL was typed into the omnibox and how many times the URL was visited in general and the time of the last visit (these three things are what the omnibox currently uses) but also the time of the second-to-last visit, the third-to-last visit, etc.  This last bits of data come from the Visit database.

Sync does not sync the Visits database.

Perhaps it should.  Not syncing the Visits database makes it slightly more likely that user's omnibox's behaves differently on different machines.

 
By the way, the omnibox only uses the most recent ten visits for each URL, not all visits.  (You don't need to sync the whole Visits database.)  Also, for each of these visits, it only uses the time of the visit and the transition type (link, typed, redirect, etc.), not all the other fields.

Comment 2 by rpop@chromium.org, Jul 17 2013

I assume this new data type would make sense to sync under the "History" UI checkbox. Does that sound reasonable?

Is this something the sync team needs to do, or would you/an omnibox ranking owner be able to implement based on go/syncapi?
> I assume this new data type would make sense to sync under
> the "History" UI checkbox. Does that sound reasonable?

Yes.

> Is this something the sync team needs to do, or would you/an omnibox
> ranking owner be able to implement based on go/syncapi?

I think this is something the sync team needs to do.  I know next to
nearly nothing about the history database so I'm not best person to
implement sync for visits.  The best person would be the person who
implemented typed visit syncing for the history database.  Baring
that, someone else who's familiar with how the history system stores
information.  (I do not; I'm just a consumer of the data.)

--mark

Comment 4 by dubroy@chromium.org, Jul 17 2013

Unfortunately, this is unlikely to happen, at least in the short term. When we implemented the new "full" history sync, we decided that syncing the entire Visits database was not feasible. The fact that omnibox would behave differently was a known consequence.

Maybe it's possible to sync a subset of the data in a way that would be sufficient for the omnibox, but based on comment #1, it seems like we'd still need to do sync almost every single entry, because every time a new visit occurs, it needs to be synced.
Aren't you already syncing a similar order of magnitude number of items for "open tabs" (which has to track every time any tab navigates)?  My recollection is that the decision not to sync visits was made a couple of years ago and could be worth revisiting.

Comment 6 by zea@chromium.org, Jul 17 2013

Open tabs' item count corresponds only with the number of tabs you have (or have had) open on a particular device. Each visit is not synced as an entity. We sync the navigation stack within the tab, but only 10 navigations in each direction (forward/back), so the protobuf size is limitted.

That said, you're right that the update frequency is directly related to the visit/navigation frequency. We can currently handle that frequency (favicons also updates at a similar frequency due to needing to track visit time), but the issue with the visits database is the number of items, and the corresponding download time/cost as well as memory footprint, particularly on mobile devices.

If we're willing to do something similar to favicons though, where we artificially limit the number of items we track, it might be feasible. E.g. track only those visits from the past month, max of 1000 visits, and automatically age out older visits.

We didn't want to do this originally since we'd then have no way of handling history clear properly (assuming the user expectation is that a full history clear on this device also cleared all history on another device), but now that we have delete directives I think we've solved that problem.
I think putting various clamps in makes sense; see comment 1.
Labels: Hotlist-Recharge Hotlist-Recharge-Stale
This issue likely requires triage.  The current issue owner may be inactive (i.e. hasn't fixed an issue in the last 30 days or commented in this particular issue in the last 90 days).  It has also not been modified in a year (prior to this update).  Thanks for helping out!

-Anthony
Cc: zea@chromium.org
Labels: -Hotlist-Recharge -Hotlist-Recharge-Stale SyncEverything
Also see  bug 514840 , which is heavily related.

Comment 10 by rpop@chromium.org, Dec 28 2015

Cc: mpear...@chromium.org
@mpearson, would it be ok to dupe this into your newer bug, which has more fruitful and recent discussion?
> @mpearson, would it be ok to dupe this into your newer bug, which has
> more fruitful and recent discussion?

If you want to merge for tracking purposes, that's your business.  It's fine with me.  However, you should note that they are different requests.  This request is a lot more comprehensive than the newer bug.  The newer bug is mostly about how to color links without syncing the whole visits database, and most of the discussion there is particular to solving that problem.

Comment 12 by rpop@chromium.org, Jan 4 2016

Ok, thanks. I'll leave them separate. 

Comment 13 by rpop@chromium.org, Sep 21 2016

Owner: ew...@chromium.org

Comment 14 by zea@chromium.org, Oct 25 2016

Cc: bre...@gmail.com
 Issue 514840  has been merged into this issue.

Comment 15 by zea@chromium.org, Oct 25 2016

Blockedon: 659310
Cc: ew...@chromium.org
Owner: ----
Status: Available (was: Assigned)
Because this is largely an sync question, I'm kicking this out of the omnibox component.  Sync can prioritize as appropriate.

Comment 17 Deleted

Comment 18 Deleted

Labels: SyncHandoff2018
Components: -UI>Browser>Omnibox
Per comment #16, actually kicking this out of the omnibox component.

Sign in to add a comment