Added field to error structures to signal existence of a stale copy in

public/platform/WebURLError.h

Index: public/platform/WebURLError.h
diff --git a/public/platform/WebURLError.h b/public/platform/WebURLError.h
index 14553d0288b209b72154aa185441e6ea00aab25b..cdd0b6abb0e87eb6333e404e32de15f65bb3dc84 100644
--- a/public/platform/WebURLError.h
+++ b/public/platform/WebURLError.h
@@ -52,6 +52,10 @@ struct WebURLError {
     // embedder (see for example WebFrameClient).
     int reason;
 
+    // A flag showing whether or not "unreachableURL" has a copy in the
+    // cache that was too stale to return for this request.
+    bool staleCopyInCache;

[abarth-chromium, 2014/01/27 18:05:31]

How likely do you think it is that we'll want to attach additional information
to WebURLError in the future?  Meaning, if we build the complicated general
thing, how likely is it that we'll make use of its generality in the future?

[Randy Smith (Not in Mondays), 2014/01/27 19:13:56]

Good question.  In the area that I'm currently working in (improving chrome
experience when you're offline) I can't think of anything we're likely to want. 
I could imagine wanting more nuance and detail about cache state (why is it
stale?  what are the headers?  Is it partial storage (range request) or complete
storage?) but really, given the racing with eviction we're doing, the only real
information here is a hint to the renderer that it might be worth trying a
LOAD_ONLY_FROM_CACHE request, and I don't think the extra information would
really help the renderer make that decision (or if it did, we can subtly tweak
the meaning of the boolean on the other side).  So I don't believe this work is
likely to produce more information to put in WebURLError.  I'm certainly happy
to sign up for the complicated version in the future if I end up wanting to put
more stuff in.

Expanding beyond the offline situation, the answer I come up is "maybe".  The
general question is, might there be expanded information about the error that
we'd want to communicate with the renderer, and I could imagine there being such
(network status (local bandwidth, captive portal, radio vs. wifi, flakiness
measurements, etc.)  But the further question is, will that information be
synchronous with the request failure, or is it better sent through other
messages that don't involve blink.  My current guess (I also chatted with Matt
Menke, cc'd, who's the error page expert) is that the answer is "no", but the
future isn't certain.

So I think I'll summarize that to "not very likely", with caveats :-}.

Let me ask about a different possible implementation pathway, which could make
this question moot.  Is it possible for the blink embedder (Chromium, in this
case) to export a type that blink makes use of?  If so, we could make
WebURLError::reason be a copyable class that Chromium defines.  This strikes me
as truer to the spirit of what that value is than making it an "int", it doesn't
require a lot of complexity in blink, and not too much in Chromium either.  But
I'm not sure it's legal to have a blink->embedder dependency like that.  

+
     // A flag showing whether this error should be treated as a cancellation,
     // e.g. we do not show console errors for cancellations.
     bool isCancellation;
@@ -62,7 +66,7 @@ struct WebURLError {
     // A description for the error.
     WebString localizedDescription;
 
-    WebURLError() : reason(0), isCancellation(false) { }
+    WebURLError() : reason(0), staleCopyInCache(false), isCancellation(false) { }
 
 #if INSIDE_BLINK
     BLINK_PLATFORM_EXPORT WebURLError(const WebCore::ResourceError&);