Opened 15 years ago

Closed 14 years ago

Last modified 11 years ago

#524 closed enhancement (fixed)

IframeIO transport is buggy on IE with 'multipart' request and 'text/xml' mimetype

Reported by: [email protected] 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)

test2.html (3.7 KB) - added by [email protected] 15 years ago.
open this file in IE to reproduce the problem
simple.xml (730 bytes) - added by [email protected] 15 years ago.
the xml that contains the ajax response

Download all attachments as: .zip

Change History (14)

Changed 15 years ago by [email protected]

Attachment: test2.html added

open this file in IE to reproduce the problem

Changed 15 years ago by [email protected]

Attachment: simple.xml added

the xml that contains the ajax response

comment:1 Changed 15 years ago by alex

Owner: changed from anonymous to alex

comment:2 Changed 15 years ago by alex

Milestone: 0.3release0.3.1

comment:3 Changed 14 years ago by James Burke

Owner: changed from alex to James Burke

I'll try fixing this (if you want it back Alex, just holler).

comment:4 Changed 14 years ago by James Burke

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 &lt;, > to &gt; and & to &amp; 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 &lt;, &gt;, and &amp; easy? 2) Don't support XML return types for IframeIO

Other options?

comment:5 Changed 14 years ago by James Burke

Resolution: fixed
Status: newclosed

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 14 years ago by [email protected]

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 14 years ago by James Burke

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 14 years ago by anonymous

Resolution: fixed
Status: closedreopened

comment:9 Changed 14 years ago by anonymous

Milestone: 0.3.10.3release
Priority: normalhigh
severity: normalmajor
Type: defectenhancement

comment:10 Changed 14 years ago by anonymous

Component: CoreWebsite
Keywords: javascript command open added
Owner: changed from James Burke to anonymous
Status: reopenednew

comment:11 Changed 14 years ago by James Burke

Component: WebsiteCore
Keywords: javascript command open removed
Milestone: 0.3release0.3.1
Priority: highnormal
Resolution: fixed
Status: newclosed

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.

comment:12 Changed 13 years ago by (none)

Milestone: 0.3.1

Milestone 0.3.1 deleted

Note: See TracTickets for help on using tickets.