Reorder some functions in SubresourceLoader to permit main resources

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Nate Chapin]

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().

For willSendRequest(), there are two calls, 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.

For didReceiveData(), We need to populate ResourceLoader::m_resourceData before notifying CachedResource of new data.  Currently the call order is :
(Start call to ResourceLoader::didReceiveData)
addData()
frameLoader()->notifier()->didReceiveData()
(End call to ResourceLoader::didReceiveData)
sendDataToResource()

Main resources want the order to be:
addData()
sendDataToResource()
frameLoader()->notifier()->didReceiveData()

...which is not permitted via calling ResourceLoader::didReceiveData().  Therefore, call all three directly, rather than delegating to the parent class.

[Nate Chapin]

Created attachment 169496 [details]
patch

[Adam Barth]

Comment on attachment 169496 [details]
patch

This looks much better.  I'm sort of amazed that the old code worked.

[WebKit Review Bot]

Comment on attachment 169496 [details]
patch

Clearing flags on attachment: 169496

Committed r131919: <http://trac.webkit.org/changeset/131919>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.