On Fri, 3 Feb 2012, Boris Zbarsky wrote: > On 2/3/12 3:07 PM, Ian Hickson wrote: > > > OK. I have no serious problem with a "beforeprocess" event that > > > fires before processing the response, esp. if "processing" is > > > defined in a page-visible way (so e.g. you could still compile a > > > script in the background before firing "beforeprocess"; you just > > > couldn't run it). > > > > I don't have an objection to adding a cancelable bubbling event that > > fires synchronously as part of the "execute a script block" algorithm, > > between the current steps 1 and 2 of "if the load was successful", > > which gets the URL of the script, targetted at the script, which if > > canceled cancels the execution of the script. > > > > Does any browser have an event like that already? If not, any opinions > > on an event name?<script onbeforerun="">? > > Gecko has a "beforescriptexecute" event. It's a simple event targeted > at the element; there's no reason to include the URI, since that can be > gotten off the element. I believe calling preventDefault() on it will > prevent the script from executing.
Ok, I've added that to the spec. > I also believe that we have proposed this for standardization in the > past, though it seems to have fallen through the cracks a bit... I couldn't find any mention of it in the WHATWG archives or Bugzilla, though I did find an e-mail from sicking saying he'd proposed it to the WHATWG list. :-( > But note that this is script-specific; I believe that content-blocker > use cases would want this for images, stylesheets, etc. As noted in the previous e-mail, it's not clear that the content-blocker use cases are valid. The use case that is compelling for beforescriptexecute is regarding sites who are trying to address mixed content vulnerabilities progressively and need to closer control over external script execution. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
