User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090717 Minefield/3.6a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090717 Minefield/3.6a1pre Details Reproducible: Always Steps to Reproduce: 1.about:config set HTML5 to true 2.close Minefield and go to SafeMode 3.open up webpage http://www.aerosnap.de.vu/ Actual Results: Page was Blank - White - Empty Expected Results: Webpage should had been shown even in HTML5 enabled Safemode should had disregard non-default value HTML5 - True to False Using Windows 7 and Official Minefield Build 20090718

Confirming and setting new: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090717 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090717120342 <latest hourly available

It's actually the frame http://aerosnap.de/ that incorrectly shows up blank.

Blank only with HTML5 parser enabled.

See also bug 503632. Based on the direction that discussion is going, I'm not marking this as a dup.

I don't see a way to fix this without reparsing. If the problem is rare, I think WONTFIX plus evang is the right solution. If the problem is common, we have a serious issue with a fundamental design constraint of the spec.

What design constraint is that? Why does <!-- inside <script> need to be treated as anything at all?

<!-- needs magic treatment inside script to mask document.write("</script>"); <script><!-- ... document.write("<script src='foo'></script>"); ... --></script> The design constraint I meant was the constraint not to do reparsing, because reparsing would change the executability characteristics of pieces of the page if an attacker can force a premature end of file.

Note to people who are searching for dupes before filing bugs: If you see this in the wild, please note the URL of the page here.

Interesting! I guess strings in scripts must have "<!--", "-->", and "</script" escaped to avoid XSS, depending on whether the script already has a "<!--" and the browser version. I used to think escaping "/" as "\/" and escaping the string delimiter was enough. I like the no-reparsing constraint, though.

I wrote up a relatively radical proposal for a fix: http://wiki.whatwg.org/wiki/CDATA_Escapes