I meant: "the mechanism exists but no registration has taken place yet"
I think the work would involve adding entried into necko.properties (under netwerk/resources/locale/en-US) for all of the error codes described in nsNetError.h. However, I'm also not sure that this approach is the right approach. I think we are working off some half-baked concept code. The string bundle stuff is used heavily by Mozilla for all localized strings; however, I don't think anyone has seriously used it for what you are trying to do.
Most code just checks for specific numeric values (extracted from nsError.h, nsNetError.h, and other definitions scattered throughout the code base) and goes from there.
Check LXR to see where nsIErrorService is used since it is the backend to this error formating magic. In fact, I think you will find that it is rarely used (http://lxr.mozilla.org/mozilla/search?string=nsIErrorService). As I said before Necko uses it to map nsresult values to strings for the browser's status bar.
If we go down the road to creating strings for all these error codes, then we also have to agree to the extra bloat for those string definitions. I can't say for sure that that is something we'd want since it's only valuable for debugging.
-Darin
Chuck Musser wrote:
Darin, thanks for the response.
XMLHttpRequest error handling had me flummoxed, but not in a way that seriously threatened my sanity or finances. Well, maybe my sanity, but that was marginal anyway. Now that I know about those opaque status codes, I can devise a workable solution. Note that the onerror handling technique I included has only worked since Saturday, when a fix for bug #218236 was checked in.
Before I discovered how to get the status codes, I filed bug #235849, in which I asked for documentation on handling XMLHttpRequest network errors and volunteered to write it. Bug 218236 was a blocker; when that was resolved, I resumed my tinkering and found out how to use the nsIRequest "status" code.
Even with 218236 out of the way, we still have this problem, with nsIStringBundleService. When you say "not supported", do you mean that no mechanism exists for registering the networking error codes with nsIErrorService or that the mechanism exists but no registration has taken place yet? Do you have an idea of the scope of that work? I'd like to help. Depending on what's involved, I might even be of some use!
Thanks,
Chuck
p.s. I came across the nsISocketTransport and nsITransport interfaces while I was reading, by the way, but I never could figure out how to QueryInterface XMLHttpRequest's "channel" field to one of those interfaces. Even if I could, I was never sure if the status field would be valid. There's not much explanatory documentation!
Darin Fisher wrote:
You're kind'a sort'a on the right track. If things actually worked like they are documented to work, then yes.... you'd have the right solution. The problem, however, is that none of the networking error codes are registered with the nsIErrorService, and hence none of the errors have mappings to localized strings. It might be a good thing for us to do that at some point, but at present it just isn't supported. The only mappings that are supported via this interface are for the status codes defined on nsITransport and nsISocketTransport. However, those status codes have nothing in common with the XPCOM error codes returned when a XMLHttpRequest fails. Instead, they pertain to the status field of nsIProgressEventSink.
Yeah, yeah, yeah... it's all very messed up :-(
-Darin
Chuck Musser wrote:
I'm trying to print out a messages when networking errors happen in my XUL app. The specific case I'm working with is errors from XMLHttpRequest.
After some reading and experimentation, I came up with something that shows promise, but doesn't quite work. A bit of background: the function shown below is the "onerror" handler for the XMLHttpRequest object. Its sole argument is the "target" of the error (the XMLHttpRequest), from which I obtain an nsIRequest interface that contains a status field.
Here's the code:
req.onerror =
function (e) { var req = e.target.channel.QueryInterface(Components.interfaces.nsIRequest);
var sbServ = Components.classes["@mozilla.org/intl/stringbundle;1"].
getService(Components.interfaces.nsIStringBundleService);
var errorText =
sbServ.formatStatusMessage(req.status, // sample value: 2152398861
// means "connection refused"
"This is a message"
);
alert(errorText);
}
req.status contain values that seem valid: they vary based on the error condition encountered--"connection refused", "no route to host", etc. But the formatStatusMessage() method always throws this exception:
Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundleService.formatStatusMessage]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///Users/chuck/errtest.html :: anonymous :: line 34" data: no]
Source File: file:///Users/chuck/errtest.html
Line: 34
Am I:
1.) Handing it a "status" (first argument) that is invalid or needs to be massaged in some way? I also tried guessing a few values (positive and negative) and hardcoding them into the first argument, but I got the same result.
2.) Handing it an inappropriate statusArg (second argument)? I'm assuming it can just be text. I tried a blank string, which got me the same exception, and I tried the "null" value, which crashed the browser. I'll file that as a bug.
3.) Barking up the wrong tree entirely? I thought the nsIStringBundleService looked like a good fit, but maybe I've misunderstood its purpose or usage.
Thanks,
Chuck _______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
_______________________________________________ Mozilla-xpcom mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-xpcom
