Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#10325 closed defect (wontfix)

FileUploader postData Error

Reported by: youngho Owned by: Mike Wilcox
Priority: high Milestone: future
Component: DojoX Form Version: 1.4.0b
Keywords: FileUploader Cc:
Blocked By: Blocking:



JSLint has no complain about

var postData = {

'a': 'hello', 'a-b': 'ok'


But If you set this format data into FileUploader? postData, Than There are error occur 'missing : after property id' after file uploaded.

You can reproduce it with attached patch file of the test_FileUploader.html

Attachments (1)

1.patch (730 bytes) - added by youngho 9 years ago.

Download all attachments as: .zip

Change History (9)

Changed 9 years ago by youngho

Attachment: 1.patch added

comment:1 Changed 9 years ago by Adam Peller

Owner: changed from dante to Mike Wilcox

comment:2 Changed 9 years ago by dante

Milestone: tbdfuture

comment:3 Changed 9 years ago by Mike Wilcox

Resolution: wontfix
Status: newclosed

I made an attempt to fix this problem with this code in the JS:

var o = {};
for(var nm in this.postData){
    o['"'+nm+'"'] = this.postData[nm];

But it still failed. I'm actually not sure what else to do other than a special serialization that looks for invalid characters, replaces them, and unserializes them on the Flash side. It seems a bit much for an edge case. If you can provide a more elegant solution I'll be glad to look into it.

I did update the docs with this limitation.

comment:4 Changed 9 years ago by Adam Peller

Is this a more general problem with JSON over the flash bridge? Who is actually doing the serialization? Is doUpload our code or Flash?

comment:5 Changed 9 years ago by Mike Wilcox

Flash is doing the serialization through the ExternalInterface?. doUpload() is a method of the SWF. JSON isn't a good solution because Flash doesn't support it and I'd have to write a fromJson method.

Maybe dashes in node names are more common than I thought? I think technically if dashes were allowed we need to allow most anything wouldn't we?

comment:6 Changed 9 years ago by Adam Peller

so it's not a JSON thing, per se. It's just that property names sometimes need to be quoted in order to parse. The dash is one example, reserved words are another. JSON solves this by quoting everything. I'm curious as to exactly where this is blowing up. The exception is a bit cryptic, with no stack trace:

try { __flash__toXML(console.log(" * d...est:null}))) ; } catch (e) { "<undefin

There's a console log in there, so I figured this was our code? If Flash is using XML, perhaps we have a problem with XML escapes also?

comment:7 Changed 9 years ago by Mike Wilcox

The flashtoXML is added to the global space by the plugin. You can look at it with:


As I said originally I tried quoting the prop names (both single and double), it didn't work. I have in the past done this with my Flash XML parser, but that was coming *from* Flash. This one isn't cooperating.

The console looked strange to me too and I poked around, but it seems to be just stuff blowing up. I managed several different errors in that function all with different code from all over the app.

And after looking into it the problem is worse than I thought. This serialization happens from JS to Flash, from Flash to the server, server to Flash, then Flash to JS. So any workaround would be very difficult and tedious.

Though this could be worked around in a custom solution – the postdata could be serialized as a string, kept as a string in Flash (my SWF just passes postdata around, it never looks at it) and could be deserialized on the server.

It's just another buggy Flash feature.

comment:8 Changed 9 years ago by Adam Peller

It's just another buggy Flash feature.

Yeah, it's just frustrating not being able to at least debug the JS error message to figure out where this call to flashtoXML comes from and what's being passed. Firebug doesn't give any clues and, unfortunately, it seems to work fine in Safari.

Odd thing is this JS error is something you'd expect coming *out* of the serialization, trying to eval {a-b:'ok'} without the quotes, not going in with a toXML call. Perhaps it has something to do with the XML implementation. I don't think hyphens are okay in XML id's.

Note: See TracTickets for help on using tickets.