Closed Bug 108373 Opened 24 years ago Closed 23 years ago

Wrong reformatting when i open a XHTML document in composer

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: collares, Assigned: harishd)

Details

Attachments

(1 file)

parser patch [ Do not treat '/', in <TAG/>, as an attribute ]
695 bytes, patch
hjtoi-bugzilla
: review+
Details | Diff | Splinter Review
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011023 BuildID: 20011012 If I open a document in composer, it automagically reformat the text. But, if i open some XHTML document which has some <tag/>-style tag, composer formats the XHTML in a wrong way. Reproducible: Always Steps to Reproduce: 1.Open any document which has some <tag/>-style tag in composer. 2.View the source code of that document 3. Actual Results: Composer reformatted the text. <link rel="top" href="index.html" /> was reformatted to <link rel="top" href="index.html" /=""> Expected Results: Code like <link rel="top" href="index.html" /> is correct and don't need to be changed. <html> <head> <title>Test</title> <link rel="top" href="index.html" /> </head> <body> <p>This is a test. Look at the source code.</p> </body> </html>
Ooops, wrong BuildID number... 20011023 is the correct BuildID ( 0.9.5-5 Debian Package )
Confirmed with 2001101914 (~NS6.2) on WinXP; suggest changing OS > All Note -- bug happens even if you have: user_pref("editor.prettyprint", false);
Harish, would this have anything to do with that XHTML flag in the parser that's not being set right?
Sounds like it. The one thing that code does is support empty end-tag syntax.
Er, I was wrong. How peculiar. Code to deal with this is http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsHTMLTokenizer.cpp#620 But it's applied regardless of XML-ness right now (bug, but we need to fix the problem bz mentioned first). So this code seems to support exactly this case, and I don't know why it's not working.
bz & choess: Do you mean that <link/> should be treated as <link></link>. Since is not a container CNavDTD does not generate </link>. The question, however, is why the XHTML document served as text/html? Shouldn't it be text/xml?
typo : The second sentence "Since is" should read "Since link is".
Harish, <link /> should be treated as <link>, not <link /="">. That is, we should not generate an attr node for the "/". I'm fairly surprised that we do, actually... (if we do, see below). This is an XHTML document being opened from disk in composer. So there is no mimetype involved, really. We sniff the extension and get text/html based on ".html" Or is this all a parser non-issue and strictly a composer problem?
>------- Additional Comment #8 From Boris Zbarsky 2001-11-05 11:14 ------- > >Harish, <link /> should be treated as <link>, not <link /="">. Please correct me if i'm wrong, but link should be treated as <link></link>, not <link> <a href="test.htm"/>Test</a> shouldn't generate a link. However, treating <a/> as <a> will generate a link...
This has nothing to do with <a>. It's about <link>, which is in the head. It cannot have any content; it's an empty node by definition. So the construct <link></link> is completely nonsensical. It should just be <link> in HTML or <link /> in XHTML.
Oh, i see... Thanks for the explanation, bz!
Actually, </link> is optional, in HTML. Since link is not a container there is no need to generate </link>.
harishd, is that patch supposed to be a fix, in need of r= sr=? Or are we still debating the problem?
syd: I haven't tested it...but it should fix the problem. Taking the bug.
Assignee: syd → harishd
Status: UNCONFIRMED → NEW
Component: Editor: Composer → Parser
Ever confirmed: true
Keywords: patch
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.8
Comment on attachment 56581 [details] [diff] [review] parser patch [ Do not treat '/', in <TAG/>, as an attribute ] r=heikki
Attachment #56581 - Flags: review+
This bug should be fixed. Sujay, could you please verify? Thanx.
qa_contact --> moied
QA Contact: sujay → moied
verfied with Build ID 20020115 on win2k Composer does not reformat any more
This is FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Verified with Build ID 20020115 on Linux. Marking Verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: