Closed Bug 819328 Opened 12 years ago Closed 11 years ago

FormData.append(string, String) results in NS_ERROR_CANNOT_CONVERT_DATA

Categories

(Core :: XPCOM, defect)

17 Branch
x86_64
Windows 7
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ashi009, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11

Steps to reproduce:

var fd = new FormData();
fd.append('name', new String('value'));


Actual results:

[21:52:10.213] [Exception... "Component returned failure code: 0x80460001 (NS_ERROR_CANNOT_CONVERT_DATA) [nsIDOMFormData.append]"  nsresult: "0x80460001 (NS_ERROR_CANNOT_CONVERT_DATA)"  location: "JS frame :: Web Console :: <TOP_LEVEL> :: line 2"  data: no]



Expected results:

works exactly the same as:
fd.append('name', 'value');
Severity: normal → minor
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Depends on: 776539
Yeah, this is variant idiocy.  Variant sees an object, sets type to VTYPE_INTERFACE_IS, doesn't QI to nsIDOMBlob, lands in nsVariant::ConvertToWStringWithSize, falls through to the default switch case, lands in ToString (data=@0x11dced3f8, outString=@0x7fff5fbf2d18) at nsVariant.cpp:749, and this throws for the INTERFACE_IS type.

Bug 776539 will so fix.
I wonder if we should still fix variant.
Component: DOM → XPCOM
This was fixed with the move of FormaData to webidl.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.