Firefox 3 doesn't apply my xslt stylesheet, but other browsers do.

Question

I'm trying to serve dynamically generated xml pages from a web server, and provide a custom, static, xslt from the same web server, that will offload the processing into the client web browser.

Until recently, I had this working fine in Firefox 2, 3, IE5, 6 and Chrome. Recently, though, something has changed, and Firefox 3 now displays just the text elements in the source.

The page source starts like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Firefox 2.0 and Internet Explorer 7 use simplistic feed sniffing to override desired presentation behavior for this feed, and thus we are obliged to insert this comment, a bit of a waste of bandwidth, unfortunately. This should ensure that the following stylesheet processing instruction is honored by these new browser versions. For some more background you might want to visit the following bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=338621 -->
<?xml-stylesheet type="text/xsl" href="/WebObjects/SantaPreview.woa/Contents/WebServerResources/Root.xsl"?>
<wrapper xmlns="http://www.bbc.co.uk/ContentInterface/Content" xmlns:cont="http://www.bbc.co.uk/ContentInterface/Content" sceneId="T2a_INDEX" serviceName="DSat_T2">
    ....

Firebug shows that the Root.xsl file is being loaded, and the response headers for it include the line

Content-Type    text/xml

I've also tried it with application/xml as the content type, but it makes no difference :-(

The Web Developer Extension shows the correct generated source too, and if you save this and load the page in Firefox, it displays correctly.

The version of Firefox displaying the problem is 3.0.3

Any ideas what I might be doing wrong?

Answer 1

try serving it as application/xml instead of text/xml

Answer 2

Displaying just the text elements is the behavior you would get out of an empty XSL stylesheet.

To me, that suggests that something fishy is going on with your xpath expressions, and that the xsl:template/@match attributes do not match the source document.

You do not provide enough information to diagnose further, so this blind guess is all I can offer.

EDIT: It turned out the problem was that IE and Chrome silently accept a nodeset as argument to string-length, while FF3 does not. Note that the specification mandates an optional string argument and does not specify behavior with a nodeset argument.

Answer 3

Answering my own question in the light of subsequent investigation. ddaa lead me in the right direction.

Firefox seems to be pretty fussy with xslt conversions. Double-check your xslt to ensure it has no errors that IE and Chrome are masking.

XML Spy is a good, though not cheap, product that will highlight a range of errors in the xslt. It seems to pick up at least as many issues as the Firefox renderer does.

It seems you can't rely on the Web Developer extension to pick up the problem, unfortunately.

Answer 4

I just write here for posterity - I had the same symptom, also Firefox 3. However in my case, the problem was another:

Firefox seems to really, really dislike when an XSL file has an underscore _ in the name. My XSLT file was called something like my_super_nice_xslt_which_loads_in_opera_and_ie.xsl.

So, people, let's not use underscores. Use a hyphen (minus) instead: my-super-nice-xslt-which-loads-in-opera-and-ie.xsl.

Then it will load in Firefox as well. I think I will just use dead simple names with letters and numbers in them from now on. You know the saying, "once bitten, twice shy". (In my case, I was bitten twice, but forgot the first time, so that makes me like four times shy this time.)