This issue is tracked internally at Salesforce as W-5369229. My customers report the behavior worked in 67.0.3396.79 and is not working in 68.0.3440.106. I'm able to reproduce in 69.0.3497.100.

Attempted workarounds that HAVE NOT solved the issue:
1) Wait until DOMContentLoaded to execute location.replace()
2) Wait until load to execute location.replace()
3) Use setTimeout(fn, 0) to execute location.replace()

Workaround that DOES solve the issue, but introduces other regressions in my app:
1) Use setTimeout(fn, 100) to execute the navigation after 100ms.

I've attached the net-internals export that reproduces the issue. Start at event 14300. I see the request to load the URL, but it is cancelled after HTTP_STREAM_PARSER_READ_HEADERS. I sometimes see this behavior if the navigation is canceled in a "beforeunload" handler, but that isn't the case here. There is hardly any JS in the servlet.Integration page, so there are event handlers created at all.

t=47021 [st=0]   +URL_REQUEST_START_JOB  [dt=9]
                  --> load_flags = 18432 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE)
                  --> method = "GET"
                  --> url = "https://c.na49.visual.force.com/apex/DestinationPage?sfdc.tabName=01r5A000001A1KB"
t=47021 [st=0]      NETWORK_DELEGATE_BEFORE_START_TRANSACTION  [dt=0]
t=47021 [st=0]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=47021 [st=0]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
                    --> net_error = -2 (ERR_FAILED)
t=47021 [st=0]      HTTP_CACHE_CREATE_ENTRY  [dt=0]
t=47021 [st=0]      HTTP_CACHE_ADD_TO_ENTRY  [dt=1]
t=47022 [st=1]     +HTTP_STREAM_REQUEST  [dt=0]
t=47022 [st=1]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                      --> source_dependency = 14302 (HTTP_STREAM_JOB_CONTROLLER)
t=47022 [st=1]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                      --> source_dependency = 14303 (HTTP_STREAM_JOB)
t=47022 [st=1]     -HTTP_STREAM_REQUEST
t=47022 [st=1]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=47022 [st=1]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                      --> GET /apex/DestinationPage?sfdc.tabName=01r5A000001A1KB HTTP/1.1
                          Host: c.na49.visual.force.com
                          Connection: keep-alive
                          Upgrade-Insecure-Requests: 1
                          User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
                          Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                          Referer: https://na49.salesforce.com/
                          Accept-Encoding: gzip, deflate, br
                          Accept-Language: en-US,en;q=0.9,fr;q=0.8,de;q=0.7,ja;q=0.6
                          Cookie: [292 bytes were stripped]
t=47022 [st=1]     -HTTP_TRANSACTION_SEND_REQUEST
t=47022 [st=1]     +HTTP_TRANSACTION_READ_HEADERS  [dt=8]
t=47022 [st=1]       +HTTP_STREAM_PARSER_READ_HEADERS  [dt=8]
t=47029 [st=8]          CANCELLED
t=47030 [st=9]   -URL_REQUEST_START_JOB

Here's a screenshot of the developer console when I observe the issue.

Deleted: Screen Shot 2018-09-24 at 09.31.18.png 281 KB

	Screen Shot 2018-09-24 at 09.31.18.png 281 KB View Download

I can't verify because the  na49.salesforce.com page gives me a "Verify Your Identity" interstitial, which I can't get past.

Setting component to SiteIsolation for further triage.

Thanks for the report.  As noted in comment 5, we'll need a way to reproduce this to investigate, but a verification code is needed to proceed.  Is there some way to disable that requirement or provide a different set of repro steps?

Adding Navigation label; maybe arthursonzogni@ might know why the request is getting canceled (once we're able to repro it).

Thank you looking into this. I believe I have disabled the two-factor for your IP address, can you please try again? Please send me your IPv4 address offline if this does not work; msenn@salesforce.com

Thank you for providing more feedback. Adding the requester to the cc list.

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

Mac triage: assigning to creis@ for followup.

Sorry, I missed that this was updated!  Thanks for adjusting the two-factor auth in comment 7.  I'm able to repro the bug in 69.0.3497.100 on Mac and Linux and 69.0.3497.95 on ChromeOS (with Site Isolation).

Interestingly, I can't repro on newer builds.  I'm not seeing it on Mac (with Site Isolation) on 70.0.3534.4 or 71.0.3568.0, after repeated attempts.  I'm also not seeing it on a recent Linux debug build (71.0.3564.0).  Are you able to repro on Chrome Canary?

If not, we can run a bisect to see where a potential fix might have landed (though admittedly it's hard to bisect something with an inconsistent repro).

If it does still repro for you on Canary, we can try to figure out what the difference is.

Arthur: I ran a bisect on Windows and came up with your r584502 (which landed in 70.0.3529.0) as the point at which the bug stopped repro'ing for me.

I'm not 100% confident in the bisect because it sometimes took a few attempts to get a repro (I tried 10 times per revision before classifying it as "bad" / "no repro"), but it does seem plausible that this could be the fix.  In particular, the CL lists issue 873541 as one of the bugs it was fixing, and that sounds very similar to what we're observing here (where an iframe was failing to load).

Can you comment on whether it seems likely that your CL would help with this bug?  If so (and if we can get confirmation the bug doesn't repro for the reporter after 70.0.3529.0, then we can consider this one fixed.

Thanks!

This seems to me VERY likely.

Before my CL, the renderer was able to shutdown itself. This responsibility must be given to the browser process only or at least having some state synchronized to prevent race conditions. When the renderer process was shutting down itself, there was no state updated on the browser. It wasn't aware and could try to reuse a process. If it tries to make a navigation, it will likely fails after a few moment.

Having more renderer processes and switching between them more often increases the probability of seeing one being reused. This bug is about site-isolation, it increases the likelihood my patch fixed it. 

In the repro step:
> 2) Do NOT open any other tabs on this site.
Keeping another tab open on this origin means the renderer process will stay alive during the navigation on the other tab.

Reporter: Please let us know if you can reproduce the bug with Chrome version >= 70.0.3529.0.

Thanks!

Great!  I'll mark it fixed, pending verification by the reporter.  (And indeed, the navigation that fails is a cross-site location.replace, which would be cross-process in Site Isolation and thus vulnerable to a race like that.)

The fix will go out in M70, which should reach the Stable channel around October 16.  (There aren't any more M69 releases planned.)

Thank you all for the triage and the bisect. I'm unable to reproduce myself in Canary 71.0.3573.0 and my customer reports the same.

Sounds like the best workaround until M70 is to keep another tab open on the site. I'll suggest this rather than making a Salesforce code change.

mseen@. Thank you for checking it doesn't reproduce anymore on your side!
Did you also check on M70 beta?

As Charlie said, M70 will reach stable in ~8 days. The users should no more see this bug in 2 weeks.

Yes, I have just checked the M70 beta, version 70.0.3538.54, and am unable to reproduce the issue. Thank you again for finding the root cause.

Thank you for checking on M70 beta!