Wouldn't XMLHttpRequest.status member give you what you want, without going to the channel member? (This bug might still be valid, regardless.)
Ah, I should have clarified what kind of errors I'm talking about. AFAIK, the XMLHttpRequest.status attribute you mention only contains HTTP status codes: 200, 404, etc. I'm interested in lower-level networking errors such as "host not found", "host unreachable", and "connection refused". The only place I've been able to find this is the "status" attribute contained in XMLHttpRequest.channel.
XMLHttpRequest.channel is intentionally not scriptable by webpages since it's our internal networking objects that we have no interest in exposing to web pages. If a mechanism for obtaining more information about the error than what XMLHttpRequest provides, then we need to do that on a different level, like maybe as a new property of the error object that's passed to the error handler, or something like that. Feel free to file a new bug on that if you feel it's worth doing. This bug is WONTFIX.
Sounds reasonable. From an application person's perspective, something more intuitive than digging into the channel member would be preferable anyway. I do think that the extra error information would help people write better applications, so I'll write a new, more appropriate bug. I don't understand the security ramifications, but I do have one comment: access to the channel member is allowed for synchronous requests, but disallowed for asynchronous ones. If there's a security concern, it seems like access should be disallowed for both request types. Let me know if this warrants a separate bug.
There's no difference from a security point of view between async and sync connections, the difference is only in how you write the code to enable access to XPConnect in the two cases. Maybe you don't fully know what you're doing in this testcase. You enable "UniversalXPConnect" privileges in this testcase (the fact that your code works differently in the async vs sync case is simply a matter of where you request "UniversalXPConnect" privileges, try putting that code in the onerror handler and see what happens), and that will give you access to *anything* on the clients computer, if he grants your script those privileges. You can read any file, you can write any file, run any programs. There are no limits. The channel property of an XMLHttpRequest object might not on its own be a security sensitive property, but it's Mozilla only thing, and it exposes Mozilla internals that were never meant to be used by script on a webpage. And we can't globally give access to our nsIChannel implementations, since with those you can open connections to servers etc, and we don't want to deal with any of the risks involved in opening that up. So I say again, if you feel that the error messages you're trying to expose here are general enough and you think they would be useful in more than a handful of cases, and while being aware that such a feature would be Mozilla only, and not available in any other browsers for some time at least, then by all means file a new bug requesting such a feature on XMLHttpRequest. But I wouldn't expect we'll ever expose our channel implementations to webpage scripts.
1.) I plead not guilty to ever actually *wanting* to use nsIChannel or it's status attribute. It was the only place I could find the damn network errors. 2.) No, I did not understand the implications of granting UniversalXPConnect privileges. I appreciate your comments here and in in bug 238731. Sorry about the invalid testcases. 3.) I did file bug 238559 to request that XMLHttpRequest provide network error status.