Implementing timeout support for XHR

Source/WebCore/platform/network/chromium/ResourceHandle.cpp

Index: Source/WebCore/platform/network/chromium/ResourceHandle.cpp
diff --git a/Source/WebCore/platform/network/chromium/ResourceHandle.cpp b/Source/WebCore/platform/network/chromium/ResourceHandle.cpp
index 54175ef216086b78905b6a56f4874d017cb3f4f1..f3340166db9f9894e3c3abca9a4b2ecbd7b29199 100644
--- a/Source/WebCore/platform/network/chromium/ResourceHandle.cpp
+++ b/Source/WebCore/platform/network/chromium/ResourceHandle.cpp
@@ -1,5 +1,6 @@
 /*
  * Copyright (C) 2009 Google Inc. All rights reserved.
+ * Copyright (C) 2013 Intel Corporation. All rights reserved.

[jamesr, 2013/04/17 17:51:05]

are we doing this?

[abarth-chromium, 2013/04/18 05:34:09]

In general, yes.

  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
@@ -58,6 +59,7 @@ ResourceHandleInternal::ResourceHandleInternal(NetworkingContext* context, const
     , m_owner(0)
     , m_client(client)
     , m_state(ConnectionStateNew)
+    , m_timer(this, &ResourceHandleInternal::timerFired)
 {
 }
 
@@ -73,6 +75,9 @@ void ResourceHandleInternal::start()
     WrappedResourceRequest wrappedRequest(m_request);
     wrappedRequest.setAllowStoredCredentials(allowStoredCredentials());
     m_loader->loadAsynchronously(wrappedRequest, this);
+
+    if (m_request.timeoutInterval() > 0)
+        m_timer.startOneShot(m_request.timeoutInterval());
 }
 
 void ResourceHandleInternal::cancel()
@@ -177,6 +182,21 @@ ResourceHandleInternal* ResourceHandleInternal::FromResourceHandle(ResourceHandl
     return handle->d.get();
 }
 
+void ResourceHandleInternal::timerFired(Timer<ResourceHandleInternal>*)
+{
+    // Use the same value as in NSURLError.h
+    static const int timeoutError = -1001;

[darin (slow to review), 2013/04/16 19:03:45]

Hmm, the network layer can also generate net::ERR_TIMED_OUT independently of
this code.  It looks like that would not be seen by XMLHttpRequest as a timeout.
 I assume that's intentional?

[Dominik Röttsches, 2013/04/17 08:26:52]

Yes, the way I read the spec, the ontimeout event should only fire in response
to an "author specified timeout", not due to implementation dependent network
timeouts. The latter would be handled by the more general onerror case.

+    static const char* const errorDomain = "WebKitNetworkError";
+
+    m_state = ConnectionStateCanceled;
+    m_loader->cancel();
+    if (m_client) {
+        ResourceError error(errorDomain, timeoutError, m_request.url().string(), String());
+        error.setIsTimeout(true);
+        m_client->didFail(m_owner, error);
+    }
+}
+
 // ResourceHandle -------------------------------------------------------------
 
 ResourceHandle::ResourceHandle(NetworkingContext* context, const ResourceRequest& request, ResourceHandleClient* client, bool defersLoading, bool shouldContentSniff)