Ticket #524 (closed enhancement: fixed)

Opened 2 years ago

Last modified 15 months ago

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

Reported by: andyhot@… Owned by: anonymous
Priority: normal Milestone:
Component: Core Version: 0.2
Severity: major Keywords:
Cc:

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

test2.html (3.7 kB) - added by andyhot@… 2 years ago.
open this file in IE to reproduce the problem
simple.xml (0.7 kB) - added by andyhot@… 2 years ago.
the xml that contains the ajax response

Change History

Changed 2 years ago by andyhot@…

open this file in IE to reproduce the problem

Changed 2 years ago by andyhot@…

the xml that contains the ajax response

Changed 2 years ago by alex

  • owner changed from anonymous to alex

Changed 2 years ago by alex

  • milestone changed from 0.3release to 0.3.1

Changed 2 years ago by jburke

  • owner changed from alex to jburke

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

Changed 2 years ago by jburke

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?

Changed 2 years ago by jburke

  • status changed from new to closed
  • resolution set to fixed

After discussing on IRC with Alex, removed XML support in IframeIO. MSIE and Safari issues block a good implementation. Done in r4267.

Changed 2 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 ?

Changed 2 years ago by jburke

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.

Changed 2 years ago by anonymous

  • status changed from closed to reopened
  • resolution deleted

Changed 2 years ago by anonymous

  • priority changed from normal to high
  • type changed from defect to enhancement
  • severity changed from normal to major
  • milestone changed from 0.3.1 to 0.3release

Changed 2 years ago by anonymous

  • keywords javascript command open added
  • owner changed from jburke to anonymous
  • component changed from Core to Website
  • status changed from reopened to new

Changed 2 years ago by jburke

  • status changed from new to closed
  • component changed from Website to Core
  • priority changed from high to normal
  • milestone changed from 0.3release to 0.3.1
  • keywords javascript command open removed
  • resolution set to fixed

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.

Changed 15 months ago by anonymous

  • milestone deleted

Milestone 0.3.1 deleted

Note: See TracTickets for help on using tickets.