Quick update: "Does this work in other browsers? Yes" it wasn't confirmed if it affects other browsers (only tested Chrome and Firefox [FF not affected]). I have not tested if Opera would be affected. Feel free to have a look into that.

Unable to reproduce the issue on Win-10 using chrome reported version #64.0.3253.3, latest stable #62.0.3202.75 and latest canary #64.0.3260.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Visited the demo page https://muffin.cloud/test/windowopener
2. Pressed the 'trust me' hyperlink -- it'll open a new tab
3. Waited for the text 'check your browsing history' to show up
4. Checked the previous tab.
5. Observed that tab title had the full URL since there is no new title being set on 'done.html' as expected.

andresantosuk@ - Could you please check this issue on latest canary #64.0.3260.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 781488.webm 1.0 MB

	781488.webm 1.0 MB View Download

krajshree@ In the screencast, I do see that the issue is present (tab is still titled 'YouTube' when it shouldn't be).
I tried this in a Windows 7 x64 VM with Google Chrome Canary v64.0.3260.0 (completely fresh, settings untouched, latest at the time of posting) and that is also affected.

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is racy behavior, its very hard to bisect. I can consistently reproduce after 6593874a60b5694724d6a226ab1b0dfca71052a5 (which removes a process swap), and I cannot reproduce before 0dbded05ad0ba1c3d8388fd649130509ab97f07a, so I suspect this may be PlzNavigate related, but it may also be there before that and PlzNavigate only changed timings.

jam@, can you take a look?

Adding avi@, who also has looked at title stuff lately.

This seems at first glance to be a bit different than  bug 96041 . In that case, we're re-using a NavigationEntry, and a page with no title doesn't clear out the old title.

In this case, the second page uses "window.opener.location = xxx" to set the location of the first page. I would imagine that assigning to the opening window's "location" property would be a NEW_PAGE entry that would avoid this.

Charlie, is "window.location = xxx" equivalent to "window.location.replace(xxx)"? If so, this might be a duplicate of  bug 596707 . If "window.location = xxx" is equivalent to "window.location.assign(xxx)" then this should already be NEW_PAGE and something is rather wrong here that we're not getting a fresh NavigationEntry.

Avi: window.location = xxx is the same as location.assign.  It creates a new entry that you can go back from (unlike location.replace), as long as it's not during page load, when it might be classified as a client redirect.

The usual cause of the title not setting is loading a page with no title with a NavEntry that already has a title. If window.location = is the same as location.assign, it's not clear then to me how the old title is being carried through. I haven't looked in detail at this though.

I've run this through my logging branch. Here's what I found.

The state before we load the "done.html" page is:

/---- At the beginning of RendererDidNavigate ----
| 2 entries:
| 0 q5 0x7fa689c6ed50
|               https://muffin.cloud/test/windowopener/
|               “”
| 1 q9 0x7fa689e74ad0
|               https://www.google.com/
|               “Google”
| 
| Last committed entry is entry 1
| 
| Pending entry is not in the entry list
| Pending entry is 12 0x7fa689c87550 https://muffin.cloud/test/windowopener/done.html “”
\------------------------------------------

So the controlling page's "window.location = https://muffin.cloud/test/windowopener/done.html" turns into a new pending navigation entry. In ClassifyNavigation, as a renderer-initiated navigation, params.nav_entry_id == 0 so it takes that block. There is a last committed entry, so it gets classified as NAVIGATION_TYPE_EXISTING_PAGE. And as per the comment in NavigationControllerImpl::RendererDidNavigateToExistingPage,

    // This is renderer-initiated. The only kinds of renderer-initated
    // navigations that are EXISTING_PAGE are reloads and location.replace,
    // which land us at the last committed entry.

the last committed nav entry is modified. We end with:

/---- At the end of RendererDidNavigate ----
| 2 entries:
| 0 q5 0x7fa689c6ed50
|               https://muffin.cloud/test/windowopener/
|               “”
| 1 q9 0x7fa689e74ad0
|               https://muffin.cloud/test/windowopener/done.html
|               “Google”
| 
| Last committed entry is entry 1
| 
| No pending entry
\------------------------------------------

---

Charlie, "window.location = xxx is the same as location.assign" might be what we intend, but it's clearly not happening here.

If we intend "window.location = xxx" to be equivalent to "location.assign" we should add that to our test. I don't see a "window.location" direct assignment anywhere in our test. I will add it and report as to what I find.

I just added a block to test location assignment to the browsertest, and it correctly classifies as NAVIGATION_TYPE_NEW_PAGE. Something deeper is happening.

Two comments aimed at Charlie:

- Patching in https://chromium-review.googlesource.com/c/chromium/src/+/567683 fixes the title issue, as you suspected in our meeting.

- Patching in that CL still doesn't create entries in the navigation history list. It's not clear if that's the right thing to do. I thought it would be, but Safari seems to agree with us in not creating them. (Firefox, BTW, only creates one, which is even more confusing.)

Thanks.  I've been in meetings most of the day and couldn't debug it myself, but I strongly suspect we're treating this as a client redirect because of the timing (and that the behavior would be the same whether it's location=xxx, location.href=xxx, or location.assign(xxx)).

In that sense, yes, my CL will leave it classified as a client redirect, but it will do so via NEW_PAGE with replacement rather than EXISTING_PAGE, hence fixing the title bug.  In that sense, hopefully this bug will be fixed when I land my CL, so I suppose it makes sense to assign to me.

As for why this is treated as a client redirect, japhet@ knows the magic there better than I do.  I think he's mentioned that any navigation before the document's onload event will be classified that way.  It looks like the repro case is using a new navigation every second, which might hit that case (though it could be racy):

index.html:
click this: <a href="demo.html" target="_blank">trust me</a>

demo.html:
<span id="txt">wait here until i say so ...</span>
<script type="text/javascript" nonce="SCRmainsrc">
setTimeout(function() {
    window.opener.location = 'https://github.com/';
}, 1000);
setTimeout(function() {
    window.opener.location = 'http://google.com/';
}, 2000);
setTimeout(function() {
    window.opener.location = 'https://youtube.com/';
}, 3000);
setTimeout(function() {
    window.opener.location = 'https://muffin.cloud/test/windowopener/done.html';
    document.getElementById('txt').innerHTML = 'check your browsing history';
}, 4000);
</script>

Ok, I've landed my CL in r514951 to fix  issue 596707 , and I've verified that it fixes the bug in 64.0.3263.0.

I've also confirmed locally that the navigations that demo.html was doing on the opener were being treated as client redirects, since they were happening during load.  We had been classifying client redirects as EXISTING_PAGE, and that didn't fully update the title in this case (when there is no new title).  Now that it's NEW_PAGE, we don't have a stale title on the NavigationEntry.

Simpler and more reliable repro steps:
1) Visit http://csreis.github.io/tests/simple.html
2) In the DevTools Console, enter:
location.replace("http://csreis.github.io/tests/");

This caused the same bug and didn't update the title, since simple.html has a title and the list of test pages does not.  These cases are now fixed since we classify them as NEW_PAGE.