See upcoming tetscase. I can't access properties, methods and so from xbl bounds elements generated from innerHMTL. I can access them when generated from a regular dom method (appendChild).

In the testcase, click on the "add xbl spans" button. I would expect that the result for all the three tests be "true" with a green background-color. The "alert(span.thing)" button should alert 3 times 'true'.

I bet the problem is that we disable script execution on the script context while setting innerHTML so that <script> nodes in it don't execute... Perhaps we should just disable the scriptloader, not disable script in general?

Why do we do that? <script>s generated through .innerHTML should execute no?

See bug 214874 for why <script>s generated through .innerHTML should not execute.

Bug 116834 is what initially introduced the innerHTML not running scripts thing. jst, was there a reason for disabling scripts on the context there instead of just disabling the script loader? I guess the loader disabling is not a counter, but neither is the script context thing... Oh, and the surroundContents behavior on that testcase is somewhat correct, per spec -- the new node is inserted first, then the kids its surrounding are inserted; the constructor fires when there are no child nodes. So I would expect to see the text we see, though I'm not sure yet why the background is red.

Actually, the surroundContents behavior is completely correct -- that constructor throws an exception, as it should. I've filed bug 299741 on the exception not making it to the JS console in a timely manner.

Comment on attachment 188328 [details] [diff] [review] Proposed fix I'm still not convinced that disabling scripts in .innerHTML is the right thing to do. But this is not the bug for that debate.

Comment on attachment 188328 [details] [diff] [review] Proposed fix Requesting 1.8b4 approval to allow XBL attached to nodes created via innerHTML to run its constructor.

Fixed.