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

Ryosuke Niwa rniwa at webkit.org
Fri Nov 12 12:48:07 PST 2010

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.

* 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.

> * 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.

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

- Ryosuke Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101112/ba9c74b7/attachment-0002.htm>

More information about the whatwg mailing list