What's causing cancelled network requests on Android Chrome

Question

On some Chrome on Android devices we are seeing cancelled requests in the Chrome Dev Tools.

It appears to only happen on URLs for articles that follow a /content/:uuid path format and on the www subdomain, we think we've narrowed it down to that rather than all articles since content with a vanity URL doesn't seem to cancel.

What happens is that these requests show as cancelled and then immediately afterwards the request goes again but isn't cancelled.

Most of the time this is fine and the browser loads the requested page, however occasionally from www.ft.com clicking a link to an article will firstly cancel the original request and then, instead of remaking that request for the content, it will remake the request for the page they were already on, in this case www.ft.com.

On devices where this bug happens the initial cancelled request will happen all the time but the reloading of the original page is intermittent (maybe 1 in 6 times?).

The cancelled request, which eventually goes through:

The cancelled request, which reloads the original page:

Bug occurs on these devices:

• Chrome Version: 59.0.3071.125, Android Version: 7.1.2, Model: Pixel
• Chrome Version: 59.0.3071.125, Android Version: 7.1.2, Model: Nexus 6P
• Chrome Version: 59.0.3071.125, Android Version: 5.0.0, Model: Note 3

Bug doesn't occur on these devices:

• Chrome Version: 59.0.3071.125, Android Version: 7.0, Model: Moto G5
• Chrome Version: 59.0.3071.125, Android Version: 7.0, Model: Galaxy S7 (mini)
• Chrome Version: 59.0.3071.125, Android Version: 7.1.1, Model: OnePlus 3

It's somewhat related to What does status=canceled for a resource mean in Chrome Developer Tools?, but we're pretty sure we've ruled out the reasons in the accepted answer.

Debugging we've tried but have not helped:

• Disabling Javascript
• Disabling our tracking Javascript
• Disabling our advertisements
• Disabling our service worker
• Disabling the application cache

Disabling Javascript did change the behaviour, we saw the request still being canceled, but did not see it reload the original page as we were seeing with Javascript enabled.

Other observations:

• Clicking the links in the Chrome Devtools' simulation of the device doesn't cause the request to cancel, only ever using the device directly.

Answer 1

So this particular case is because of what appears to be a bug in the current version of Chrome when there is an app installed that handles deep links.

On my phone (Oneplus 3, Chrome 60.0.3112.107), I was unable to reproduce either the cancelled requests or faulty redirects UNTIL I installed the FT app on my phone.

With the App installed (which I assume is set to handle links of the pattern www.ft.com/content/), clicking on an article links shows the popup to decide whether I want to open in the App or Chrome. This reflects as a cancelled request in the Network tab. Even after choosing to always open in the browser, these links show as cancelled and re-requested (either to the homepage incorrectly, or to the correct article).

I can reproduce this with both the FT and WSJ with their respective apps installed, which implies that it is a bug in the current version of Chrome.

However, the same behaviour does not happen in Chrome Beta (v61.0.3163.60), or Chrome Canary - so I guess it's now been fixed...