Bug 39891 – HTML5ScriptRunner can re-enter from event dispatch

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

HTML5ScriptRunner can re-enter from event dispatch

HTML5ScriptRunner tries to only enter scripting when calling "executeScript" on the HTML5SriptRunnerHost, but I realize after writing it that it will also re-enter from events which will cause us to hit m_scriptNestingLevel ASSERTs and do the wrong thing. :)

I tried to write a test for this, but it doesn't quite work yet, and I have more important bugs to fix in the code before I get back to this one so recording it for posterity:

1
<script>
function doubleWrite(number)
{
    document.write("<script>document.write(" + number ")</scr" + "ipt><script>document.write(" + (number+1) ")</scr" + "ipt>")
}
</script>
2
<script
onbeforeload="doubleWrite(3)"
onload="doubleWrite(5)"
src="data:text/plain,doubleWrite(7)"
></script>
9

[Eric Seidel (no email)]

Created attachment 59134 [details]
Cleaned up test case which reveals at least one ASSERT in ToT

The fix for the first assert:

ASSERTION FAILED: !haveParsingBlockingScript()
(/Projects/WebKit/WebCore/html/HTML5ScriptRunner.cpp:262 void WebCore::HTML5ScriptRunner::runScript(WebCore::Element*, int))

is to just re-order the setting of m_parsingBlockingScript until after the beforeLoad check, since the before load might cancel the script anyway!

The next assertions you hit, of close m_source, relate to the insertion point never getting set for some of these calls.  Those need a bit more thought.

[Eric Seidel (no email)]

http://code.google.com/p/chromium/issues/detail?id=47080
is probably caused by this issue.

[Eric Seidel (no email)]

As of http://trac.webkit.org/changeset/61610 we believe this issue to be completely resolved.  Adam is also mailing the W3c about Minefield's behavior discrepancy.

[Eric Seidel (no email)]

http://trac.webkit.org/changeset/61606
http://trac.webkit.org/changeset/61607
http://trac.webkit.org/changeset/61608
were all related to this fix, btw.