[whatwg] Should script run if it comes from a HTML fragment?

[Jonas Sicking]

On Fri, Nov 12, 2010 at 12:48 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Thu, Nov 11, 2010 at 5:48 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> When setting .innerHTML browsers always have prevented any created
>> <script>s from running. We ended up copying this behavior from IE when
>> we originally implemented .innerHTML in firefox (then netscape) since
>> sites were relying on it.
>>
>> In particular sites were doing things like
>>
>> a.innerHTML = b.innerHTML;
>> and
>> a.innerHTML += "<b>what's up dog</b>";  (btw, perf-wise this is
>> terrible, but people do do it).
>>
>> and in both cases fell over when scripts in a "re-executed". So your
>> example above should not alert if you want your browser to be
>> compatible with the web.
>
> Ok, so we agree on this case.
>>
>> For range.createContextualFragment things are different though. (The
>> function returns a fragment, and so its obvious that script should
>> never execute *during* exeuction of createContextualFragment, the
>> question is if they should execute if that fragment is later inserted
>> in a document).
>
> I don't think we should execute either.  Why should we treat fragments
> created by createContextualFragment differently from fragments created by
> innerHTML?  That sounds arbitrary and confusing.
>>
>> First off, there is no spec for createContextualFragment so there is
>> no spec text to turn to.
>
> On Thu, Nov 11, 2010 at 10:22 PM, Henri Sivonen <hsivonen at iki.fi> wrote:
>>
>> > First off, there is no spec for createContextualFragment so there is
>> > no spec text to turn to.
>>
>> There is now:
>> http://html5.org/specs/dom-parsing.html#extensions-to-the-range-interface
>
> According to the part of spec Heri referenced, we should NOT run scripts in
> a fragment created by createContextualFragment either because we invoke the
> same HTML fragment parsing algorithm, which sets "already started" flag
> before inserting the script element into the document.

You looking at only part of what Henri said. He also pointed to

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11191

which is a request to change HTML5 so that createContextualFragment
can specify that scripts should remain executable.

>> * Firefox has always left scripts created using
>> createContextualFragment as executable. So web compatibility would
>>
>> speak for making the scripts executable.
>
> Opera seems to execute scripts created by createContexualFragment as well.
>>
>> * It seems somewhat weird to single out script elements as being the
>> only ones to receive special treatment by disabling them. Things like
>> onclick attributes are still enabled.
>
> But we already do this for innerHTML.  I don't think it's weird to single
> out script elements given the security implications.

Security isn't affected by this. It's always hazardous to use
innerHTML, createContextualFragment, createElement,
XSLTProcessor.transformToFragment etc to build content and insert into
your DOM due to onfoo attributes.

>> * Since scripts don't execute synchronously from within
>> createContextualFragment the caller doesn't have to deal with weird
>> reentrancy issues during parsing.
>
> Sure but that means we have to special-case fragments created
> by createContexualFragment.  That adds extra complexity to the HTML fragment
> parsing algorithm.

I'd prefer to single out scripts only in one API than in multiple ones.

>> For these reasons we decided to keep Firefox 4 behaving like previous
>> versions of firefox and allow scripts created using
>> createContextualFragment to execute.
>
> However, Firefox 4.0 Beta 6 does not execute the script as far as I tested.
>  Try opening http://dscoder.com/MessageStyle/testcase.html

That's old code at this point. And it resulted in people filing bugs
on us. I forget if we fixed it for beta7 or not, but if you try recent
nightlies it should work there.

/ Jonas