XMLhttpRequest - responseXML bug in Fx3b2 and current nightly
Foteos Macrides
not encountered any problems when using responseText for
text / HTML-fragment fetches.
But there is an Fx3+ problem through last night's Minefield in handling
the Apple developer site's:
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
example that uses responseXML:
http://developer.apple.com/internet/webcontent/XMLHttpRequestExample/example.html
Fx2.0.0.11 has no problem with that example. The Fx3+ problem is
with the:
result = parentElem.getElementsByTagName(local)[index];
call in:
function getElementTextNS(prefix, local, parentElem, index)
That function is in a script block of the example.html document's head
block.
When one clicks on an option in the Categories select box to load the
Items select box, both Fx2.0.0.11 and Fx3+ return valid result objects
(with tagName values of "title") to load options into the Items select box.
If one then clicks on one of those options, Fx2.0.0.11 returns a valid
result object (with tagName value of "content:encoded") to add material
below that select box, whereas Fx3+ fails, such that 'n/a' is added below
that select box.
Fote
--
Gijs Kruitbosch
This is interesting. Note that using the IE version (calling
getElementsByTagName with the prefix included) works in this case
(checked with Venkman). Maybe this was an intentional change and apple's
example wasn't updated? The comments in the file suggest that it will
not work if there are namespace conflicts - I don't have time to check
for them, but I also suspect there won't be any. Anyway. Maybe this will
help you dealing with it, though it would still be interesting to get
feedback from someone who knows what exactly is going on. :-)
~ Gijs
Foteos Macrides
>> But there is an Fx3+ problem through last night's Minefield in handling
>> the Apple developer site's:
>> http://developer.apple.com/internet/webcontent/xmlhttpreq.html
>> example that uses responseXML:
>>
>> http://developer.apple.com/internet/webcontent/XMLHttpRequestExample/example.html
> This is interesting. Note that using the IE version (calling
> getElementsByTagName with the prefix included) works in this
> case (checked with Venkman). Maybe this was an intentional change
> and apple's example wasn't updated? The comments in the file
> suggest that it will not work if there are namespace conflicts - I don't
> have time to check for them, but I also suspect there won't be any.
> Anyway. Maybe this will help you dealing with it, though it would
> still be interesting to get feedback from someone who knows what
> exactly is going on. :-)
That example code, and those comments, have not changed for quite
a while. It does not work with IE7 because its isIE sniffer is not
taking into account that IE7 has an XMLhttpRequest object (but
implemented like the earlier ActiveX object, instead of meeting the
standards, so that prefix is still needed). I sent the Apple development
site's maintainers a fix for that soon after the IE7 release early last
year,
but it was not patched properly, so IE7 still falls through to the code
for Safari, Firefox and Opera (and any other browsers which comply
with the standards). The latter code, and everything else about that
javascript+xml, hasn't changed for years.
But I do hope someone able to determine the problem for Fx3+ with
sufficient clarity to file a bug, does so (or post's an existing bug number
for it). It would be a shame if the XMLhttpRequest enhancements for
Fx3.0 broke the sole example in the key Apple support document for
AJAX. Plus, that function has become widely used in conjunction with
RSS feeds which might also become broken with Fx3.0.
Fote
--
xfsu...@gmail.com
> Gijs Kruitbosch wrote:
> >> But there is an Fx3+ problem through last night's Minefield in handling
> >> the Apple developer site's:
> >>http://developer.apple.com/internet/webcontent/xmlhttpreq.html
> >> example that uses responseXML:
>
I have found a workaround of this bugs.
function getElementTextNS(prefix, local, parentElem) {
var prefixwithlocal = parentElem.getElementsByTagName(prefix + ":" +
local)[0];
var result = (prefix && prefixwithlocal) ? prefixwithlocal :
parentElem.getElementsByTagName(local)[0];
return result ? (result.childNodes.length > 1 ?
result.childNodes[1].nodeValue : result.firstChild.nodeValue) : 'N/A';
}
Foteos Macrides
> I have found a workaround of this bugs.
>
> function getElementTextNS(prefix, local, parentElem) {
> var prefixwithlocal = parentElem.getElementsByTagName(prefix + ":" +
> local)[0];
> var result = (prefix && prefixwithlocal) ? prefixwithlocal :
> parentElem.getElementsByTagName(local)[0];
> return result ? (result.childNodes.length > 1 ?
> result.childNodes[1].nodeValue : result.firstChild.nodeValue) : 'N/A';
> }
IE doesn't like that getElementsByTagName call to have a lead colon
when there's no prefix, and so would freeze when trying to fill the
"Categories" select box, but that was trivial to deal with and now it
works with all of the browsers including Fx3.
But the fix was essentially to make Fx3 use the prefix for the "Items"
select box, equivalently to how IE does it, whereas Fx2, Safari, and
Opera do not use the prefixing. Could someone point me to a standards
document and/or relevant discussion of this issue?
Based on an email request from Mike Shaver I had filed a bug with CC
to him. That's:
https://bugzilla.mozilla.org/show_bug.cgi?id=414055
but based on the above, it may be a DUPLICATE of::
https://bugzilla.mozilla.org/show_bug.cgi?id=206053
which was RESOLVED FIXED for alpha1, apparently yielding the
above issue.
Fote
--
Boris Zbarsky
> result = parentElem.getElementsByTagName(local)[index];
What's the value of "local"? What does the markup look like for the elements in
question?
-Boris
Boris Zbarsky
> But the fix was essentially to make Fx3 use the prefix for the "Items"
> select box, equivalently to how IE does it, whereas Fx2, Safari, and
> Opera do not use the prefixing. Could someone point me to a standards
> document and/or relevant discussion of this issue?
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-A6C9094
It's generally understood that the term "tag name" (which is not defined
anywhere in the spec) refers to the tag name actually present in the markup.
That wasn't what Firefox 2 implemented, as you discovered.
-Boris
Foteos Macrides
Thanks for the explanation. It's always so simple once you grasp it (but
seems so complex before you do :<). I also really like the fix (once
tweaked for the lead colon issue) that was posted, because it basically
does capability testing instead of using that clunky browser sniffing it the
Apple developer's version, which is now obsolete for both IE7 and Fx3.
Fote
--
Boris Zbarsky
> Thanks for the explanation. It's always so simple once you grasp it (but
> seems so complex before you do :<). I also really like the fix (once
> tweaked for the lead colon issue) that was posted
I'm a little confused by the fact that the code isn't just using
getElementsByTagNameNS in UAs that support it, thus avoiding all these problems...
-Boris
Foteos Macrides
> I'm a little confused by the fact that the code isn't just using
> getElementsByTagNameNS in UAs that support it, thus avoiding
> all these problems...
I'm using a modified version of the Apple developer site's example.html
for some examples of how to use the XMLhttpRequest object (or its
ActiveX predecessor) and responseXML in conjunction with a DHTML
popup library (in XHTML documents), e.g.:
http://www.macridesweb.com/oltest/AJAX.html#ajaxex2
There of course is the issue that IE, through its version 7 (and so probably
for years to come) does not support getElementsByTagNameNS, but also
differences across versions of browsers which do support both that and
getElementsByTagName, e.g., for Fx3 versus Fx2 and Fx1.5 as discussed
in:
https://bugzilla.mozilla.org/show_bug.cgi?id=206053
and:
https://bugzilla.mozilla.org/show_bug.cgi?id=343307
and for Safari:
http://www.xs4all.nl/~jlpoutre/BoT/Javascript/RSSpanel/safari-dom-namespace.html
Based on the earlier post (and it's minor problems with lead colons for
IE7), I at this point am using:
// Retrieves text of an XML document element,
// including elements using namespaces.
//
function getElementTextNS(prefix, local, parentElem, index) {
// circumvent browser differences in getElementsByTagNameNS
// and/or getElementsByTagName
var prefixwithlocal = (prefix) ?
parentElem.getElementsByTagName(prefix+ ":"+local)[index] : null;
var result = (prefix&&prefixwithlocal) ?
prefixwithlocal : parentElem.getElementsByTagName(local)[index];
// get text, accounting for possible
// whitespace (carriage return) text nodes
return result?
(result.childNodes.length > 1 ? result.childNodes[1].nodeValue :
result.firstChild.nodeValue) : 'n/a';
}
which is called via other functions using either:
// Loop through <item> elements, and add each nested
// <title> element to Topics select element
for (var i = 0; i < items.length; i++) {
appendToSelect(select, i,
document.createTextNode(getElementTextNS("", "title", items[i], 0)));
}
or:
// Copy <content:encoded> element text for the selected item.
item = OLhttp.responseXML.getElementsByTagName("item")[select.value];
content = getElementTextNS("content", "encoded", item, 0);
That works for both <title> and <content:encoded> elements with
all of the browsers and versions I have available for testing, and I
suspect (but can't be certain) for all versions of all browsers which
have an XMLhttpRequest object and/or its ActiveX predecessor.
And the getElementTextNS function is only 3 lines of code when
the comments are removed and lines unwrapped for actual use.
I could use:
var result = null;
if (parentElem.getElementsByTagNameNS)
result = parentElem.getElementsByTagNameNS("*", local)[index];
else {
var prefixwithlocal = (prefix) ?
parentElem.getElementsByTagName(prefix+ ":"+local)[index] : null;
result = (prefix&&prefixwithlocal) ?
prefixwithlocal : parentElem.getElementsByTagName(local)[index];
}
if that's what you meant, but since the "else" part works for all of
the browsers, the "if" part is excess baggage.
But if I'm still missing something and there is a better way to do it,
I would appreciated the education.
Fote
--