Closed
Bug 283036
Opened 19 years ago
Closed 19 years ago
Select rendered when dynamically creating option tag with innerHTML
Categories
(Core :: DOM: HTML Parser, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.8beta2
People
(Reporter: martijn.martijn, Assigned: mrbkap)
References
Details
(Keywords: regression, testcase)
Attachments
(4 files)
514 bytes,
text/html
|
Details | |
3.18 KB,
image/gif
|
Details | |
637 bytes,
application/xhtml+xml
|
Details | |
3.19 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
See upcoming testcase. I'll also attach an image of the bug. This seems to have regressed. It's working in the 2005-02-18 builds, but it's not working well anymore in the 2005-02-19 builds: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-02-18+06%3A00%3A00&maxdate=2005-02-19+07%3A00%3A00&cvsroot=%2Fcvsroot
Reporter | ||
Comment 1•19 years ago
|
||
To trigger the bug: -Click on the "doe" button -Open the select drop-down Afterwards, you should two options in the drop-down menu: "scroll" and "visible". You should not see a new select drop-down in the already existing drop-down menu.
Reporter | ||
Comment 2•19 years ago
|
||
When I use document.body.appendChild(toggle_div) instead of document.documentElement.appendChild(toggle_div), I don't get this bug.
Assignee | ||
Comment 4•19 years ago
|
||
What's happening is that by appending the <div> to the documentElement (namely, <html>) instead of the body, we're trying to append <div> with a context stack of <html>. When we parse the context, however, the <div> gets pushed onto the misplaced stack because no body was open. Then we inform the fragment sink that we're processing the actual content, but the <div> hasn't made it to the fragment sink. The result is that the outmost token (in this case, the <div>) gets duplicated and bad things happen. I'm open to suggestions (<endnote> may have to come back for HTML )-:).
Assignee | ||
Comment 5•19 years ago
|
||
*** Bug 282870 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 6•19 years ago
|
||
Probably http://www.google.com/webhp?complete=1&hl=en is showing the same bug, not? Mentioned at: http://forums.mozillazine.org/viewtopic.php?t=222705&start=30#1252553 It has the same regression dates.
Assignee | ||
Comment 7•19 years ago
|
||
Taking. I'll have a patch tomorrow. Also bumping severity, since this breaks .innerHTML in HTML on nodes that aren't already in the document (this is probably why Google suggest breaks).
Assignee: nobody → mrbkap
Severity: normal → major
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Comment 8•19 years ago
|
||
Interestingly, the testcase doesn't seem to fail in XML.
Updated•19 years ago
|
Attachment #175158 -
Attachment mime type: application/octet-stream → application/xhtml+xml
Comment 9•19 years ago
|
||
XML doesn't buffer up tokens in the DTD (in fact, doesn't really have a DTD).
Assignee | ||
Comment 10•19 years ago
|
||
The only change that's required for this bug is the nsParser.cpp change. That makes sure that the context flags get flushed out of the DTD (note: the DTD is perfectly happy to open tags that should belong in the head in the body, but not vice versa). The changes in nsHTMLFragmentSink make us not lose a <body> tag in the new content (Boris, this fixes the document.documentElement = document.documentElement problem). This change isn't strictly necessary to fix this bug, however.
Attachment #175235 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•19 years ago
|
Attachment #175235 -
Attachment description: patc → patch v1
Comment 11•19 years ago
|
||
Comment on attachment 175235 [details] [diff] [review] patch v1 r+sr=bzbarsky
Attachment #175235 -
Flags: superreview+
Attachment #175235 -
Flags: review?(bzbarsky)
Attachment #175235 -
Flags: review+
Assignee | ||
Comment 12•19 years ago
|
||
I left the nsHTMLFragmentContentSink.cpp changes out of the checkin for this bug because since they weren't quite ready. The nsParser.cpp changes were the only ones required, however, so this should be FIXED.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•19 years ago
|
Component: Layout: Form Controls → HTML: Parser
Target Milestone: --- → mozilla1.8beta2
Reporter | ||
Updated•19 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•