Rendered XML garbled particularly when server returns small chunks

NEW
Unassigned

Status

()

Core
XSLT
P1
normal
10 years ago
7 years ago

People

(Reporter: Jake Garver, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Starting with Firefox 3, we see clipped output when rendering an XML file generated by our embedded device.  I was able to reproduce the problem with a static XML file, but only if I wrapped with a "dd" that chunked the return.  The problem is very evident when using very small 5 byte chunks.

Attached is a screenshot, Truncated_XML_Rendering.jpg, so you can see what I'm talking about easily.

The page renders fine in Firefox 2 and IE7.



Reproducible: Always

Steps to Reproduce:
To reproduce, put the following 3 files in the same directory on a web server.  I used Apache on Linux.
1. x.xml.  This is a simplified version of our output, made a little longer so you'll be sure to see the problem.
2. list.xsl.  A simplified version of our stylesheet.
3. breakit.cgi.  A simple CGI script that uses "dd" to make 5 byte chunks of x.xml.

To see the problem, point Firefox 3 at "breakit.cgi".  Usually the first 10-30 lines are fine, but then you'll see the "unknown"s start to get truncated.  A refresh results in a different pattern, implying some randomness.

Actual Results:  
Usually the first 10-30 lines are fine, but then you'll see the "unknown"s start to get truncated.  A refresh results in a different pattern, implying some randomness.

Expected Results:  
Each line should be:
X/X enable unequipped unknown unknown none unknown unknown unknown unknown unknown

I suspect the problem is around the input boundaries.  If the server sends big chunks there are fewer input boundaries and you're less likely to see it.  If the server sends small chunks, more input boundaries, greater probability.
(Reporter)

Comment 1

10 years ago
Created attachment 326958 [details]
Actual output, demonstrates render problem
(Reporter)

Comment 2

10 years ago
Created attachment 326959 [details]
Simple CGI script to chunk the static file and expose the problem.
(Reporter)

Comment 3

10 years ago
Created attachment 326960 [details]
Stylesheet
(Reporter)

Comment 4

10 years ago
Created attachment 326961 [details]
Static XML file demonstrating the problem when processed through breakit.cgi
(Reporter)

Comment 5

10 years ago
The problem still exists in Minefield 3.1a2pre (Build 20080826034105).
(Reporter)

Updated

10 years ago
Version: unspecified → 3.0 Branch
(Reporter)

Comment 6

10 years ago
The problem still exists in Minefield 3.1b1pre
(Reporter)

Comment 7

10 years ago
It seems to be caused when text() crosses packets.  To test this theory, I wrote the following simple wrapper around my static xml file (attached).

The first fflush will flush after every packet and causes severe corruption in the rendered page.  The second fflush will guarantee that text() is always sent whole.  When the first fflush is commented and the second is uncommented, the screen renders fine.

So, I have a (ugly) workaround.

#include <stdio.h>

int main(int argc, char *argv[])
{
        FILE *src=fopen("x.xml", "r");
        int next;

        printf("Content-Type: text/xml\n\n");

        while((next=fgetc(src))!=EOF)
        {
                fputc(next, stdout);

                /* breaks */
                /* fflush(stdout); */

                /* doesn't break */
                if(next=='>') fflush(stdout);
        }
}
Component: General → XSLT
Product: Firefox → Core
QA Contact: general → xslt
Version: 3.0 Branch → Trunk
Attachment #326960 - Attachment mime type: text/plain → application/xml
Attachment #326961 - Attachment mime type: text/plain → application/xml
My guess is that this broke in the incremental xml bug. What likely is happening is that we create multiple separate textnodes, rather than appending to the existing one. We used to have code to ensure that we always appended to existing one when parsing an XSLT source file.

To work around this, try changing

<xsl:template match="*" mode="listItem">
   <!-- Finally, output the column -->
   <td class="contentTableCell">
   	<xsl:value-of select="text()"/>
   </td>
</xsl:template>

to

<xsl:template match="*" mode="listItem">
   <!-- Finally, output the column -->
   <td class="contentTableCell">
   	<xsl:value-of select="."/>
   </td>
</xsl:template>
Blocks: 18333
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x?
Flags: blocking1.9.1+
Perhaps fixed by the patch in bug 449219?
(Reporter)

Comment 10

10 years ago
Thanks, Jonas.

I can't always use "." because we might have text in sub-elements, but the following will also work.

<xsl:value-of select="text()[1]"/><xsl:value-of select="text()[2]"/>

That also seems to confirm that it's being broken into two (or more) textnodes.
Not blocking on this after all. Wanted+, and over to Jonas.
Flags: wanted1.9.1+
Flags: blocking1.9.1-
Flags: blocking1.9.1+
Priority: -- → P1
(Reporter)

Comment 12

10 years ago
I'm using the following general purpose template to work around this problem.  Anywhere that I was using text(), I call or apply this into a variable instead.  Of course, I use text() everywhere, so this work around was a bit invasive.

<xsl:template name="detailText" match="*" mode="detailText">
   <xsl:for-each select="text()">
      <xsl:value-of select="."/>
   </xsl:for-each>
</xsl:template>

The problem was worse on long screens, but I proved that I could experience it on any screen whose XML crossed multiple packets.  That's why I had to go around and wrap every use of text().
Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at a reviewed and baked patch.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
This is a regression introduced in the 3.0 release. Renominating.
Flags: wanted1.9.0.x- → wanted1.9.0.x?
Keywords: regression
Marking it "wanted1.9.0.x" doesn't make a patch appear, just means we'll have a more positive attitude when presented with a branch approval request. Still needs to get fixed on trunk.
Flags: wanted1.9.0.x? → wanted1.9.0.x+
You need to log in before you can comment on or make changes to this bug.