Re: [whatwg] Should script run if it comes from a HTML fragment?
On Thu, 10 Feb 2011, Henri Sivonen wrote: * innerHTML doesn't run scripts and they are inserted disabled. FWIW, here's a counter-example: http://www.oele.net/innerhtmljs2.html The above runs the script in all browsers except Firefox 4 (which follows the spec). The pattern is reportedly from the http://crossbrowserajax.com/ library. However, http://www.oele.net/innerhtmljs.html doesn't run in IE9 PP7. I'm not thrilled about adding code to support this quirky pattern at this point of the release cycle (evang is being attempted), but I thought I'd mention this finding even though I'm not asking for a spec change (at least not yet). Wow. That difference is absurd. Since Gecko and WebKit both do what the spec says now, I've left the spec as is. I don't even know where I'd begin in terms of doing what IE does here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should script run if it comes from a HTML fragment?
* innerHTML doesn't run scripts and they are inserted disabled. FWIW, here's a counter-example: http://www.oele.net/innerhtmljs2.html The above runs the script in all browsers except Firefox 4 (which follows the spec). The pattern is reportedly from the http://crossbrowserajax.com/ library. However, http://www.oele.net/innerhtmljs.html doesn't run in IE9 PP7. I'm not thrilled about adding code to support this quirky pattern at this point of the release cycle (evang is being attempted), but I thought I'd mention this finding even though I'm not asking for a spec change (at least not yet). -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Should script run if it comes from a HTML fragment?
On Thu, 11 Nov 2010, Ryosuke Niwa wrote: I'm working on the WebKit bug 12234 - Using createContextualFragment to insert a script does not cause the script to execute https://bugs.webkit.org/show_bug.cgi?id=12234. [...] This thread pretty much resolved itself, but for the record: * createContextualFragment() is here: http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment ...and re-enables scripts before returning them; the parser doesn't execute them synchronously. * innerHTML doesn't run scripts and they are inserted disabled. On Sat, 13 Nov 2010, Henri Sivonen wrote: Hixie wrote the relevant part of the spec without taking createContextualFragment into account, so you shouldn't read too much into what the spec says now. Similar overlooking a part of the platform when considering the interactions has occurred a couple of time with how HTML5 integrates with XSLT, too. Indeed. I am not omniscient. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Should script run if it comes from a HTML fragment?
After reading all the responses and consulting with several developers at
Google and other WebKit contributors, I have reached the conclusion that we
should fix this bug, and the script parsed by createContextualFragment
should, indeed, run when the fragment is inserted into a document.
I'll follow up when the bug is fixed and WebKit's behavior is matched that
of Firefox.
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
On Thu, Nov 11, 2010 at 4:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
Greetings all,
I'm working on the WebKit bug 12234 - Using createContextualFragment to
insert a script does not cause the script to
executehttps://bugs.webkit.org/show_bug.cgi?id=12234.
While investigating the issue, the following part of HTML5 spec came to my
attention:
*10.2.5.7 The in head insertion
modehttp://www.whatwg.org/specs/web-apps/current-work/#parsing-main-inhead
*
...
- *A start tag whose tag name is script*
1. If the parser was originally created for the HTML fragment parsing
algorithm, then mark the script element as already started. (fragment
case)
Since 10.4 Parsing HTML
fragmentshttp://www.whatwg.org/specs/web-apps/current-work/#fragment-casedoes
not special case the script element, this seem to imply that we never
execute scripts inserted by the HTML fragment parsing algorithm. Am I
right?
To give you more concrete example, should the following markup show the
alert or not?
!DOCTYPE html
html
script
document.body.innerHTML+=scr+iptalert('SUCCESS')/scr+ipt;
/script
/html
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
Re: [whatwg] Should script run if it comes from a HTML fragment?
On Sat, Nov 13, 2010 at 6:14 AM, Ms2ger ms2...@gmail.com wrote: Ms2ger wrote: Ryosuke Niwa wrote: On Fri, Nov 12, 2010 at 2:29 PM, Jonas Sicking jo...@sicking.cc wrote: 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. However, this request has not been granted yet. The specification [1] now states: Mark all scripts in /new children/ as already started. This should have said Unmark. Unfortunately, this update hasn't propagated to html5.org yet, but please take this (unmarked, to be executed) as the current status. Apologies for any confusion caused. For what it's worth, IMHO unmark X as 'foo' is a pretty confusing construct. It'd might be a bit clearer to say: Unset the already started flag on all scripts in /new children/. and maybe even add an informative note as to what the effect of this is (that scripts can execute if later inserted into a document). / Jonas
Re: [whatwg] Should script run if it comes from a HTML fragment?
On Nov 13, 2010, at 00:54, Ryosuke Niwa wrote: On Fri, Nov 12, 2010 at 2:29 PM, Jonas Sicking jo...@sicking.cc wrote: 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. However, this request has not been granted yet. Hixie wrote the relevant part of the spec without taking createContextualFragment into account, so you shouldn't read too much into what the spec says now. Similar overlooking a part of the platform when considering the interactions has occurred a couple of time with how HTML5 integrates with XSLT, too. 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. OK. Thanks for clarification. The fix landed after beta 7, so it's in the nightlies but not in any beta so far. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Should script run if it comes from a HTML fragment?
Ryosuke Niwa wrote: On Fri, Nov 12, 2010 at 2:29 PM, Jonas Sicking jo...@sicking.cc wrote: 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. However, this request has not been granted yet. The specification [1] now states: Mark all scripts in /new children/ as already started. I hope this clarifies my intention. Ms2ger [1] http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment
Re: [whatwg] Should script run if it comes from a HTML fragment?
On Thu, Nov 11, 2010 at 5:48 PM, Jonas Sicking jo...@sicking.cc wrote: When setting .innerHTML browsers always have prevented any created scripts 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 += bwhat'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 hsivo...@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
Re: [whatwg] Should script run if it comes from a HTML fragment?
On Fri, Nov 12, 2010 at 12:48 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Nov 11, 2010 at 5:48 PM, Jonas Sicking jo...@sicking.cc wrote: When setting .innerHTML browsers always have prevented any created scripts 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 += bwhat'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 hsivo...@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
Re: [whatwg] Should script run if it comes from a HTML fragment?
On Fri, Nov 12, 2010 at 2:54 PM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Nov 12, 2010 at 2:29 PM, Jonas Sicking jo...@sicking.cc wrote: 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. However, this request has not been granted yet. I'm not sure what your argument is? This is just an editorial matter, createContextualFragment can always be defined to behave whatever way we deem is appropriate no matter what. And more importantly, the biggest input to the spec will be what implementations do, not the other way around. * 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. innerHTML and createContexualFragment both use the HTML fragment parsing algorithm. If you had implemented these features as described in the spec, there should be no differences. Again, a spec for createContexualFragment didn't exist until recently. And it certainly didn't exist close to a decade ago when it was invented at Netscape. Same thing for innerHTML when it was invented at microsoft. The spec really isn't a source of authority here, reality is. I think discussions about specs as a source of authority here is a red herring. My concern is that treating script elements in a fragment differently based on whether the fragment was added by innerHTML or createContextualFragment is confusing to the developers. I would, if I was a developer. You could also argue that it's confusing that createElement and XSLTProcessor.transformToFragment creates fragments where scripts do execute, but createContextualFragment doesn't. If developers wanted to load a script file, they can explicitly load the file and use eval, no? I'd rather argue that they wouldn't put a script in their fragment if they wanted it to do nothing. / Jonas
Re: [whatwg] Should script run if it comes from a HTML fragment?
On Thu, Nov 11, 2010 at 4:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
Greetings all,
I'm working on the WebKit bug 12234 - Using createContextualFragment to
insert a script does not cause the script to execute. While investigating
the issue, the following part of HTML5 spec came to my attention:
10.2.5.7 The in head insertion mode
...
A start tag whose tag name is script
If the parser was originally created for the HTML fragment parsing
algorithm, then mark the script element as already started. (fragment
case)
Since 10.4 Parsing HTML fragments does not special case the script element,
this seem to imply that we never execute scripts inserted by the HTML
fragment parsing algorithm. Am I right?
To give you more concrete example, should the following markup show the
alert or not?
!DOCTYPE html
html
script
document.body.innerHTML+=scr+iptalert('SUCCESS')/scr+ipt;
/script
/html
When setting .innerHTML browsers always have prevented any created
scripts 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 += bwhat'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.
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).
First off, there is no spec for createContextualFragment so there is
no spec text to turn to.
Second, there are a few reasons to keep scripts created using
createContextualFragment executable:
* Firefox has always left scripts created using
createContextualFragment as executable. So web compatibility would
speak for making the scripts executable.
* Other APIs that create fragments of content, such as the
XSLTProcessor.transformToFragment and createElement, create scripts
that are executable.
* 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.
* Since the API isn't a property, there is no possibility that people
will use the += operator to create confusion. It is still possible to
do something like range.createContextualFragment(a.innerHTML), but
arguably it's more likely that they'll use innerHTML all the way
instead.
* Since scripts don't execute synchronously from within
createContextualFragment the caller doesn't have to deal with weird
reentrancy issues during parsing.
For these reasons we decided to keep Firefox 4 behaving like previous
versions of firefox and allow scripts created using
createContextualFragment to execute.
/ Jonas
Re: [whatwg] Should script run if it comes from a HTML fragment?
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 See also: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11191 -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
