The XML Document returned is original, untransformed, document at the location specified by the URL. It doesn't look like I can attach files to this bug, but I'll give you a quick example: xmldoc.xml: -------------- <?xml version="1.0" encoding="UTF-8" ?> <?xml-stylesheet type="text/xsl" href="xsldoc.xsl"?> <page> <paragraph> <line>This is line one.</line> <line>This is line two.</line> </paragraph> </page> xsldoc.xsl: -------------- <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="text" omit-xml-declaration="yes" /> <xsl:template match="//page"> <xsl:for-each select="paragraph"> <p> <xsl:apply-templates /> </p> </xsl:template> <xsl:template match="line"> <br> <xsl:value-of select="."/> </br> </xsl:template> </xsl:stylesheet> ------- When I enter the url for xmldoc.xml into the browser, i get the result of the transformation, however requesting it in an XMLHttpRequest just returns xmldoc.xml as an xml document.
Created attachment 10096 [details] The XML document listed in the description.
Created attachment 10098 [details] The XSL document listed in the description (There were typos in the listing that are corrected here)
I didn't think transforms would be auto-applied to XMLHttpRequests. Does Firefox respect this?
It's not clear to me that we should respect this.... since I would think you'd want the source doc rather than the result doc (XSL can transform you to plain text or HTML as well, and that seems really strange to me if you could get that kind of transformed result from XMLHttpRequest).
Firefox doesn't support this, unfortunately. Your recent addition of the XSLT processor makes this sort of moot (and hooray!), but I was just trying to work around the absence of browser-side transformations. I don't think that it would be totally unexpected behaviour, however. XMLHttpRequest already handles both text and XML data in response*, so either of those output methods could be interpreted. In any case, I can certainly appreciate not breaking compatibility with Mozilla in this regard, and since browser side XSL is in the nightlies, it's certainly nothing important.
Closing as invalid per comments 4 and 5.