It looks like the title tag for the page is probably filled in post-load via Angular?

    <title ng-bind='title'>YAQS</title>

Is there a way for JavaScript to poke the browser to update the history item?

I have not tried but maybe history.replaceState() could help.

[mac bug triage]

+sky@ - could you help triage this?

Possibly related:
*  bug 635507  ("history.pushState ignores the new title set via document.title and creates an entry in the history using the previous (out-dated) title as a label")
*  bug 727986  ("Updating document.title does not update the title for the URL in Chome's history entry")
* bug 44140 ("document.title changes not reflected in history view")
*  bug 602416  ("only first hash url stored with title in history when opened in same tab")

Incidentally, it appears no one triages the History component. :-(

+sdefresne as the other OWNER of components/history

I suspect this is a dupe of bug 44140 and possibly also  bug 602416 .  I can't load YAQS here at home to check (and don't really do web development/debug JS anyway), but if someone can confirm that'd be welcome.

Yes, by default YAQS have "<title ng-bind='title'>YAQS</title>". Same with Buganizer and PLX.

[Mac triage] sdefresne@, could you take a look at this or find a more appropriate owner?

Note that it's not specific to Angular; Memegen has the same issue and doesn't use Angular, though it does set the title dynamically.

This is almost certainly a dup of issue 44140.

Issue 44140 has been merged into this issue.

 Issue 602416  has been merged into this issue.

I duped a bunch of bugs into this one thinking it was public; it's not. Oh well.

What's happening here is deliberate, a bugfix that was, in retrospect, clearly the wrong choice given the trail of bugs it's left behind.

When a page sets its title, that title change is dispatched through WebContentsObserver::TitleWasSet(). The history system *does* override that, in HistoryTabHelper::TitleWasSet(). Look at that function:

