Open
Bug 672775
Opened 13 years ago
Updated 4 years ago
Invoking the fragment parsing algorithm with an RCDATA context node should leave the appropriate end tag as undefined
Categories
(Core :: DOM: HTML Parser, defect, P5)
Core
DOM: HTML Parser
Tracking
()
NEW
People
(Reporter: hsivonen, Unassigned)
References
()
Details
See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1084
The substring "</title>" is lost in Gecko but not in Ragnarök or Chrome. The fragment parsing algorithm steps in the spec don't have a step for setting the appropriate end tag, so the parser in Gecko shouldn't be setting it.
|
||
Comment 1•8 years ago
|
||
I make test for all elements listed for HTML fragment parsing (https://html.spec.whatwg.org/multipage/syntax.html#html-fragment-parsing-algorithm):
<html>
<script>
var elements = ["title", "textarea", "style", "xmp", "iframe", "noembed", "noframes", "script", "noscript", "plaintext"];
elements.forEach(function(localName){
var el = document.createElement(localName);
el.innerHTML = "foo&barä<tag></endtag> But the <\/" + localName + "> end tag disappears.";
console.log(localName + ": " + el.textContent);
});
</script>
</html>
And results:
Firefox is wrong for title, textarea, xmp, iframe, noembed, noframes, noscript
Blink/Edge/IE11/Presto are correct for all
|
||
Comment 2•4 years ago
|
||
Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.
If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.
Severity: normal → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•