ResourceError has an integer 'reason' field to specify the type of error. DocumentThreadableLoader always sets this to 0. BlobResourceHandle sets this to private error codes. Create a system of error codes to describe Resource access errors.
I don't see the word "reason" anywhere in ResourceError.h or ResourceErrorBase.h.
Sorry, 'reason' is the name of the field in the WebKit::WebURLError wrapper struct. The description should say: " ResourceErrorBase has an integer 'm_errorCode' field to specify the type of error. DocumentThreadableLoader always sets this to 0. BlobResourceHandle sets this to private error codes. Create a system of error codes to describe Resource access errors."
Both are correct in this regard. There is an m_domain field, and every domain owner uses whatever codes it likes. Apparently, we never needed to differentiate between errors in internal WebKit domain, so always using 0 is fine. On the other hand, ResourceErrorMac copies error code and domain from NSError - and the domain could be CFNetwork, SSL, POSIX, or something else along those lines.
Renaming this issue to reflect the fact that this should only affect DocumentThreadableLoader. ThreadableLoader should define integer values for types of access errors and set those on the ResourceErrors it returns, so we can return better error codes at higher levels of WebKit and Chromium.
Note that DocumentThreadableLoader creates errors in internal domain. Internal means that these should never go to the client, or at least that we don't want the client to care about details. Errors that are meaningful to the client are defined in each WebKit - see e.g. WebKit/mac/Misc/WebKitErrors.h. If DocumentThreadableLoader creates errors that can be meaningful to clients, it should call WebKit to create those via FrameLoaderClient.