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.
Hm, if this belongs in DOM:MozillaExtensions then so do a whole bunch of other XMLHttpRequest bugs.
Created attachment 516677 [details] [diff] [review]
This needs tests. I think I'll submit them to the official test suite first.
Created attachment 645527 [details] [diff] [review]
Backed out with the mass tree revert to get rid of the OS X M5 orange: