Issue with cancelled AJAX requests following Chrome updates

[Ryan Heath]

Howdy,

Our web app is experiencing some very strange behaviour following some recent Chrome Updates.

We first saw the issue following the 60.0.3112.101 update and posted the update in the attached PDF which basically summised that the issue was related to the update process itself and was resolved by a hard reset of all chrome processes but as we could no longer replicate it, we were unable to investigate further.

We have since started seeing the issue again following the 61.0.3163.79 update and at present we are still able to replicate it. Now we have dug a little deeper it seems we can resolve the issue by closing Chrome, deleting the local state file (C:\Users\<username>\AppData\Local\Google\Chrome\User Data\Local State) and then re-opening chrome and browsing back to our app. This resolves the issue until the next time you restart chrome, at which point it returns, unless you repeat and delete the local state file again. 

What are we doing?

When a user logs into our app, we automatically initiate a custom protocol URI request to send a message to a client app installed locally on the device, this then reports device information back to the server and the app periodically polls the server for the device information. The protocol request is triggered simply using a window.location='ourprotocol://blah' (but obviously wrapped in a load of success/failure handling JS). 

What problem our we seeing?

The problem we are seeing post-update seems to be either:

1) Some form of conflict between the AJAX requests that poll for other information and those that poll for device info status (which happen at the same time) - we wondered whether the browser was seeing the protocol request as a "navigate away" and cancelling all subsequent requests OR

2) Some form of security issue with the requests being cancelled because they are not user-actioned. 

However, neither of these really make sense when you consider that refreshing the local state file resolves the problem, which suggests this isn't either an app issue or a result of an actual change implemented in the newer version. 

Symptoms:

Basically there are two requests happening at around the same time (application/list and get-device-info), both are showing as cancelled (in the same manner) as shown in the attached net-stat-log.txt. This results in failure for our app to load. One thing to note is that the protocol request IS permitted and DOES complete, meaning the client is triggered and device info sent, so if you refresh the page, our app has no need to do the second set of AJAX calls (only the application/list requests) which execute without issue. 

Investigations so far:

It is intersting to note that we if switch the protocol launch method to launch in a hidden iframe by setting its location.href then we don't see the issue! I include this as a possible clue but at this stage, changing the product is not a viable solution as we have 400+ customer installations world-wide that we can't update without change control approval and remote access. (Please no comments on this, we are actively moving to a better deployment methodology so we can be more flexible!) 

We have grabbed a copy of the Local State file from a machine experiencing the issue from when it was working and when it stopped, both of which are attached. We're not really sure what we should be looking for in here but it might offer someone an idea. 

We are continuing our investigations but wanted to put this out to the wider community in the hope of getting some assistance as it makes no sense currently why a local state file could have such a heavy impact on browser behaviour

Any advice is much appreciated

[PhistucK]

This group discusses technical browser development issues, not web development.

You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.

Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.

☆PhistucK

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/fc1e57ca-3b0a-45bc-88d6-72b1eeef3b69%40chromium.org.

[Ryan Heath]

@PhistucK Thank You. I could not find a similar issue so I raised it as below:

https://bugs.chromium.org/p/chromium/issues/detail?id=762945&q=ERR_ABORTED&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified

I posted the issue here as I see it as likely to be a development issue seen as this is unexpected behavior occuring following an update and seems to be related to the re-build of the Local State file, rather than a difficulty on our part to implement something or an issue we have noted whilst developing our product. I do not see this as a web development issue as the behaviour of our code has been consistent for years and remains consistent still, apart from when (what appears to be) changes to the Local State file affect it's behaviour in some way. To me it seems specifically related to something the browser itself is doing and this appears to be affecting how it performs in a non-consistent way. 

Thank you for your quick response and I welcome anyone's comments on either thread

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.