Let ThreadableLoaderClientWrapper's client handle failures better.

Source/core/loader/ThreadableLoaderClientWrapper.h

Index: Source/core/loader/ThreadableLoaderClientWrapper.h
diff --git a/Source/core/loader/ThreadableLoaderClientWrapper.h b/Source/core/loader/ThreadableLoaderClientWrapper.h
index 56da8f8e063551615eb016d61474220d079395d5..8755eadef73cb54bb159524415c0a44a17567f28 100644
--- a/Source/core/loader/ThreadableLoaderClientWrapper.h
+++ b/Source/core/loader/ThreadableLoaderClientWrapper.h
@@ -97,16 +97,19 @@ public:
 
     void didFailAccessControlCheck(const ResourceError& error)
     {
-        m_done = true;
+        // Let the client first handle the failure by possibly issuing
+        // a didFail() with a cancellation error before marking this
+        // wrapper as 'done'.
         if (m_client)
             m_client->didFailAccessControlCheck(error);
+        m_done = true;

[abarth-chromium, 2014/06/22 14:48:26]

Is the client allowed to destroy |this| during the didFailAccessControlCheck
callback?

[sof, 2014/06/22 15:49:14]

I don't think it will be able to accomplish that per the "case 2" lifetime
comment next to the WorkerThreadableLoader::MainThreadBridge declaration, i.e.,
the ref count is upped across the call to the wrapper.

No implementation of this method (and didFailRedirectCheck()) will currently try
to delete the loader (and indirectly de-ref this wrapper object), but they
should be allowed to do so in general.

Does that make sense?

     }
 
     void didFailRedirectCheck()
     {
-        m_done = true;
         if (m_client)
             m_client->didFailRedirectCheck();
+        m_done = true;
     }
 
     void didReceiveAuthenticationCancellation(unsigned long identifier, const ResourceResponse& response)