Reorder some functions in SubresourceLoader to permit main resources
authorjaphet@chromium.org <japhet@chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 19 Oct 2012 17:40:55 +0000 (17:40 +0000)
committerjaphet@chromium.org <japhet@chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Fri, 19 Oct 2012 17:40:55 +0000 (17:40 +0000)
commitdb2489376268bfb15c8300c40992bf35d7cd3010
tree3d0f002f5e11f92e9c5326eb8cd1fbc21396abe5
parentd3253512d95964732b446dcb1eb0ef7edca44be0
Reorder some functions in SubresourceLoader to permit main resources
https://bugs.webkit.org/show_bug.cgi?id=99769

Reviewed by Adam Barth.

Most resource types that go through the memory cache (and therefore
through SubresourceLoader) are not sensitive to the exact ordering of
the callbacks they receive, particularly as it relates to ResourceLoadNotifier
calls.  Main resources are not so lenient.  For main resources to be cacheable
and maintain the current behavior as precisely as possible, we will need to
rearrange SubresourceLoader's willSendRequest() and didReceiveData().

No new tests, refactor only.

* loader/SubresourceLoader.cpp:
(WebCore::SubresourceLoader::willSendRequest): There are a series of checks that can result
    in the request being canceled, plus calls to CachedResource::willSendRequest() and
    ResourceLoader::willSendRequest().  MainResourceLoader (which will be a
    CachedResourceClient) has work it expects to do before ResourceLoader::willSendRequest()
    is called, but the calls are out of order for that, so swap those.
(WebCore::SubresourceLoader::didReceiveData): We need to populate ResourceLoader::m_resourceData
    before notifying CachedResource of new data, but we also want to do CachedResourceClients calls
    before calling ResourceLoadNotifier. This means we can't delegate to ResourceLoader.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@131919 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore/ChangeLog
Source/WebCore/loader/SubresourceLoader.cpp