|Summary:||Incorrect cache behavior with dynamic scripts after page-refresh|
|Product:||WebKit||Reporter:||Kyle Simpson <getify>|
|Severity:||Normal||CC:||ap, john.david.dalton, marcus, rvargas, tonyg|
|Version:||528+ (Nightly build)|
Description Kyle Simpson 2009-12-11 04:31:22 PST
Comment 1 Alexey Proskuryakov 2009-12-14 10:33:39 PST
See also: bug 30862. I'm having a lot of difficulty trying to understand this bug or the attached test cases. Clearly, there are some amusing differences in behavior depending on how exactly script elements are inserted, but is there any practical problem that needs to be fixed?
Comment 2 Kyle Simpson 2009-12-14 17:01:24 PST
Comment 3 John-David Dalton 2009-12-14 23:30:22 PST
Created attachment 44849 [details] revised test case.
Comment 4 John-David Dalton 2009-12-14 23:31:42 PST
Comment 6 Kyle Simpson 2010-03-09 15:31:07 PST
Actually, I believe this to be the opposite behavior to 30862. My bug is demonstrating a scenario when the cache SHOULD be used for two loads of the exact same URL resource in the same page-view (one before page load, one on-demand, later), and it is failing to do so (meaning it re-requests the resource a second time incorrectly, even though the first load did put the resource into the cache). 30862 seems to be about resources staying cached when they shouldn't be, which is the opposite to this bug.
Comment 7 rvargas 2011-02-03 18:32:20 PST
@Alexey: Note that http://code.google.com/p/chromium/issues/detail?id=23162#c6 has a description of where exactly this bug resides (although with an old version of the code).
Comment 8 Tony Gentilcore 2012-05-09 17:07:24 PDT
@getify: I'm working on related bug 84614 and suspect it's a duplicate. However, your test case doesn't work any more for me. Would you mind double checking it? I'm very interested to get to the bottom of this.
Comment 9 Kyle Simpson 2012-05-09 18:41:09 PDT
(In reply to comment #8) Tony- The previous test cases no longer work because Webkit (and thus Chrome) have changed since this bug was initial submitted. Those test cases were based on then-behavior that script elements with fake/unrecognized mime-types would be requested by the browser into the cache, but not executed. Webkit no longer fetches such scripts, so the test cases all fail to execute fully. --------------------- I have created a new test case which I believe illustrates still the same problem, which is that the cache is not used during a page reload even though caching headers ostensibly suggests the item should be fetched from cache. Steps to reproduce: 1. with a clean cache, go to: http://test.getify.com/webkit-bug-32423/ 2. wait for the "initial" 2 scripts to load/finish. then, click the button to re-request them, and wait for the "on-demand" script requests (same URLs!) to finish (should be nearly immediate, because they come from cache, as desired). 3. normal-click the refresh button. note that the scripts again load nearly immediately, from cache, as desired! 4. finally, normal-click the refresh the button a second time (third total page load), and notice that the scripts no longer come from cache, but get re-requested, and thus take several seconds each. Further subsequent loads continue to re-request the scripts from the server (not the cache) every time.
Comment 10 Tony Gentilcore 2012-05-10 10:15:53 PDT
(In reply to comment #9) > (In reply to comment #8) > Tony- > > The previous test cases no longer work because Webkit (and thus Chrome) have changed since this bug was initial submitted. Those test cases were based on then-behavior that script elements with fake/unrecognized mime-types would be requested by the browser into the cache, but not executed. Webkit no longer fetches such scripts, so the test cases all fail to execute fully. > > --------------------- > > I have created a new test case which I believe illustrates still the same problem, which is that the cache is not used during a page reload even though caching headers ostensibly suggests the item should be fetched from cache. > > Steps to reproduce: > > 1. with a clean cache, go to: > > http://test.getify.com/webkit-bug-32423/ > > 2. wait for the "initial" 2 scripts to load/finish. then, click the button to re-request them, and wait for the "on-demand" script requests (same URLs!) to finish (should be nearly immediate, because they come from cache, as desired). > > 3. normal-click the refresh button. note that the scripts again load nearly immediately, from cache, as desired! > > 4. finally, normal-click the refresh the button a second time (third total page load), and notice that the scripts no longer come from cache, but get re-requested, and thus take several seconds each. Further subsequent loads continue to re-request the scripts from the server (not the cache) every time. This still repros at ToT so not a dupe. However, #3 seems like the bug, not #4. When the user presses the browser's refresh button, we are supposed to revalidate all the subresources with the server. The desired heuristic is to revalidate anything which is started prior to the load event. Resources lazily loaded after the page loads shouldn't continue to be revalidated.
Comment 11 Kyle Simpson 2012-05-10 12:13:56 PDT
(In reply to comment #10) > This still repros at ToT so not a dupe. However, #3 seems like the bug, not #4. I designed the test so that the first request for script1 and script2 comes during/before load. When you subsequently request them a second time, by clicking the button, you're pulling from the cache that's already primed from during load, not dynamically loading them after page load. This is why, I think, #3 is desired and not a bug, because when you refresh the page, and it again goes to load the scripts during page load, it's reloading resources that were previously loaded during a page load. Or am I misunderstanding? If I'm correct in that assertion, that's why #4 is the bug, because the assertion should continue to hold true on subsequent page loads where they are always first requested during a page load. Or no? > When the user presses the browser's refresh button, we are supposed to revalidate all the subresources with the server. The desired heuristic is to revalidate anything which is started prior to the load event. Resources lazily loaded after the page loads shouldn't continue to be revalidated. I understand that browsers desire that heuristic, but as Bug #30862's discussion thread (and other related ones) shows, I think developers have a more complex heuristic they desire: when they **shift+reload** the page, they want any hard resource that might have changed (like script files they are developing) to be revalidated, regardless of when it got loaded onto the page (race conditions!), whereas some soft resources (like perhaps XHR requests), I can see why those maybe shouldn't be re-validated (just like you don't necessarily want to re-submit form posts, etc). But anyway, that's a rabbit trail best left for discussion in that other bug.