Closed Bug 283036 Opened 20 years ago Closed 20 years ago

Select rendered when dynamically creating option tag with innerHTML

Categories

(Core :: DOM: HTML Parser, defect)

x86
All
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.8beta2

People

(Reporter: martijn.martijn, Assigned: mrbkap)

References

Details

(Keywords: regression, testcase)

Attachments

(4 files)

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
Attached file Testcase
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.
When I use document.body.appendChild(toggle_div) instead of
document.documentElement.appendChild(toggle_div), I don't get this bug.
This was caused by bug 263053.
Blocks: 263053
OS: Windows 2000 → All
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 )-:).
*** Bug 282870 has been marked as a duplicate of this bug. ***
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.
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
Status: NEW → ASSIGNED
Interestingly, the testcase doesn't seem to fail in XML.
Attachment #175158 - Attachment mime type: application/octet-stream → application/xhtml+xml
XML doesn't buffer up tokens in the DTD (in fact, doesn't really have a DTD).
Attached patch patch v1Splinter Review
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)
Attachment #175235 - Attachment description: patc → patch v1
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+
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: 20 years ago
Resolution: --- → FIXED
Component: Layout: Form Controls → HTML: Parser
Target Milestone: --- → mozilla1.8beta2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: