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.
Created attachment 169496 [details] patch
Comment on attachment 169496 [details] patch This looks much better. I'm sort of amazed that the old code worked.
Comment on attachment 169496 [details] patch Clearing flags on attachment: 169496 Committed r131919: <http://trac.webkit.org/changeset/131919>
All reviewed patches have been landed. Closing bug.