#441 closed defect (fixed)
IFrameIO with text/html not working properly
Reported by: | Owned by: | anonymous | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | General | Version: | 0.3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
When using IFrameIO with a mime-type of text/html, the returned data isn't actually returned (I'm under the impression that the contents of the first textarea field element are returned as data to the load function). Actually, a variant on this would work better even if it's not the case.
The following code snippet added to the appropriate place in dojo.io.IFrameIO.iframeOnLoad() fixes the problem (at least on mozilla), the first line is a good marker for location:
replace:
else{ text/plain
value = ifw.innerHTML;
}
with:
else{ text/plain
var doc = ifw.document; var e = doc.getElementsByTagName("textarea"); if(e.length) value = e.item(0).innerHTML;
}
Thanks!
Bill Welliver [email protected]…
Change History (4)
comment:1 Changed 16 years ago by
Milestone: | 0.2.2release → 0.3release |
---|---|
Version: | 0.2 → 0.3 |
comment:2 Changed 16 years ago by
Milestone: | 0.3release → 0.4 |
---|
comment:3 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
This was fixed in 0.3.1, but not in the manner suggested by this bug. The HTML document object is returned. See this test file:
http://archive.dojotoolkit.org/nightly/tests/io/test_IframeIO.html.html
actually, it turns out that certain browsers encode html contained within a textarea element, so you can't just get the contents of a textarea and stick it someplace else; the html elements have been converted with > and so forth.
I don't confess to understand the origins of the technique, but it does seem that using a div as the "holder" for the returned value will work better than a textarea.
So, in my example solution, replacing "textarea" with "div" seems to work better.