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?

 

 

 

5 Comments

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

  • Hello AGZ, I also have a bug in XSL which did not exist in FireFox 2.
    Did you found a solution or informations ?

  • 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 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 elements in the resulting serialized text for FF3.

    The bug is reported:

    https://bugzilla.mozilla.org/show_bug.cgi?id=440974

    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.






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

  • Thanks, Mark. Good luck with rattling the cages.



Comments have been disabled for this content.