Some users have started to experience issues in the back end of Kartris with features that use AJAX (in-page postbacks). For example, when editing a version, the stock-tracking checkbox does not postback property to activate or deactivate the warning level field as it should.
The problems seem to coincide with Chrome being updated from version 35 to 36. We have tested with the present version of Opera, which is based on Chrome 35 and this works fine on the same sites that Chrome 36 exhibits problems with. The user agents are almost identical (Opera 35 top, Chrome 36 underneath):
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 OPR/22.0.1471.70
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
This would tend to suggest that the issue is not ASP.NET failing to identify the browser correctly, but is indeed a bug with the way Chrome is handling certain AJAX functionality. In other words, both browsers get served exactly the same page, Chrome 35 handles it but 36 does not.
UPDATE 1
The issue has been raised with the Chromium team behind the core Chrome code. They claim that a subtle change in the way Chrome handles certain javascript brings it into compliance with the standard specification. Unfortunately, because Chrome evidently wasn't in compliance for several years, the AJAX Toolkit and quite possibly many other libraries were written to handle Chrome as it was. So in fixing the bug, they changed Chrome's behaviour without warning, and effectively broke Chrome for many web sites. There is some indication that they will fix this with the next update. There appears to be a javascript hack that would make the code work, but this may well just cause a breakage later when the issue is fixed.
More details here on Chromium - Google Code repository discussion
UPDATE 2
It seems the Chromium team aren't planning on fixing this (well, it's gone very quiet), so we have been looking into fixing this our side. After a great deal of testing and experimentation, we discovered a few things. On the front end, Chrome seems to work fine, so this particular issue should not affect sites ability to serve customers, which is at least some good news. We also found that if you use Chrome but change the user-agent using an add-on to Firefox, the issues in the back end of Kartris are largely fixed. We looked at rebuilding the AjaxToolkit with fixes for Chrome, but identifying the parts of the code to change was not such an easy task - we never quite got a 100% solution.
However, there was a very old hack we had in from the early Chrome days, contained within the Javascript/Webkit.js file. We found that updating this, so that 'Webkit' browsers (i.e. Chrome, Safari, Opera) are treated as Firefox is for the purposes of Javascript seems to fix the issues. We've run through various back end tests and things largely seem to work exactly as we'd expect.
This doesn't seem to be an ideal solution, but in practice since it addresses the issues and is easy to apply retrospectively to older sites with a single file update, we've decided to adopt this for now. If you do find any issues still after applying this fix, please raise the issue on the forum, detailing which version of Kartris you are running and it may be that the solution can be further refined.
You can download the updated file here:
https://kartris.codeplex.com/SourceControl/latest#JavaScript/Webkit.js
UPDATE 3
As of today, 5th September 2014, the Chromium team has acknowledged the issues with the changes made and will revert the behaviour back in Chrome 38. It seems we should be able to pull the fix at some point in future and revert Kartris back to how it was previously too. We will issue another update once Chrome 38 is released.