Last Comment Bug 600111 - XMLHttpRequest.setRequestHeader() throws NS_ERROR_FAILURE inappropriately
: XMLHttpRequest.setRequestHeader() throws NS_ERROR_FAILURE inappropriately
Status: RESOLVED FIXED
: dev-doc-needed
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla17
Assigned To: :Ms2ger
:
Mentors:
http://dev.w3.org/2006/webapi/XMLHttp...
Depends on:
Blocks: 704787 726433
  Show dependency treegraph
 
Reported: 2010-09-27 19:19 PDT by Zack Weinberg (:zwol)
Modified: 2013-04-04 13:53 PDT (History)
3 users (show)
ryanvm: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
WIP (5.02 KB, patch)
2011-03-03 12:48 PST, :Ms2ger
no flags Details | Diff | Review
Patch v1 (8.48 KB, patch)
2012-07-24 15:07 PDT, :Ms2ger
jonas: review+
Details | Diff | Review

Description Zack Weinberg (:zwol) 2010-09-27 19:19:49 PDT
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.
Comment 1 Zack Weinberg (:zwol) 2010-09-27 19:33:53 PDT
Hm, if this belongs in DOM:MozillaExtensions then so do a whole bunch of other XMLHttpRequest bugs.
Comment 2 :Ms2ger 2011-03-03 12:48:54 PST
Created attachment 516677 [details] [diff] [review]
WIP

This needs tests. I think I'll submit them to the official test suite first.
Comment 3 :Ms2ger 2012-07-24 15:07:40 PDT
Created attachment 645527 [details] [diff] [review]
Patch v1
Comment 5 Ed Morley [:emorley] 2012-08-04 11:28:29 PDT
Backed out with the mass tree revert to get rid of the OS X M5 orange:
https://hg.mozilla.org/mozilla-central/rev/c801b99d726f
Comment 6 Ryan VanderMeulen [:RyanVM] 2012-08-04 14:50:40 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/e5b07db1a574
Comment 7 Ryan VanderMeulen [:RyanVM] 2012-08-04 18:40:34 PDT
https://hg.mozilla.org/mozilla-central/rev/e5b07db1a574

Note You need to log in before you can comment on or make changes to this bug.