I think this is working as designed (though maybe not quite as intended), has always been the case, and is not iOS-specific.

History Sync uploads history, but we don't actually download it on all devices. The chrome://history page fetches synced history on demand, but other places in Chrome (like the Omnibox) don't have access to it.

+mastiz who's been thinking of making History Sync more robust.

Thanks for filing the bug!

We currently sync this information if an address is *typed* in the omnibox. I tried this out, and indeed the suggestion shows up in A's omnibox, but not in B's, which seems undesirable.

We could narrow down the scope of this bug and fix article suggestions specifically, that is, sync AUTO_BOOKMARK page transition types in TypedUrlSyncBridge. Handing over to jkrcal@ for further considerations.

That's interesting! A few questions, Mikel:

 - Do we use full history locally for omnibox suggestions but we only sync typed URLs?
 - Does a most likely ntp tile also trigger an AUTO_BOOKMARK page transition?
 - Do we have some statistics on percentage of AUTO_BOOKMARK transitions versus TYPED transition? (to understand the potential increase in sync traffic)

Personally, this is on the edge between WontFix and actually doing something about the issue. I do not think we can fix a lot with the current design of typed URL but AUTO_BOOKMARK seems acceptable.

1. I don't know the details of how the omnibox is populated (mpearson@ would know), but empirically it does display AUTO_BOOKMARKs.

2. NTP surfaces AUTO_BOOKMARK, but there's a boolean (consider_for_ntp_most_visited) that allows callers to filter it out, which we do for article suggestions.

3. cdcs@ once did detailed analysis of this, which I don't recall now, but I'd estimate AUTO_BOOKMARK being in the same order of magnitude as TYPED.