Firefox 3 doesn't apply my xslt stylesheet, but other browsers do
Asked Answered
C

5

10

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?

Collide answered 21/10, 2008 at 10:47 Comment(0)
D
6

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.

Delectate answered 23/10, 2008 at 21:3 Comment(2)
I'll take a look and double-check. Both IE and Chrome seem to be doing the transformation OK, though, and the Web Developer extension in Firefox is displaying html that looks valid for the generated source. How accurate is the generated source window? Does it show the exact source used to render?Collide
Also, do not use underscore in the name of the XSLT file. I had this, and when I changed to a filename without underscore, it worked fine in Firefox.Vindictive
K
4

If you're using NoScript, that also disables XSL stylesheets until you Allow <site>.

Kloof answered 24/4, 2013 at 12:2 Comment(2)
This was it for me. I would never have guessed that NoScript was disabling XSL stylesheet loading, let alone processing, but until I whitelisted the site, FireFox didn't even do the HTTP request for the XSL stylesheet. Once I whitelisted the site, the page auto-reloaded and it requested and used the stylesheet.Stripteaser
I feel so stupid right now, but this was exactly my issue. I know that "thank you" comments are generally frowned upon on SO, but thank you.Aranda
C
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.

Collide answered 21/10, 2008 at 10:47 Comment(3)
So, was that indeed a kind of namespace matching problem?Delectate
No. I had an xpath problem. string-length() on IE and Chrome doesn't mind if the argument is a node list, but XML Spy complains that there are "Too many items" and changing the expression made Firefox spring back to life.Collide
Is there a way to get an error message from firefox? I have the same problem and XML Spy does not complain. 8-/Georgeta
V
3

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.)

Vindictive answered 13/10, 2010 at 15:48 Comment(0)
O
0

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

Osteophyte answered 21/10, 2008 at 23:59 Comment(1)
Sometimes it does for other browsers, so not a bad guess.Vindictive

© 2022 - 2024 — McMap. All rights reserved.