Closed
Bug 136397
Opened 23 years ago
Closed 15 years ago
Do not always treat FORM as a leaf in CNavDTD.
Categories
(Core :: DOM: HTML Parser, defect, P3)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
FIXED
mozilla1.9alpha1
People
(Reporter: harishd, Unassigned)
References
Details
(Whiteboard: [fixed by the HTML5 parser])
As far as the CNavDTD is concerned FORM is always considered a leaf element.
However, the content sink treats FORM as a container depending on it's parent.
This discrepancy has caused a lot of issues. One way to solve this is to treat
FORM, in the CNavDTD & in the content sink, alike.
There are risks in fixing this bug and therefore has to wait :-(
Target Milestone: --- → mozilla1.0.1
I write one simple html like this
<HTML><BODY><form><B>abc</b></form></BODY></HTML>
when I debug CNavDTD, it shows that it treat <form> as container,
CNavDTD::OpenForm(const nsIParserNode * 0x0388fef8) line 3199
CNavDTD::OpenContainer(const nsCParserNode * 0x0388fef8, nsHTMLTag
eHTMLTag_form, int 1, nsEntryStack * 0x00000000) line 3439 + 12 bytes
CNavDTD::HandleDefaultStartToken(CToken * 0x03a89de0, nsHTMLTag eHTMLTag_form,
nsCParserNode * 0x0388fef8) line 1322 + 20 bytes
CNavDTD::HandleStartToken(CToken * 0x03a89de0) line 1735 + 22 bytes
CNavDTD::HandleToken...
it seems that CNavDTD not always treat FORM as leaf element.
>when I debug CNavDTD, it shows that it treat <form> as container,
How did you find this out? Note: Form tags are never pushed into the dtd stack.
>it seems that CNavDTD not always treat FORM as leaf element.
No...it's always treated as a leaf.
In my comments, I have posted stack trace of my debug when meet <form>.
you see, if CNavDTD treat it as leaf, in the function of
CNavDTD::HandleDefaultStartToken(), it will call AddLeaf(),
but in fact, it call OpenContainer(),so I got that kind of thought.
Am I wrong?
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
Priority: -- → P4
Target Milestone: mozilla1.0.1 → Future
|
||
Updated•20 years ago
|
Assignee: harishd → mrbkap
Status: ASSIGNED → NEW
|
|
||
Comment 6•19 years ago
|
||
This is needed to fix bug 328930 more sanely. I'm going to propose that given:
<form><p></form>foo
"foo" will not be a child of the <p> since that's what IE does.
Blocks: 328930
Status: NEW → ASSIGNED
OS: Windows 2000 → All
Priority: P4 → P3
QA Contact: moied → parser
Hardware: PC → All
Target Milestone: Future → mozilla1.9alpha
|
|
||
Updated•15 years ago
|
Assignee: mrbkap → nobody
While this isn't fixed per se, the HTML5 parser makes the mechanism proposed in the title of this bug irrelevant and fixes the problem from comment 6 by other means.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
You need to log in
before you can comment on or make changes to this bug.
Description
•