We recently moved to jQuery 1.6 and ran into the attr() versus prop() back-compat issue. During the first few hours after the change was deployed everything was fine, then it started breaking for people. We identified the problem pretty quickly and updated the offending JS, which was inline.
No we have a situation where some folks are still having issues. In every case thus far, I could get the user up and running again by telling them to load the page in question then manually refresh it in the browser. So something must still be cached somewhere.
But there are basically only two potential culprits: First, the jQuery library itself, but this is loaded with the version number in the query string so I think browsers will be refreshing it in their cache. Second, the inline javascript. Is it possible that this is being cached in the browser?
We are using APC, apc.stat=1 so it should be detecting that the PHP files have changed. Just to be on the safe side I nuked the opcode cache anyway.
To summarize, I have two questions:
- Could some browsers be ignoring the query string when jQuery is loaded?
- Could some browsers be caching an older version of the inline javascript?
Any other ideas very welcome too.
UPDATE: In the course of checking that there wasn’t any unexpected caching going on using Firebug, I discovered a case where the old jQuery library would load. That doesn’t explain why we had trouble after deploying the site and before we updated the inline code, but if it solves the problem I’ll take it.
The answer to both your questions is no. Unless the whole page is being cached. A browser can’t cache part of a file, since it would have to download it to know which parts it had cached and by that time it’s downloaded them all anyways. It makes no sense 🙂
You could try sending some headers along with your page that force the browser not to use it’s cached copy.