Thanks for filing the bug! Does the issue repro with sync disabled?

Good question, looks like it doesn't repro with sync disabled actually. So perhaps this is Sync related, although strange that having the device offline when opening history didn't make a difference?

Adding sync component, as in fact this does seem sync related.

Sorry for the long delay!

I could repro this, with two entries in history with slightly different URLs (URL fragment stripped in one of the two):

Entry 1 (longer, received from Google Servers): https://www-foxnews-com.cdn.ampproject.org/v/s/www.foxnews.com/entertainment/cnn-panel-trashes-trump-after-u-s-capitol-visit-to-honor-george-h-w-bush.amp?amp_js_v=a2&amp_gsa=1#referrer=https%3A%2F%2Fwww.google.com&amp_tf=From%20%251%24s&ampshare=https%3A%2F%2Fwww.foxnews.com%2Fentertainment%2Fcnn-panel-trashes-trump-after-u-s-capitol-visit-to-honor-george-h-w-bush

Entry 2 (truncated, provided by local history): https://www-foxnews-com.cdn.ampproject.org/v/s/www.foxnews.com/entertainment/cnn-panel-trashes-trump-after-u-s-capitol-visit-to-honor-george-h-w-bush.amp?amp_js_v=a2&amp_gsa=1#referrer=https%3A%2F%2Fwww.google.com&amp_tf=From%20%251%24s

The second entry is missing the URL fragment.

I don't see any redirects being relevant here: not observed in Footprints and the URLs actually don't redirect to each other.

BrowsingHistoryService seems to implement deduping based on exact URL matches, which in this case is too strict.

I don't really know why the two URLs differ, but it doesn't seem a sync issue, so unassigning for now.

I skimmed through the AGSA code and it looks like the app appends those fragments (including ampshare and referrer). I can't confirm this 100%, but googlers can codesearch for REFERRER_FRAGMENT_PARAM.

On chromium's side, the only alternative would be to implement more aggressive deduping in BrowsingHistoryService, which is questionable.

On to sky@ as owner of history: has this deduping logic in BrowsingHistoryService been discussed from the product's PoV?

I'm not aware of any discussion of trying to find similar visits and prune them. Any heuristics we try would likely cause problems for certain use cases. IMO if the page is triggering visits, we should show them as is and not attempt to decide what is relevant and what isn't. I'm going to close this out.