[Webkit-unassigned] [Bug 37215] Web Inspector: be more explicit about resource loading errors

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=37215





--- Comment #9 from Patrick Mueller <pmuellr at yahoo.com>  2010-04-07 21:22:15 PST ---
re: comment 2: "Do you have a use case in mind that where a resource loading
failure is "normal" and would cause lots of messages to be logged?"

I didn't mean to imply I thought resource loading was "normal", more that I've
heard other complaints about excess messages being printed to the console; for
example XHR completion messages.  Used to be, that was the only way to provide
information to the user; today there are a variety of other panels.  I tend to
think of the console now as just a REPL, but it's serving dual purpose as both
a logging device and a REPL.

re: comment 4: "There is already the HTTP status code for showing failure in
the Headers tab."

Which isn't appropriate if the resource never got an HTTP response.  Examples:
XHR requests that result in xhr.status == 0 (when you can't connect to the
server, and probably other cases); resource loads in an app-cache environment
where the resource isn't listed in the manifest (no request is ever made of the
resource, but it shows up in the resource list - as it should).

In both of these cases, there is additional information that we can provide, in
theory, about why the resource wasn't loaded.  Let's say we can actually
determine the reason why an xhr.status == 0 occurred, say ECONNREFUSED when
trying to access the resource - where would we provide that information?  The
app-cache example would require a sentence or two explaining the problem ("a
resource was requested which should have been listed in the manifest, but
wasn't, so the resource not loaded"). 

I think this sort of information could go in the headers tab, although I
suppose if there's no content, it could go in the content tab as well.  Or
both.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.