-----
void HistoryTabHelper::TitleWasSet(NavigationEntry* entry) {
  if (received_page_title_)
    return;
  // ...
-----

If the history system *already has a title* for the page, it drops the title change on the floor. If we look at the declaration of |received_page_title_| we see the comment:

-----
  // Whether we have a (non-empty) title for the current page.
  // Used to prevent subsequent title updates from affecting history. This
  // prevents some weirdness because some AJAXy apps use titles for status
  // messages.
  bool received_page_title_;
-----

It's clear what assumption is being made here. The assumption is that the first title a page sets is its "real" one, and every subsequent title change is a fake title that is used to update the user for some kind of status notification.

The history of this change is hard to track down. That particular comment and associated variable were introduced in https://codereview.chromium.org/7650 at r3601 as a consolidation of two title setting paths, but the behavior of ignoring all titles after the first goes *all the way back to initial.commit*.

Is it time to remove that flag and allow the history service to see all title changes?

(For amusement I'm tracking this behavior past initial.commit. This landed on 2007 May 10 as http://cr/4577479. This was a *very* deliberate change.)

> Is it time to remove that flag and allow the history service
> to see all title changes?
I think it's worth a shot, given the documented complaints about the current behavior and the dearth of complaints about the previous behavior.

There's a good argument that the *last* / *most recent* title the user saw for a page is the one that should be shown in history.

> There's a good argument that the *last* / *most recent* title the user saw for a page is the one that should be shown in history.

That's what I'm saying, too. I'm saying that rather than dropping on the floor all title changes after the first, all the title changes should be sent to the history service, where they will be processed. The result will be that the most recently-set title will be the one attached to the URL.

> dearth of complaints about the previous behavior

Note that Chrome has had this title-ignoring behavior since Chrome 1. The change that implemented it was in 2007, before we shipped. There were no complaints about the previous behavior because there weren't any users.

This change was made for a reason, that titles were (and are) used to notify users. The question is whether the tradeoff of dropping them for a cleaner history is worth it. I don't think so, but that is a valid question to ask.

Re #18: This does mean, however, that my GMail history entry will have the title "Avi Drissman says..."

Could we have some sort of heuristic, whereby we do preserve the title for pushState/fragment navigations and not via DOM manipulations? 

That wouldn't solve the problem with the original post in this thread, where a generic page title is set in the <title> tag and the actual title is set via JavaScript when the page load is complete.

Re #23: Unless we're willing to introduce new APIs (e.g. document.EphemeralTitle) or change behavior in only one codepath (as proposed in #22), I think we end up in a worst-of-both-worlds situation where we just trade one set of broken sites for a different set of broken sites.

A trivial CL to remove the title dropping and always update the history title is at https://crrev.com/c/819571 and in brief testing it seems to fix the problem. The big question of Eric's in comment 24 remains, though, and this really does belong to the History team to ponder.

>>>
> dearth of complaints about the previous behavior

Note that Chrome has had this title-ignoring behavior since Chrome 1. The change that implemented it was in 2007, before we shipped. There were no complaints about the previous behavior because there weren't any users.
>>>

What I meant was that whatever complaints that caused the original change were not documented.  No linked bug, no discussion on the code review, no mention in the changelist description.  We cannot tell what the original motivating problem was (UI? performance? privacy? and so on), whether the motivating web site still exists, etc.  Maybe this changelist (simply described as "Only store the first non-empty title set for a page.") was fixing an issue we haven't thought of and has since been fixed in a different manner.

Evan, do you remember this change?

I don't remember this at all.  I vaguely recall that some sites will do cutesy things with their titles, like animating them.  I don't think it's worth worrying about those because they are lost to history (pun intended!).  I do worry about comment #22.

Maybe we can have a time cutoff? Titles set within, say, 10s of load are remembered in history, but then after that they're dropped? Hopefully the canonical page title would be set during that initial period.

RE #30: That seems pretty reasonable. Could we do a UseCounter to see how many asynchronous title changes would then update the history entry vs. not?

I'm more of a UMA person, living in Chrome rather than Blink, and am thinking about this. We could histogram (|time of title setting| - |time of load finish|) and assume some cutoff. Maybe 99%ile? Or just throw a random time out there (like my 10s).

Doing a UMA would delay a fix, so I'd pass unless we have a plan about how we would use that data to make a decision.

Assigning to avi@ who created https://chromium-review.googlesource.com/c/chromium/src/+/847697 CL.

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

commit 786917e6915ce15449b8097901e5dc152b5e83c4
Author: Avi Drissman <avi@chromium.org>
Date: Mon Jan 08 16:56:56 2018

Allow updating history entries with new page titles.

The old code only allowed a page to set its title in the history
system just once, to avoid the problem of pages using title changes
as a user alert mechanism spamming title changes throughout the
history system. This, however, was problematic with apps that use
frameworks where a generic title is set with the <title> tag with
the real title set later via JavaScript.

This allows titles set within 5 seconds of page load completion to
be saved. This should catch legitimate titles while rejecting title
changes that are just the page looking for attention from the user.

BUG= 782064 

Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet;master.tryserver.chromium.mac:ios-simulator-full-configs
Change-Id: I7a12e88d453a373ff2039e0622828a42bafc7d1a
Reviewed-on: https://chromium-review.googlesource.com/847697
Reviewed-by: Sylvain Defresne <sdefresne@chromium.org>
Reviewed-by: Sergio Collazos <sczs@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527649}
[modify] https://crrev.com/786917e6915ce15449b8097901e5dc152b5e83c4/chrome/browser/history/history_tab_helper.cc
[modify] https://crrev.com/786917e6915ce15449b8097901e5dc152b5e83c4/chrome/browser/history/history_tab_helper.h
[modify] https://crrev.com/786917e6915ce15449b8097901e5dc152b5e83c4/components/history/core/browser/history_constants.cc
[modify] https://crrev.com/786917e6915ce15449b8097901e5dc152b5e83c4/components/history/core/browser/history_constants.h
[modify] https://crrev.com/786917e6915ce15449b8097901e5dc152b5e83c4/ios/chrome/browser/history/history_tab_helper.h
[modify] https://crrev.com/786917e6915ce15449b8097901e5dc152b5e83c4/ios/chrome/browser/history/history_tab_helper.mm
[modify] https://crrev.com/786917e6915ce15449b8097901e5dc152b5e83c4/ios/chrome/browser/tabs/tab_unittest.mm

 Issue 774402  has been merged into this issue.