I saw the search URL in my history too. And I saw this happen on desktop too.

Try this, search "warriors game". Click on an upcoming game. Check your history, I saw the first search (2nd in the history list) with the title, but the current page (1st in the history list) with the url. If you check on another device, both have the title of "warriors game - Google Search".

I can repro this on both Desktop and Android. So this is not Android specific issue. Also I don't think it is due to traveling.

I suspect this is related to how we handle the navigation for SRP. Even Chrome on iOS has the same issue. But Mobile Safari doesn't.

+sky for any historical insight into how history works.  Do we only persist titles in the history DB under certain circumstances?

@ainslie, @klobag -- Does this happen only for SRPs or do you see this for normal pages as well?  When showing history, we could likely just general SRP urls based on parsing the query, but that is probably working around the issue instead of solving it.

It's possible this was introduced here: https://chromium-review.googlesource.com/c/chromium/src/+/847697 (adding avi to the cc list). HistoryTabHelper has used GetTitleForDisplay for quite a while, which fallsback to the url in some situations. I'm not entirely sure why HistoryTabHelper uses GetTitleForDisplay() vs title.

+eugenebut +danyao

Adding clamy@ and arthursonzogni@ in case they have some cycles to triage this.

I think I can reproduce the bug by following instruction in comment 1. It is something that used to work?

I tried to bisect, but it is hopeless. I can reproduce the bug as far as I want. I tried up to Chrome 47. So I think it probably never worked.

This is happening with any websites in general that has URL fragment identifiers. Example buzzfeed.com, www.weather.gov etc. 

Here is a simple testcase to repro.

1. Navigate to https://www.w3.org/wiki/UriTesting
2. Click on the sections #1,2,3 from Contents table
3. Goto History

Only entry from step#1 has a page title. Rest of the click records a history entry but no page title. only URL is displayed.

Deleted: Screen Shot 2018-05-16 at 7.25.37 AM.png 35.2 KB

	Screen Shot 2018-05-16 at 7.25.37 AM.png 35.2 KB View Download

The fragmented URL's issue was a bug on iOS and it was solved by https://chromium-review.googlesource.com/c/chromium/src/+/1098137

It has also been cherrypicked to M68
https://chromium-review.googlesource.com/c/chromium/src/+/1104820

The initial bug seems to be related to HistoryTabHelper, re assigning to avi@ since I believe he owns that now.

Scott: re comment 4, I have a gut feeling the issue isn't GetTitleForDisplay(). HistoryTabHelper::TitleWasSet() calls into the history system's HistoryService::SetPageTitle(url, title) which means "set the title of the page with this URL to this title", and URL doesn't feel like a super reliable way to do lookup of history entries. (Look at the implementation of HistoryBackend::SetPageTitle() which has its own notion of redirects that it keeps independent of the real redirect system on the NavEntry?)

Is there a reliable repro for the OP failure? I'm not seeing anything with the Warriors search from comment 1.

Re #11, I think this only happens if the link you click is still a Google search page.

For the next week or two, you can try "world cup 2018", then click a game. I can repro as in #1.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86

commit 87b0ae4a09eef5c30e5771ce84f2789c40ae9b86
Author: Avi Drissman <avi@chromium.org>
Date: Fri Jul 06 15:09:20 2018

Add the page titles to the history service.

The history service assumed that the page would always explicitly
call "set title" when the title was set. However, when a page
does a pushState, the title stays set, and there is no explicit
set title call. Therefore, pass the current page title to the
history system when navigating same-document.

Also, add a bug reference to some old infrastructure that might
be obsolete.

BUG= 840663 , 859902
TEST=as in first bug, the new test in this CL

Cq-Include-Trybots: luci.chromium.try:ios-simulator-full-configs;master.tryserver.chromium.mac:ios-simulator-cronet
Change-Id: Ie5bc17239a20cc2e364daa4fd358f07996c907eb
Reviewed-on: https://chromium-review.googlesource.com/1125159
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#572976}
[modify] https://crrev.com/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86/chrome/browser/history/history_browsertest.cc
[modify] https://crrev.com/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86/chrome/browser/history/history_tab_helper.cc
[modify] https://crrev.com/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86/components/history/core/browser/history_backend.cc
[modify] https://crrev.com/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86/components/history/core/browser/history_backend.h
[modify] https://crrev.com/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86/components/history/core/browser/history_service.h
[modify] https://crrev.com/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86/components/history/core/browser/history_types.cc
[modify] https://crrev.com/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86/components/history/core/browser/history_types.h
[modify] https://crrev.com/87b0ae4a09eef5c30e5771ce84f2789c40ae9b86/ios/chrome/browser/history/history_tab_helper.mm