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

public/platform/WebURLError.h

 /*
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 34 matching lines @@
     // resource errors. WebKit does not care about the value of this
     // string as it will just be passed via callbacks to the consumer.
     WebString domain;
 
     // A numeric error code detailing the reason for this error. A value
     // of 0 means no error. WebKit does not interpret the meaning of other
     // values and normally just forwards this error information back to the
     // 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;
 
     // The url that failed to load.
     WebURL unreachableURL;
 
     // 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&);
     BLINK_PLATFORM_EXPORT WebURLError& operator=(const WebCore::ResourceError&);
     BLINK_PLATFORM_EXPORT operator WebCore::ResourceError() const;
 #endif
 };
 
 } // namespace blink
 
 #endif