Firefox 3. XSLT Processing Engine bug?

I stumbled upon really strange issue while researching unexpected behavior of existing web application under Firefox 3.

So, there are ultimately simplified steps to reproduce:

1. XML document:

<?xml version="1.0"?>
<items>
    <item>
        <id>1</id>
    </item>
    <item>
        <id>2</id>
    </item>
    <item>
        <id>3</id>
    </item>           
</items>

2. XSL stylesheet:

<?xml version="1.0"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="html" />
    <xsl:template match="item">
        <tr id="{id}">
            <td>
                <xsl:value-of select="id" />
            </td>
        </tr>   
    </xsl:template>
</xsl:stylesheet>

3. Load these XML and XSL documents to Document instances.

4. Transform this XML document using given XSL stylesheet with the following code:

            var processor = new XSLTProcessor();
            processor.importStylesheet(xsl);           
            var doc = processor.transformToDocument(xml);             

In Firefox 2 we would get following document as a result of this utterly ordinary code:

 <transformiix:result xmlns:transformiix="http://www.mozilla.org/TransforMiix">
    <TR id="1">
        <TD>1</TD>
    </TR>
    <TR id="2">
        <TD>2</TD>
    </TR>
    <TR id="3">
        <TD>3</TD>
    </TR>
</transformiix:result>

Since we used transformToDocument and there is no root node in the resulting XML fragment then we have wrapping <transformiix:result /> document element node.

But, as I said, in Firefox 3 result differs. I got following document:

<transformiix:result xmlns:transformiix="http://www.mozilla.org/TransforMiix">
    <transformiix:result>
        <TR id="1">
            <TD>1</TD>
        </TR>
        <TR id="2">
            <TD>2</TD>
        </TR>
    </transformiix:result>
    <TR id="3">
        <TD>3</TD>
    </TR>
</transformiix:result>

Do you see the difference? There is unexpected (at least to me) <transformiix:result /> element wrapping first two <tr /> elements in the resulting document.

And it gets event more interesting with an increase of the number of items in the original document. For example with four items we would get:

<transformiix:result xmlns:transformiix="http://www.mozilla.org/TransforMiix">
    <transformiix:result>
        <transformiix:result>
            <TR id="1">
                <TD>1</TD>
            </TR>
            <TR id="2">
                <TD>2</TD>
            </TR>
        </transformiix:result>
        <TR id="3">
            <TD>3</TD>
        </TR>
    </transformiix:result>
    <TR id="4">
        <TD>4</TD>
    </TR>
</transformiix:result>

And so on...

This behavior starts when the number of elements is equal to or grater than 3.

 Any thoughts?

 

 

 

Published Saturday, June 21, 2008 1:21 AM by AGS777
Filed under:

Comments

# re: Firefox 3. XSLT Processing Engine bug?

Friday, July 04, 2008 3:00 AM by Egor

This worked for me:

1) type about:config in the address bar

2) change security.fileuri.strict_origin_policy to false

Taken from

forums.mozillazine.org/viewtopic.php

# re: Firefox 3. XSLT Processing Engine bug?

Friday, July 04, 2008 5:32 AM by AGS777

Egor,

Unfortunately the problem/solution referred to in your comment is completely irrelevant to the issue I indicated in the post.

The issue is not related to XSLT file path in any case and, as it is shown in the post, the processing does not fail, the problem actually is in the erroneous result of the processing.

Thanks for you reply though.

# re: Firefox 3. XSLT Processing Engine bug?

Tuesday, July 08, 2008 12:40 PM by Veacks

Hello AGZ, I also have a bug in XSL which did not exist in FireFox 2.

Did you found a solution or informations ?

# re: Firefox 3. XSLT Processing Engine bug?

Monday, September 01, 2008 11:26 AM by Mark

You are right, there are differences in the output here.  Browser dev teams with different interpretations on how this should be handled maybe?  But fwiw, I fixed the wraparound issue in Firefox with this little XSLT workaround, using your example:

&lt;?xml version="1.0"?&gt;

 &lt;xsl:stylesheet version="1.0" xmlns:xsl="www.w3.org/.../Transform"&gt;

   &lt;xsl:output method="html" /&gt;

   &lt;xsl:template match="items"&gt;

   &lt;tr id="{id}"&gt;

     &lt;xsl:for-each select="item"&gt;

       &lt;td align="left"&gt;&lt;xsl:apply-templates/&gt;&lt;/td&gt;

     &lt;/xsl:for-each&gt;

   &lt;/tr&gt;

   &lt;/xsl:template&gt;

&lt;/xsl:stylesheet&gt;

However Opera doesn't put any whitespace between cell items like Firefox and IE6 did in my test, but that's another issue, I guess.  Hope this helps.

Mark

ajamyajax.com

# re: Firefox 3. XSLT Processing Engine bug?

Monday, September 01, 2008 12:13 PM by Mark

Well let me try that again, hope this post's format looks better:

<pre>

<?xml version="1.0"?>

 <xsl:stylesheet version="1.0" xmlns:xsl="www.w3.org/.../Transform">

   <xsl:output method="html" />

   <xsl:template match="items">

   <tr id="{id}">

     <xsl:for-each select="item">

       <td align="left"><xsl:apply-templates/></td>

     </xsl:for-each>

   </tr>

   </xsl:template>

</xsl:stylesheet>

</pre>

# re: Firefox 3. XSLT Processing Engine bug?

Monday, September 01, 2008 5:00 PM by AGS777

Mark,

It is not "different interpretation", it is plain and simple bug that is very annoying.

Regarding your workaround:

1. It does not matter, of course, in this case but your stylesheet provides entirely different result from the one presented in the original post :) - one row with several <td /> elements instead of several rows. But, as I said, it does not matter.

2. What is important is that the actual XSLT stylesheet for which I encountered the bug originally is rather complex. The example I presented here is just the simplest one I could come up with. It is not suitable, and not always possible to rework numerous number of complex stylesheets to eliminate one particular bug of the single browser. Temporary workaround I use at the moment is to remove the <transformiix:result /> elements in the resulting serialized text for FF3.

The bug is reported:

bugzilla.mozilla.org/show_bug.cgi

but strangely enough it is not even assigned for quite some time.

From my personal experience I found that Microsoft development team is much more responsive and I am really disappointed by the attitude demonstrated by Mozilla development team.

# re: Firefox 3. XSLT Processing Engine bug?

Monday, September 01, 2008 8:16 PM by Mark

Ok, fair enough about the bug comment.  However, I did run your actual code and the workaround was for what I thought you were trying to do...  So my misunderstanding there but that workaround could easily be changed to do x rows instead of one, right?  I'm sure you saw that.  But, like you say one little workaround doesn't matter if the bug issue in general is your primary concern.

And sure Microsoft has been better.  No arguments there.  I wonder who pays the Mozilla team, though?  Maybe that's an issue.  Just wondering if that's a factor.  I'm on the outside also, not defending them.

Anyway, I'll check that Bugzilla post when I get a chance.  Maybe I'll post a similar little workaround there, if it is appropriate. I have posted several on Bugzilla -- where it looked like no FF fix is forthcoming -- to help of course, but also to see if that rattles the cages of any of their team members. :)  

So, we'll see.  Good luck.

# re: Firefox 3. XSLT Processing Engine bug?

Tuesday, September 02, 2008 3:56 AM by AGS777

Thanks, Mark. Good luck with rattling the cages.

Leave a Comment

(required) 
(required) 
(optional)
(required)