208779 - Duplicate display of XML CDATA sections in text/xml response

Status: RESOLVED WORKSFORME

(Core :: XSLT, defect)

Description

[shakahshakah]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030608
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030608

Not sure what the "right" display is, but the following text/xml response:

<?xml version="1.0"?>
<XmlResult code="0" message="" userdata="">
<data><![CDATA[<minerRepositoryList>
<minerRepositoryInfo name="common" description="common repository"/>
<minerRepositoryInfo name="companyA" description="repository for Company A"/>
</minerRepositoryList>
]]></data>
</XmlResult>

is rendered differently by this build versus the 1 Jun 2003 nightly build (and
previous builds). The previous build looked "correct", the 8 Jun 2003 nightly
repeats the CDATA contents below the XML block.

Reproducible: Always

Steps to Reproduce:
1. Fetch a URL that returns the XML described in "Details" ;
2. Notice the display in the browser.

Actual Results:  
Contents of CDATA section is repeated below the XML representation.

Expected Results:  
Previous nightlies (last one I tried was 1 Jun 2003) did not repeat the CDATA
contents below the regular XML display. Again, I'm not sure what is "right",
just noting the new (different) behavior.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Happens on Linux too.  Recent regression, sounds like....

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Is the bug with display only, or is the data model wrong?

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Does this happen on the 1.4 branch as well?

Comment 5

[harishd]

I wasn't able to reproduce this bug in my build ( old 04/24!! ) with the patch
checked in by Heikki to fix bug 207904. So, he is off the hook. My gut feeling
is that this is a display bug.

Comment 6

[harishd]

FYI: The extra text is not found in the DOM. And, while observing the document
in DOM inspector I noticed that the html:span's display property is set to
nothing ( i.e., display:;). I believe it should be set to _none_ ( i.e.,
display:none; ) or something.

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

I don't see this bug on 1.4 branch build 20030606.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

On a trunk build I did see this. The layout looks different as well. Reloading
the page made it look as expected (but selecting text did not).

Since this looks like a layout regression, reassigning.

Comment 9

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: simplified testcase

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

I blame XSLT, since the duplication shows up in the content model according to
DOM inspector.

Comment 11

[Axel Hecht]

Seems like noone can reproduce this these days.
Someone with time and the right build might wanna comment whether DOM inspector
shows the duplicated content just for the pretty-printed source or the original
document as well.
I don't have the bandwidth to pull that magic off.
I'm tempted to mark this WORKSFORME in the near future.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I suspect the problem is that the original content of the page doesn't get
hidden, i.e. the user ends up seeing both the prettyprint content and the
original content.

Comment 13

[Andrew Schultz]

I see no duplication with linux trunk 2005061808 and 1.5a (closest thing I have
to a build that might exhibit this bug).

Is this no longer a problem or am I misunderstanding the problem?

Comment 14

[shakahshakah]

It appears to work fine now.