WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
30506
Resources that the server sent as 304 not modified are not shown in the inspectors resource pane
https://bugs.webkit.org/show_bug.cgi?id=30506
Summary
Resources that the server sent as 304 not modified are not shown in the inspe...
Martin Häcker
Reported
2009-10-19 03:10:28 PDT
Which is unfortunate, as I often want to inspec them - even if Safari pulled them from it's internal cache. Interestingly this behaviour persists even if you deactivate all caches from the "developer" menu.
Attachments
proposed fix
(4.27 KB, patch)
2009-10-22 16:12 PDT
,
Alexey Proskuryakov
timothy
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2009-10-19 10:28:46 PDT
What nightly build revision are you seeing this with? Is this a regression? I understand you're saying this happens everywhere, but nonetheless, do you have a specific example of a page we could refer to when investigating this bug?
Martin Häcker
Comment 2
2009-10-19 15:52:39 PDT
I've seen it with builds for at least the last several months, the latest with build 49764. I have also seen it with Safari 4.0.3 so if it is a regression it probably was in 4 already. For reference, it mostly annoys me when I am debugging our web application that we develop in-house. Here's the homepage
http://www.agile42.com/cms/pages/agilo/
and the accompanying trac instance:
https://dev.agile42.com/
It is open source, so you could get it to test with, I do suspect that this error is so widespread that you can test it with any page that sends 304s for objects. I would advise to try it with javascript files, because it becomes really apparant if you hit a breakpoint in a file that is just displayed as empty or step into a function just to be shown an empty screen. Something I just noticed: sometimes reloading the page and trying again helps (but its more a 1 out of 10 tries works) scenario and it almost always means that other files will then be hidden. Still this points to the theory that this could also be a timing issue (which I hope it's not). Regards, Martin
Alexey Proskuryakov
Comment 3
2009-10-20 12:38:57 PDT
<
rdar://problem/7319845
>
Alexey Proskuryakov
Comment 4
2009-10-20 17:35:59 PDT
Looks like the main culprit here is preloading logic (I'm not even sure if this only happens for 304 Not Modified responses). Here is what happens: 1. As a document is loaded, preload scanner is invoked, requesting subresources while HTML parser is blocked waiting for the first script to download. 2. These preloads result in InspectorController::addResource being called, but cache->requestResource() returns null, thus the resource is never added to document resource set in DocLoader. 3. Once a response for preload is received, Inspector asks DocLoader about it (in InspectorResource::updateScriptObject), but DocLoader says that there is no such resource. It's no good that DocLoader doesn't know about resources that were revalidated by preloader.
Alexey Proskuryakov
Comment 5
2009-10-21 16:59:27 PDT
Seems related to FrameLoader::loadedResourceFromMemoryCache() not being called in this case.
Alexey Proskuryakov
Comment 6
2009-10-22 16:12:43 PDT
Created
attachment 41692
[details]
proposed fix This isn't exactly the kind of fix I was trying to make - as mentioned above, it seems that client callbacks are messed up when preloading meets revalidation, which this doesn't correct. But it is a simple and hopefully safe fix.
Alexey Proskuryakov
Comment 7
2009-10-22 17:02:07 PDT
Committed <
http://trac.webkit.org/changeset/49960
>.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug