The default bug view has changed. See this FAQ.

HTML closing tags changed to lowercase in form data

NEW
Unassigned

Status

()

Core
Editor
P4
normal
16 years ago
10 years ago

People

(Reporter: prgallier, Unassigned)

Tracking

({compat, testcase})

Trunk
Future
x86
All
compat, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
Forms with text containing HTML codes or HTML-like codes (such as </P>) have the
closing tags changed to lowercase.  This occurs when text is loaded into a form
for editing, not when submitting the form.

Comment 1

16 years ago
Moving.
Assignee: rods → beppe
Component: Form Submission → Editor
QA Contact: vladimire → sujay

Comment 2

16 years ago
if this happens on loading, then this should probably start with Harish,
resassigning
Assignee: beppe → harishd
Priority: -- → P4

Comment 3

16 years ago
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 4

16 years ago
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

Comment 5

15 years ago
the problem also happens in 2002041009 build (1.0rc2), slack8. probably it is a
parser problem.
I'd like to ask a priority change since this affects all kinds of xml code being
retrieved and later submited by a form ("closing tag mismatch" error).

Comment 6

15 years ago
yes, please up the priority.  this is *extremely* annoying if you use an html
form interface to edit html/xml templates. 

Comment 7

15 years ago
Created attachment 95171 [details]
test html page
For example this fails: http://jakobbg.mine.nu/jakob/files/temp/moz.html

This invalidates all xml preloaded into the form.

This goes on Linux as well, OS should be changed to ALL.
You're almost certainly not escaping markup within the <textarea>. If your 
data is, for instance, <xml>element!</xml>, your code should look like:

<textarea>
&lt;xml>element!&lt;/xml>
</textarea>
Keywords: compat, testcase
OS: Windows 98 → All
QA Contact: sujay → editor
Assignee: harishd → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.