[NOTE: I'm re-posting this bug here. It was originally filed in the Chromium bug tracker http://code.google.com/p/chromium/issues/detail?id=37711 but it now appears to be Webkit related]
Across shift+refreshes, or even cache clearings, the color #1 and number #1 always
reload/change (as expected). but color #2 and number #2 persist from load to load.
until you navigate away and come back, which resets the special caching state.
i verified that "script2.js" and "css2.css" *are* removed from the cache when clearing
the cache. But yet they still remain in some sort of special cache state and persist.
What steps will reproduce the problem?
1. Go to the above testing URL (http://test.getify.com/chrome-cache-bug-2/)
2. Notice the first number and background color that appear immediately
3. After 3 seconds, notice the second number, and the new background color
4. Shift-Refresh the page, notice the first number and color change, but
after 3 seconds, the second number and color are the same as before the
5. Clear the browser cache, refresh the page. Notice same behavior as in
What is the expected result?
That scripts and css that are loaded dynamically after page load will go
normally into the cache, and therefore be removed from the cache when it is
cleared or when a shift-refresh occurs.
What happens instead?
scripts and css that are loaded at page load time behave correctly in the
cache. but, scripts and css that are loaded later (after the 3 seconds), go
into some special cache state, where they cannot be cleared by normal
means. They will persist even if the file changes on the server, or even if
the cache is cleared through any of several methods.
Please provide any additional information below. Attach a screenshot if
The test at the URL above is designed in this way:
1. First, it loads a single script file ("script1.js") and a single css
file ("css1.css"), both immediately during page load. The CSS file sets the
background color of the log textarea, and the JS file adds a message to the
log with a random number generated on the server.
2. It then sets a timeout of 3 seconds, at which time it loads another
script file ("script2.js") and another css file ("css2.css"). You will then
notice the second message in the log box, and the color change.
Now, at this point, there should be 4 files in the cache, two .js files and
two .css files. If I do a shift-refresh, or I clear the cache manually
(shift+ctrl+delete), I would expect all 4 files to be cleared out.
On refresh of the page after clearing/invalidating the cache, the first
script and css file DO reload with their new version. But after 3 seconds,
the browser loads the previous version of "script2.js" and "css2.css". This
happens persistently no matter how you try to clear the cache or shift-
refresh, it will keep those versions around.
The only way to truly clear these specially (incorrectly) cached items is
to physically navigate away from the URL and then come back, at which point
it will reload all 4 files. But then it goes right back to keeping
"script2.js" and "css2.css" in that special cache state until another
Duplicate of bug 30862?
It might very well be a duplicate of 30862 in terms of the actual underlying functionality issues, but I can say specifically that my bug has some different symptoms than 30862 is listing.
Mine is related to behavior of resources that load AFTER the regular page is finished loading (on-demand resources).30862 seems to be referring to resources that are loaded during page load.
In my test, you can actually see that resources loaded at page load time ("script1.js" and "css1.css") behave just fine with respect to the cache. It's only the "script2.js" and "css2.css" that behave incorrectly, and it appears it's because they are loaded later, on-demand, after a 3 second delay.
Also, as my bug demonstrates, this incorrect (too aggressive) caching actually causes the resources to be kept around in some sort of in-memory cache EVEN after the actual cache is manually cleared. 30862 seems to suggest the opposite, that clearing the cache fixes their problem.
I should also point out that this DOES in fact also affect both Firefox and Chrome. My original supposition was that it was only webkit related, but it appears to be more widespread than that.
That's all very good information, thanks! It makes the behavior look more like correct one though - it would be great if you could rephrase the report to make it clear what exactly is the bug here. Note that we usually try to mimic Firefox loading behavior when in doubt.
Please also specify how you are emptying the cache - we have two ways for doing that in Safari menu, and two more in Debug menu, which is unfortunate.
So, FWIW, Safari and Firefox differ from Chrome on one particular point:
In Chrome, even if you clear the cache, it keeps the dynamically loaded items around persistently, until you navigate away and come back. In Safari and FF it appears that it DOES re-download if you clear the cache.
However, *all 3* browsers have the problem that if you do a shift-refresh, it doesn't re-validate the items that are loaded later on-demand. So those get incorrectly loaded from cache.
Perhaps you may say this is intentional by design. But what is the point of allowing shift-refresh to reload a page's resources if in fact it only reloads *some* of a page's resources (those that are loaded immediately at page-load)?
Just left a comment over on Bug 30862:
I now feel that this bug *is* a duplicate of 30862, provided that 30862 is taken in the proper scope as I described in that comment.
*** This bug has been marked as a duplicate of bug 30862 ***