57411 - "error loading url" message should print macro name, not just hex value

Status: RESOLVED FIXED

(Core :: Networking, defect, P3)

Description

[Jesse Ruderman]

This "error loading url" message prints a hex nsresult, which not everyone 
knows how to decode.  Apparently the error message was originally added to 
figure out what was causing a specific problem with tinderbox, but since the 
error message is showing up often I think it would be nice if the error message 
included the macro name for the error.

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/src/nsBrowserInstance.cpp#1
752:

         fprintf(stdout, "Error loading URL %s: %0x \n", 
                (const char*)url, aStatus);

Changelog:

[e-mail]
We now report status error along with the "Error loading URL" This will help us 
catch the reason of unsuccessful URL loads. See bug 48900 for details. r=warren


Here's an example of an error message that includes the number and #define name 
of the error message:

http://lxr.mozilla.org/seamonkey/source/js/src/jsexn.c#812
 
    JS_ReportErrorNumber(cx, js_GetErrorMessage, NULL,
        JSMSG_UNCAUGHT_EXCEPTION, bytes);

Comment 1

[Warren Harris]

These printfs don't appear in release bits, and bug 47207 will remove them 
altogether. WONTFIX.

Comment 2

[Jesse Ruderman]

These error messages will still appear in nightlies when -console is used, 
though, right?

Changing the message to include the #define name of the error would make it 
easier for testers and developers to figure out what the problem is and/or 
which part of the C++ code is returning the error.  It would also help with 
identifying which errors are bug 55720, which are javascript errors from 
javascript: urls, and which are separate bugs (most people can't recognize 8-
digit hex numbers as readily as they can recognize phrases).

For an example of why the current behavior is less than ideal, load
javascript:4
and then type
javascript:x=window.open("about:blank");x.document.write("foo");x.document.write
("bar");
into the url bar.  You get four error messages after the second step:


Error loading URL about:blank: 804b0002
JavaScript error:
 line 0:

JavaScript error:
 line 0: uncaught exception: [Exception... "Access to property denied"  code: "1
010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)"  location: "<unkno
wn>"]

Error loading URL javascript:x=window.open("about:blank");x.document.write("foo"
);x.document.write("bar");: 805303f5


I can't tell from this mess which errors are triggering other errors.  Because 
the last hex value has a value close to the second-to-last (which also has a 
name), I can use lxr to find out that the last "error loading page" is 
NS_ERROR_DOM_RETVAL_UNDEFINED, or "Return value is undefined".  Ok, so that 
makes some sense, but it could have been easier to figure out what the error 
was.  I can get the same error by typing javascript:undefined or 
javascript:asdf into the url bar, or by triggering any other security error.

But what the heck is the first error?  It turns out that I get that whenever I 
load about.blank and write to it immediately, but I still have no idea what 
code it's going through or even whether it's correct for there to be an error.

(See bug 57414 for more on the example I gave.)

Comment 3

[Bradley Baetz (:bbaetz)]

It would be nice to print the name, especially since we now print the error code
in decimal instead of hex for some reason.

Comment 4

[benc]

REOPENED:
One of those Mozilla 1.0 type issues that should be resolved by some design
decisions.

We need better error logging and descriptions, because triaging vague problems
and marking dupes eats up a lot of contributor time, time I would rather have
them spend learning things about how to actually solve or analyze networking
problems rather than ask reporters the same questions again and again.

Comment 5

[Gagan]

->bbaetz

Comment 6

[Bradley Baetz (:bbaetz)]

I'm attaching a patch which tecnically does the Right Thing (and moves the error
code back to hex).

However, we can only print the name of error codes which the xpc code actually
knows about, ie anything in js/src/xpconnect/src/xpc.msg.

Otherwise I just print "<unknown>". If that code ever ends up printing any type
of error, then this patch will print the macro name as well. I'd print the plain
english name as well, except that nothing in xpcexception.cpp seems to get the
format from NameAndFormatForNSResult. For debugging, the macro name is probably
better, anyway.

Comment 7

[Bradley Baetz (:bbaetz)]

Attachment: patch

Comment 8

[Bradley Baetz (:bbaetz)]

*** Bug 76296 has been marked as a duplicate of this bug. ***

Comment 9

[Bradley Baetz (:bbaetz)]

jag says, r=jag, but he wants be to remove the <unknown> bit if we don't know
anything about the error. And he prefers my patch to his (from bug 76296).

Ben apparently had some issues with the other patch, so I'm ccing him for
comment before I update the patch.

Comment 10

[Ben Goodger (use ben at mozilla dot org for email)]

sure

sr=[e-mail]

Comment 11

[Bradley Baetz (:bbaetz)]

Fix checked in.