Because the tree builder does block, the parser kicks off a preload scanner. And because the preload scanner starts _inside_ the template, it's not able to make use of its m_templateCount counter to ignore resources it finds inside the scanner. This is what was causing the failure noted in bug 106810. Since the tree builder knows it's in a template, it could simply avoid queueing an scripts inside the template for processing. But that might be somewhat ugly, since it requires the tree builder to "know" that scripts are inert in templates (currently that knowledge is handled at the ScriptElement level instead, by examining the <script>'s ownerDocument).
It's possible this bug should instead be titled "HTMLPreloadScanner should be able to handle starting inside a <template>"; the title depends somewhat on how this should be fixed, which is a question I pose to our resident parser experts, eseidel and abarth.
We're in the process of removing the HTMLPreloadScanner. We shouldn't spend too much effort polishing these issues in the old design.
(Maybe that argues for fixing this issue in the tree builder?)
Created attachment 184330 [details] WIP
The WIP patch here unfortunately takes the approach of messing with the preload scanner's logic rather than trying to fix things in the tree builder. My first attempt at that (which was simply to avoid setting m_scriptToProcess when in template contents) didn't work, as the script wouldn't run later when attached to the page.
I don't think this patch landed (although code is different now): https://github.com/WebKit/WebKit/blob/e7be2359033b5a89111f70b799953e17421eeede/Source/WebCore/html/parser/HTMLDocumentParser.cpp#L291 https://github.com/WebKit/WebKit/blob/941eb3e0b2a0c171ead200aade992b31b7d84493/Source/WebCore/html/parser/HTMLTreeBuilder.h#L64 rniwa@webkit.org - Is this needed anymore? Thanks!