#524 closed enhancement (fixed)
IframeIO transport is buggy on IE with 'multipart' request and 'text/xml' mimetype
Reported by: | Owned by: | anonymous | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | Core | Version: | 0.2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
Dojo's IframeIO transport is buggy on IE when the request is multipart. In that case, the xml nodes returned to our load function (specified in dojo.io.bind) seem to contain the whole hidden iframe used for the transport.
Additionaly, the true response xml is hidden inside the text nodes of the above nodes.
In tacos.sf.net, we fixed / hacked this by
- gathering the values of all text nodes in a string,
- removing the doctype (IE doesn't seem to like this)
- having a Microsoft.XMLDOM create xml nodes from the generated string
I'll try to attach 2 files that demonstrate this problem + contain the possible fix.
Attachments (2)
Change History (14)
Changed 15 years ago by
Attachment: | test2.html added |
---|
comment:1 Changed 15 years ago by
Owner: | changed from anonymous to alex |
---|
comment:2 Changed 15 years ago by
Milestone: | 0.3release → 0.3.1 |
---|
comment:3 Changed 15 years ago by
Owner: | changed from alex to James Burke |
---|
I'll try fixing this (if you want it back Alex, just holler).
comment:4 Changed 15 years ago by
OK, this is ugly. I would like some feedback.
Problems with the current implementation of xml handling with IframeIO:
- Doesn't work in Safari 2.0.3. Just like with text/plain documents, we don't get the onload call for xml files.
- The issue in this bug: MSIE seems to convert the XML into an HTML document for pretty display in the browser. Ugh.
I tried converting the XML path to use the same approach as javascript or text/plain -- use an HTML page with a textarea that has the XML inside of the textarea tag, and use dojo.dom.createDocumentFromText() to create the XML doc. Works fine for MSIE, but:
- Firefox complains about <?xml version="1.0" encoding="UTF-8"?> being in the wrong place.
- Safari 2.0 does not error out, but the resulting XML document is probably either empty or formatted differently. In either case, I can't use the same getElementsByTagName() call to get the result XML element that I'm looking for.
I'm down to two options. Feedback is appreciated: 1) Require that the XML be escaped (convert < to <, > to > and & to & inside the text area tag, so it will just be treated as a text string by the browser, so we can reconstitute it correctly in Firefox and Safari. Do we have dojo methods to make unescaping the <, >, and & easy? 2) Don't support XML return types for IframeIO
Other options?
comment:5 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
After discussing on IRC with Alex, removed XML support in IframeIO. MSIE and Safari issues block a good implementation. Done in r4267.
comment:6 Changed 15 years ago by
So, in a word, we cannot have forms containing upload components and expect dojo to submit them + get back normal 'text/xml' response.
Do you know if there's any way to achieve exactly that (since IFrameIO cannot help)? Perhaps IScriptIO ?
comment:7 Changed 15 years ago by
ScriptSrcIO won't work: it uses script src tags to get the response, so the response has to be pure javascript.
I don't think there is a way to do what you want (file upload and get a pure XML response) with the existing Dojo IO providers.
comment:8 Changed 15 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:9 Changed 15 years ago by
Milestone: | 0.3.1 → 0.3release |
---|---|
Priority: | normal → high |
severity: | normal → major |
Type: | defect → enhancement |
comment:10 Changed 15 years ago by
Component: | Core → Website |
---|---|
Keywords: | javascript command open added |
Owner: | changed from James Burke to anonymous |
Status: | reopened → new |
comment:11 Changed 15 years ago by
Component: | Website → Core |
---|---|
Keywords: | javascript command open removed |
Milestone: | 0.3release → 0.3.1 |
Priority: | high → normal |
Resolution: | → fixed |
Status: | new → closed |
Hmm, spam/hack resetting this, or is this a request to have this issue reconsidered? Closing again, but if you want this bug to be reconsidered, please add comments as to why.
open this file in IE to reproduce the problem