Don't throw when setting XHR.responseType to an invalid value

RESOLVED FIXED in Firefox 14

Status

()

Core
DOM
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: Ms2ger, Assigned: Ms2ger)

Tracking

({regression})

Trunk
mozilla16
regression
Points:
---

Firefox Tracking Flags

(firefox14+ fixed, firefox15+ verified, firefox16+ fixed)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
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

5 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

5 years ago
Created attachment 634043 [details] [diff] [review]
Patch v1

This isn't terribly elegant, but it seems to work, at least.
Assignee: nobody → Ms2ger
Status: NEW → ASSIGNED
Attachment #634043 - Flags: review?(bzbarsky)
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

5 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?
Looks like we'll get this into all branches with plenty of time but setting tracking anyway in case there are any followup issues.
tracking-firefox14: ? → +
tracking-firefox15: ? → +
tracking-firefox16: ? → +
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

5 years ago
https://hg.mozilla.org/mozilla-central/rev/9ce5e415d5da
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
(Assignee)

Comment 8

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/238fc377f102
https://hg.mozilla.org/releases/mozilla-beta/rev/567afb848289
status-firefox14: affected → fixed
status-firefox15: affected → fixed
status-firefox16: affected → fixed

Comment 9

5 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
status-firefox15: fixed → verified
Component: DOM: Mozilla Extensions → DOM
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.