Closed
Bug 765704
Opened 13 years ago
Closed 13 years ago
Don't throw when setting XHR.responseType to an invalid value
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla16
People
(Reporter: Ms2ger, Assigned: Ms2ger)
References
Details
(Keywords: regression)
Attachments
(1 file)
9.82 KB,
patch
|
bzbarsky
:
review+
lsblakk
:
approval-mozilla-aurora+
lsblakk
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
The algorithm at <http://dev.w3.org/2006/webapi/WebIDL/#dfn-attribute-setter> explicitly special-cases enums, so that setting an enum attribute to an unrecognized value silently fails, rather than throwing. We broke that.
Assignee | ||
Updated•13 years ago
|
status-firefox14:
--- → affected
status-firefox15:
--- → affected
status-firefox16:
--- → affected
tracking-firefox14:
--- → ?
tracking-firefox15:
--- → ?
tracking-firefox16:
--- → ?
We have to fix this before release.
Assignee | ||
Comment 2•13 years ago
|
||
This isn't terribly elegant, but it seems to work, at least.
![]() |
||
Comment 3•13 years ago
|
||
Comment on attachment 634043 [details] [diff] [review]
Patch v1
I don't think you need the invalidEnumValueFatal function. Just pass "not setter" in CGPerSignatureCall.__init__ ?
r=me. Please add mochtests for XHR here or something to actually exercise this code? Also tests for the fact that the method argument throws...
Attachment #634043 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 4•13 years ago
|
||
Comment on attachment 634043 [details] [diff] [review]
Patch v1
[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 740069
User impact if declined: scripts can break if they set responseType to something unrecognized
Testing completed (on m-c, etc.): passes try <https://tbpl.mozilla.org/?tree=Try&rev=ac41076a1718>
Risk to taking this patch (and alternatives if risky): small
String or UUID changes made by this patch: none
Attachment #634043 -
Flags: approval-mozilla-beta?
Attachment #634043 -
Flags: approval-mozilla-aurora?
Comment 5•13 years ago
|
||
Looks like we'll get this into all branches with plenty of time but setting tracking anyway in case there are any followup issues.
Comment 6•13 years ago
|
||
Comment on attachment 634043 [details] [diff] [review]
Patch v1
low risk fix, test included, and we're still nice and early in the beta cycle - approving.
Attachment #634043 -
Flags: approval-mozilla-beta?
Attachment #634043 -
Flags: approval-mozilla-beta+
Attachment #634043 -
Flags: approval-mozilla-aurora?
Attachment #634043 -
Flags: approval-mozilla-aurora+
Assignee | ||
Comment 7•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Assignee | ||
Comment 8•13 years ago
|
||
Comment 9•13 years ago
|
||
The test that verified this fix (test_enums.html) is passing on all the OSs:
https://tbpl.mozilla.org/php/getParsedLog.php?id=14175380&full=1&branch=mozilla-beta
https://tbpl.mozilla.org/php/getParsedLog.php?id=14174727&full=1&branch=mozilla-beta
https://tbpl.mozilla.org/php/getParsedLog.php?id=14178339&full=1&branch=mozilla-beta
https://tbpl.mozilla.org/php/getParsedLog.php?id=14178942&full=1&branch=mozilla-beta
Updated•12 years ago
|
Component: DOM: Mozilla Extensions → DOM
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•