Closed Bug 105937 Opened 23 years ago Closed 20 years ago

textarea parsing: <[![CDATA]]> gets corrupted

Categories

(Core :: DOM: HTML Parser, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: tpassin, Assigned: mrbkap)

References

Details

(Keywords: testcase)

Attachments

(1 file)

With Mozilla 0.9.5, a CDATA section inside a textarea element displays incorrectly. <![CDATA[blah blah blah]]> displays as [CDATA[blah blah blah]] Same thing displays correctly in Internet Explorer. Here is a web page that illustrates this problem: <html> <head> <title>CDATA Bug Demo</title> </head> <body> <form> <textarea rows='5' cols='40'><![CDATA[blah blah blah]]> </textarea> </form> </body> </html>
Parser. Serving the same document as XML makes us do the right thing. Is <!CDATA even valid in HTML?
Assignee: asa → harishd
Component: Browser-General → Parser
QA Contact: doronr → moied
Hold on. What's the bug here exactly? Do you want to see "blah blah blah" or "<![CDATA[blah blah blah]]>"? If you want the latter you should really escape your < and > !
That's odd...I didn't think we were supposed to show *anything* inside CDATA sections in HTML.
Comments from reporter: I assume that it should display "blah blah blah", but certainly not "[CDATA[blah blah blah]]" as it did. I would have been fine with "<![CDATA[blah blah blah]]>" in my particular application, but that's clearly wrong, as I think on it more (although IE handles it that way).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration -----
Status: NEW → ASSIGNED
Target Milestone: --- → Future
my expectation is that <![CDATA[foo]]> be entirely ignored just like <!>
certainly i'd expect that w/o a dtd we'd do quirks form and N3 among others treats them like <!>
Attached file Strict mode testcase (deleted) —
Testcase shows "blah blah blah" using clarence's patch 0.9 from bug 57724. Not sure this is correct for textarea, this sounds like it may have to do with discrepancies between SGML and XML content model.
Keywords: testcase
Okay, I was wrong. CDATA sections in HTML should (as far as I can tell) display in the document, but automagically escape markup, etc. inside them (in browsers that support them, of course). The patch in bug 57724 fixes this bug.
Depends on: 57724
*** Bug 206710 has been marked as a duplicate of this bug. ***
the comments above indicate that this bug was fixed by a patch for 57724, but it still happens with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314
That patch has never been checked in and is long obsolete, which is why that bug is not marked "fixed".
.
Assignee: harishd → parser
Status: ASSIGNED → NEW
QA Contact: moied → ian
Summary: CDATA section in textarea element gets truncated → textarea parsing bug: <[![CDATA]]> is corrupted
Summary: textarea parsing bug: <[![CDATA]]> is corrupted → textarea parsing: <[![CDATA]]> gets corrupted
Target Milestone: Future → ---
Depends on: 88952
(In reply to comment #14) > . We are having problems when using CDATA in both link and description tags of RSS (in the browser and live bookmarks). Our feed (http://rss.esporte.uol.com.br/ultimas/index.xml) doesn’t show the same problem in feedReader, Thunderbird, RssReader, for example. And it is validated in www.feedvalidator.org
Assigning to me so I keep track of this. I have a couple of ideas about approaches to this, but need to think them over.
Assignee: parser → mrbkap
Just as a note: now that I'm looking at bug 88952, it's starting to look like I'm going to need to special case CDATA sections in PCDATA to make this bug work right (assuming the patch in bug 88952 is checked in). If I don't then we'll display <![CDATA[content]]>, which is a lot less than ideal.
FIXED by checkin for bug 88952
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 255553 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: