null XHR.responseXML

Confirming, and assigning to myself.

This could have been avoided if we had tests that validate the output of templates. I'm not sure how we could structure something like this (without making the testsuite much more expensive), but it seems to me that it's something that's worth doing.

Note: if the XMLHttpRequest object supports overrideMimeType, this issue can be worked around by overriding the mime type to "text/xml".

Using MochiKit (which is available on launchpad), that means using something like:

    d = doXHR('https://launchpad.net/', {'mimeType': 'text/xml'});
    function cb(value) { xhr = value; return value; }
    d.addCallback(cb);

Then d.responseXML is set.

This should address the greasemonkey issue.

Matthew, would it be a browser compatibility problem to serve launchpad pages with text/xml MIME type instead of text/html?

In the previous comment, I mean "Then xhr.responseXML is set."

The above work-around doesn't work for me for some reason. xpath still doesn't work, and I have no idea why:

 document.evaluate("//span", xhr.responseXML, null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null).snapshotLength;

This is '0' when it should be at least above 10. Compare against:

 document.evaluate("//span", document, null,XPathResult.UNORDERED_NODE_SNAPSHOT_TYPE, null).snapshotLength;

I do not know about about the technique you are using, but it looks like a problem with your usage.

You can get the desired result using a MochiKit function:
getElementsByTagAndClassName('span', null, xhr.resultXML)

> You can get the desired result using a MochiKit function:
> getElementsByTagAndClassName('span', null, xhr.resultXML)

Right, direct manipulations work, but XPath does not. I have been
hoping to do much more interesting XPath queries, such as:

"//span[contains(@id,'karma-total')]"

Finding an element by id is not this interesting. You can do it using:
    xhr.responseXML.getElementById('karma-total')
or (using MochiKit)
    withDocument(xhr.responseXML, partial(getElement, 'karma-total'))

For really complicated xpath queries, you may need more complicated gymnastics. Generally, if you need more id or class attributes on interesting elements, we can easily provide them on request.

On Wed, Oct 17, 2007 at 11:23:48PM -0000, David Allouche wrote:
> Finding an element by id is not this interesting. You can do it using:
> xhr.responseXML.getElementById('karma-total')
> or (using MochiKit)
> withDocument(xhr.responseXML, partial(getElement, 'karma-total'))

Right, I know I can dig for it, but xpath lets me do very complex
queries without needing to build up lots of "getElement" calls. There
just seems to be something wrong with the resulting object that causes
them not to work with XPath. I have no idea why -- I can't see any
difference between a "good" document object and a "bad" document object
other than the bad one fails to process XPath queries. :(

For some examples of really insane XPath usage, see the bottom of
lp_karma_suffix.user.js[1].

[1] http://codebrowse.launchpad.net/~ubuntu-dev/ubuntu-gm-scripts/ubuntu/files

After discussion with Kees, marking this bug Invalid because there is a simple client-side solution to get XHR.responseXML.