Buggy caching of .js/.css resources

• Component: New Bugs
• Status: RESOLVED DUPLICATE

[Kyle Simpson]

[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]


Bug Statement:
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 
refresh.
5. Clear the browser cache, refresh the page. Notice same behavior as in 
#4.

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
possible.

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 
navigation away.

[Alexey Proskuryakov]

Duplicate of bug 30862?

[Kyle Simpson]

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.

[Alexey Proskuryakov]

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.

[Kyle Simpson]

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)?

[Kyle Simpson]

Just left a comment over on Bug 30862:

https://bugs.webkit.org/show_bug.cgi?id=30862#c12

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 ***