Opened 14 years ago

Closed 13 years ago

Last modified 10 years ago

#524 closed enhancement (fixed)

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

Reported by: andyhot@… 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 andyhot@… 14 years ago.
open this file in IE to reproduce the problem
simple.xml (730 bytes) - added by andyhot@… 14 years ago.
the xml that contains the ajax response

Download all attachments as: .zip

Change History (14)

Changed 14 years ago by andyhot@…

Attachment: test2.html added

open this file in IE to reproduce the problem

Changed 14 years ago by andyhot@…

Attachment: simple.xml added

the xml that contains the ajax response

comment:1 Changed 13 years ago by alex

Owner: changed from anonymous to alex

comment:2 Changed 13 years ago by alex

Milestone: 0.3release0.3.1

comment:3 Changed 13 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 13 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 13 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 13 years ago by andyhot@…

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

Resolution: fixed
Status: closedreopened

comment:9 Changed 13 years ago by anonymous

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

comment:10 Changed 13 years ago by anonymous

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

comment:11 Changed 13 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 12 years ago by (none)

Milestone: 0.3.1

Milestone 0.3.1 deleted

Note: See TracTickets for help on using tickets.