- From: milakam <milakam@eclipso.de>
- Date: Tue, 22 Jul 2014 13:46:50 +0200
- To: whatwg@whatwg.org
> On 7/21/14, 1:21 PM, Boris Zbarsky wrote: >> That said, Chrome's behavior is not useful for your purposes for >> script-inserted scripts, since those do "prepare a script" before the >> mutation observer fires... > > And for parser-created scripts I expect Chrome doesn't prevent the > preload, but haven't tested that. Thanks, your're right document.write triggers also "evil.js". But my user JS is dead anyway (cannot publish it while violating the spec and only partially filtering / blocking). >> This doesn't sound too bad "Safari 5.0 and later (and other WebKit-based >> browsers) generates a "beforeload" event before loading each subresource >> belonging to a webpage. The "beforeload" event is generated before >> loading every script, iframe, image, or style sheet specified in the >> webpage, for example." from >> https://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/MessagesandProxies/MessagesandProxies.html#//apple_ref/doc/uid/TP40009977-CH14-SW9 >> >> >> Anyone knows why this never made it into the spec? > > How would this interact with a preload scanner, exactly? Guess it could be similar to the beforescriptexecute / onload implementation from https://www.w3.org/Bugs/Public/show_bug.cgi?id=9984#c6 and http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034629.html 1) the parser gets unblocked. 2) scriptwillexecute fires. 3) insertion point becomes non-undefined 4) the document becomes aware of an external script being evaluated (for write-neutralization) if applicable 5) the insertion point becomes the right point for this script 6) the script is evaluated! 7) the insertion point stops being the right point for this script 8) the document becomes unaware of an external script being evaluated 9) the insertion point potentially becomes undefined 10) scriptdidexecute fires 11) load (for external scripts) fires
Received on Tuesday, 22 July 2014 11:47:25 UTC