(In reply to James Teow [:jteow] from comment #4)
If I'm understanding this correctly, the issue is that target url is also contained in the Google search results URL. So if the user happens to type a string that matches both the target URL as well as something in the source URL, then source link may show up in suggest.
that's correct, both source and target may show.
Other providers (i.e. Bing) may also use redirects but they may not be including the target URL in the request URL, so we avoid these duplicate entries.
I didn't check what others are doing, off-hand it may be interesting and useful to check if Bing, DuckDuckGo, Yahoo, Yandex, Baidu (I think these are still the most used engines today) do something similar.
I feel into the weeds and stepped through the backend logic of adding URI visits which called
VisitURI in History.cpp. Will do more testing to see how the behaviour of this method changes depending on the conditions.
When the docshell visits a url, is is indeed invoking VisitURI and SetURITitle (this is not a single call because the title must be extracted later from the DOM, there was some discussion about how to do a single call but it's low priority). The docshell knows the most about of the page was visited, and passes that info through flags
History may decide that some visits are not worth showing in the UI, and then sets the hidden field that can be used later by history views to exclude them. The main reason for that is performance of views showing hundreds/thousands of entries and providing to the user history lists that are more useful (like in the history menu). I think the urlbar, like searching through history, completely ignores hidden, the reason is if you are looking for something you should be able to find it.
The other part of this is frecency, when updating frecency from a new visit, IIRC we pass down the redirect info, otherwise we try to extract it from history itself. If we detect a visit is a redirect source, that is 0.
Sometimes we exclude frecency = 0 entries in the urlbar, but I suspect we're not very consistent with that, some queries may not do it, or frecency of these entries may not be exactly zero.