(To clarify, according to Jake Archibald, this "bug" happens in Safari too)

Able to reproduce the issue on reported chrome version 71.0.3578.98 and latest chrome version #73.0.3672.0 by following steps as per comment#0 using Windows 10, Ubuntu 17.10 and Mac OS 10.13.6. The following is the bisect information.

Bisect Information:
===================
Good Build: 66.0.3359.0
Bad Build: 67.0.3360.0

You are probably looking for a change made after 540708 (known good), but no later than 540709 (first known bad).
CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/079dd8fa35bab9e08cab73135f35d24223cc23a5..7e26ecaa672c0786362996119f0528f3f07bdb58
Reviewed-on: https://chromium-review.googlesource.com/881836

@Alex Moshchuk: Please help us in reassigning the issue if it is not related to your change.
Thanks.!

Thanks for the report.  This was indeed an intentional change for  issue 803367 , to reduce the amount of unnecessary process sharing between tabs when the user manually navigates to a new site.  It's similar to what's being considered for a new Cross-Origin-Opener-Policy in issue 922191 (discussed at https://github.com/whatwg/html/issues/3740), to give sites a way to explicitly sever window relationships.

In the context of issue 922191, we are talking about the possibility of closing the previous browsing context (and thus setting window.closed to true) if we swap browsing context groups like this.  (In Chrome's terminology, that's a BrowsingInstance swap.)  That's a bit tricky for us to implement in Chrome, but we're looking into it, and we might be able to do it for all BrowsingInstance swaps and not just the ones for Cross-Origin-Opener-Policy headers.

To help us understand the motivation, can you give us a sense for the use case where your site is affected?  In which cases do you expect the opener page to be able to navigate the popup after the user navigates it to a different site?

(Side note: When trying to repro this, we also noticed something unexpected-- the replacement navigation still works if you copy/paste the cross-site URL, but not if you type it.  That behavior difference wasn't intentional, and we should probably make them consistent.)

Hello, my website uses web notifications to tell the user they have a new notification in the Scratch community website (scratch.mit.edu). I am not affiliated to Scratch in any way.
I ask its users to keep my website pinned and open so it can frequently check the Scratch API for new notifications.
I know this would be better as a Chrome extension, but unfortunately these are not allowed to be shared in the Scratch community website for security concerns.
I also have reasons to not make this a push notifications API based system.

Before this change, when the user clicked a notification, a new tab would open to scratch.mit.edu/messages, and when a second notification was clicked, the website would attempt to replace the URL of the previously opened tab, if not closed, so the website wouldn't have to open a new tab for every single notification click. After replacing the URL, it would focus the tab. This would always work.

Now, when the user used the opened tab to navigate to another site, my website just focuses that tab, but doesn't replace the URL of it, breaking this functionality, and leaving users confused.
I don't have any other option but to remove this functionality from Chromium based browsers and "spam" my website users with a new tab per notification click, which is pretty annoying.