Closed
Bug 154882
Opened 23 years ago
Closed 20 years ago
textarea parsing: entities inside <tags> get corrupted
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
FIXED
People
(Reporter: d.voelzke, Assigned: mrbkap)
References
Details
Attachments
(2 files)
|
172 bytes,
text/html
|
Details | |
|
2.55 KB,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020530
BuildID: 2002053012
When mozilla displays a page with a textarea in it and within the textarea there
is a preset text and this text includes something like '<input value="e;'
the scanner/parser doesn't replace the "e; by " (the quote character).
Reproducible: Always
Steps to Reproduce:
1. create a .html file with a text editor and the following contents:
<HTML>
<BODY>
<FORM>
<TEXTAREA ROWS=5 COLS=40>
input value=" *** good *** ">
<input value=" *** bad *** ">
</TEXTAREA>
</FORM>
</BODY>
</HTML>
2. save it and open it with the browser
3. take a look, it's obviously: the two preset textarea lines should be same
except the '<' character
4. activate "view source" for details
Actual Results: textarea displays (wrong):
input value=" *** good *** ">
<input value=" *** bad *** ">
MAYBE YOU DONT SEE ANY DIFFERENCE TO THE EXPECTED RESULTS BECAUSE THIS TEXT IS
ENTERED IN THE ERROREOUS TEXTAREA!
Expected Results: textarea should display:
input value=" *** good *** ">
<input value=" *** bad *** ">
MAYBE YOU DONT SEE ANY DIFFERENCE TO THE ACTUAL RESULTS BECAUSE THIS TEXT IS
ENTERED IN THE ERROREOUS TEXTAREA!
In the "good" line there are quote characters.
In the "bad" line the quote characters are replaced by the string '"e;'.
When you view the source (i used enabled syntax highlighting) you'll see the
problem: the displayed source differs from the source file.
This error is neither in Netscape Navigator 4.79 (windows 98se and windows 2000)
nor in Internet Explorer 5.5 (windows 98se and windows 2000).
I got a server maintaining a data base with free text. when the user updates any
free text data displayed within a textarea it may change without any aimed changes.
Confirmed with branch build 20020628 on winXP
Status: UNCONFIRMED → NEW
Ever confirmed: true
|
||
Comment 3•23 years ago
|
||
This is a duplicate. Please find the original and mark it so (and the "<" in
that testcase should be escaped.... then the problem would not arise in the
first place).
This is most likely a dup of bug 107537 or bug 99467
Whiteboard: DUPEME
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.2beta
Allow attributes within the textarea content to be consumed as text to ensure
entity conversion. That is, w.r.t the above test case the attributes of <input>
will not be consumed as attributes rather will be consumed as text.
|
||
Comment 6•21 years ago
|
||
.
Assignee: harishd → parser
Status: ASSIGNED → NEW
Whiteboard: DUPEME
Target Milestone: mozilla1.5beta → ---
|
|
||
Comment 7•21 years ago
|
||
*** Bug 166866 has been marked as a duplicate of this bug. ***
|
|
||
Updated•21 years ago
|
QA Contact: moied → ian
Summary: preset text in textarea which includes <input and "e isn't displayed properly → textarea parsing bug: entities inside <tags> get corrupted
|
|
||
Updated•21 years ago
|
Severity: major → normal
OS: Windows 98 → All
Priority: P3 → --
Hardware: PC → All
Summary: textarea parsing bug: entities inside <tags> get corrupted → textarea parsing: entities inside <tags> get corrupted
|
||
Comment 8•21 years ago
|
||
The following (unescaped) text inside a text area:
<param><value><dateTime.iso8601></dateTime.iso8601></value></param>
is rendered in a funky way: the opening datetime tag is shown as
<dateTime.iso8601>, while the closing tag is shown as </dateTime>
I'd expect the browser to either choke on any non-html unescaped tag or to
display all of them correctly...
p.s. Tested on Moz 1.6
p.p.s. the same text, inserted html-escaped in the same textarea works just fine
|
Assignee | |
Comment 9•20 years ago
|
||
*** Bug 244066 has been marked as a duplicate of this bug. ***
|
|
Assignee | |
Updated•20 years ago
|
Assignee: parser → mrbkap
|
|
Assignee | |
Comment 10•20 years ago
|
||
FIXED by checkin to bug 88952
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 11•20 years ago
|
||
*** Bug 273942 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.
Description
•