The W3C spec for XMLHttpRequest (see URL) says that setRequestHeader() is supposed to distinguish two kinds of errors, and doesn't license it to produce any other kind of exception: # Throws an INVALID_STATE_ERR exception if the state is not OPENED or # if the send() flag is true. # # Throws a SYNTAX_ERR exception if header is not a valid HTTP header # field name or if value is not a valid HTTP header field value. Our implementation uses NS_ERROR_FAILURE for conditions falling under both these heads, and also for some internal, should-never-happen conditions (IsPending() or IsCapabilityEnabled() fails - death to xpcom). And it can throw NS_ERROR_IN_PROGRESS under conditions that are unclear to me but probably shouldn't be visible to JS. Also, HttpBaseChannel::SetRequestHeader can throw NS_ERROR_INVALID_ARG for conditions that I think are supposed to be mapped to SYNTAX_ERR in this case, and NS_ERROR_NOT_AVAILABLE for another probably should-never-happen condition (nsHttp::ResolveAtom fails). And several things can produce NS_ERROR_OUT_OF_MEMORY, but we probably don't need to worry about that.
7 years ago
Hm, if this belongs in DOM:MozillaExtensions then so do a whole bunch of other XMLHttpRequest bugs.
Created attachment 516677 [details] [diff] [review] WIP This needs tests. I think I'll submit them to the official test suite first.
Created attachment 645527 [details] [diff] [review] Patch v1
Backed out with the mass tree revert to get rid of the OS X M5 orange: https://hg.mozilla.org/mozilla-central/rev/c801b99d726f