VERIFIED FIXED Bug 3526
improve support for dynamically added <script> elements
https://bugs.webkit.org/show_bug.cgi?id=3526
Summary improve support for dynamically added <script> elements
Sjoerd Mulder
Reported 2005-06-14 06:37:25 PDT
When creating a script-element with document.createElement and inserting this element into the DOM, the attached script is not executed or not loaded at all. This has been tested on IE6, Firefox 1.0.4 and Opera 8, these browsers all work. Tested Safari version: 1.3(v312). Testcase is provided at URL
Attachments
Fix (5.79 KB, patch)
2005-06-15 09:20 PDT, Anders Carlsson
darin: review-
Another test case (4.13 KB, text/html)
2005-06-16 11:40 PDT, Anders Carlsson
no flags
Better patch (6.31 KB, patch)
2005-06-16 13:12 PDT, Anders Carlsson
darin: review+
Better patch (6.29 KB, patch)
2005-06-16 14:58 PDT, Anders Carlsson
darin: review+
Compilable patch (6.28 KB, patch)
2005-06-16 15:05 PDT, Anders Carlsson
darin: review+
Support setting title.text (7.47 KB, patch)
2005-06-16 15:13 PDT, Anders Carlsson
mjs: review-
Chris Petersen
Comment 1 2005-06-14 13:06:13 PDT
Interesting results: With Safari 2.0 (v412): All tests fail With TOT Webkit under 10.4.1 (8B15): Tests 1 - 3 pass but tests 4- 6 fail With Mac Firefox 1.0.4: All tests pass.
Anders Carlsson
Comment 2 2005-06-15 09:20:08 PDT
Created attachment 2365 [details] Fix Here's a patch that makes the test cases pass and also adds getters and setters for the text property.
Darin Adler
Comment 3 2005-06-16 09:51:21 PDT
Comment on attachment 2365 [details] Fix This patch looks pretty good. I have a few comments: 1) The !scriptString.isEmpty() check needs a comment. Anders explained to me why it's needed, and the code needs that explanation too. 2) The code needs formatting fixes; there are function declarations with extra spaces before and after ) and ( characters. There are also commas that don't have commas after them. 3) I'd like to understand why the insertBefore and appendChild methods look at the exceptioncode and newChild rather than looking at the result. Perhaps an "if (result)" is a better check? 4) Is there a good reason this can't be done inside the childrenChanged() function instead of individually overriding insertBefore and appendChild? Can we enhance childrenChanged() so it can be used? I'm not entirely comfortable with the precedent of overriding both of these functions. 5) I believe HTMLScriptElementImpl::setText could be implemented better by using removeChildren(). 6) The URL parameter to evaluateScript should be a const QString &, rather than QString. Looks like this is on the right track, although I still don't fully understand the rules for when the script should be run and re-run.
Niels Leenheer (HTML5test)
Comment 4 2005-06-16 11:08:35 PDT
5) I also implemented an alternative for this function for bug 3501, which does use removeChildren() and is also for HTML by simply reusing of a pre-existing text node. http://bugzilla.opendarwin.org/attachment.cgi?id=2368
Anders Carlsson
Comment 5 2005-06-16 11:40:54 PDT
Created attachment 2392 [details] Another test case Here's a test case with a couple of different test cases. WinIE does not allow adding children to the script node, only .text and .innerText works there, all tests pass on Mozilla though. I'll try to whip up a better patch that uses childrenChanged.
Anders Carlsson
Comment 6 2005-06-16 13:12:27 PDT
Created attachment 2397 [details] Better patch Here's a new patch that addresses the comments. I tried the previously attached test case in Opera and it always re-ran the script when the children changed. This patch still does what Mozilla and WinIE does, but it doesn't allow you to evaluate a script by appending a child node to a script node that's already in the document.
Darin Adler
Comment 7 2005-06-16 14:40:09 PDT
Comment on attachment 2397 [details] Better patch I think this is good. Two ideas to make it even better: 1) Put the NodeImpl *n declaration inside the for statement in HTMLScriptElementImpl::text. 2) HTMLScriptElementImpl::childrenChanged could check firstChild() instead of childNodeCount(), since that's faster (maybe we should have a hasChildren()). 3) HTMLScriptElementImpl::setText should do isTextNode instead of nodeType() == TEXT_NODE. Otherwise, super-great! (I also mentioned to Anders on IRC that we need this text/setText change for title elements.) r=me
Anders Carlsson
Comment 8 2005-06-16 14:58:13 PDT
Created attachment 2403 [details] Better patch Here's a new patch that addresses the issues in the previous comment.
Anders Carlsson
Comment 9 2005-06-16 15:05:21 PDT
Created attachment 2404 [details] Compilable patch And here's a version that actually compiles.
Darin Adler
Comment 10 2005-06-16 15:07:02 PDT
Comment on attachment 2403 [details] Better patch This won't compile. It's ->isTextNode(), not nodeType()->isTextNode(). But I'm saying r=me anyway. Just make sure whatever we check in does compile.
Anders Carlsson
Comment 11 2005-06-16 15:13:08 PDT
Created attachment 2405 [details] Support setting title.text Sorry to cause more bugzilla spam, but here's a patch that supports setting and getting title.text
Maciej Stachowiak
Comment 12 2005-06-16 17:50:58 PDT
Could you please make a separate patch with the title stuff (ideally with a test, if it's testable)? It makes life simpler to have one patch per issue. It also makes life easier if the test case is included in the patch in the right subdir of layout tests - not sure if you can make patches that add files against anoncvs, but if so, that would be handy.
Maciej Stachowiak
Comment 13 2005-06-16 17:52:02 PDT
Comment on attachment 2405 [details] Support setting title.text review- due to unrelated title change being included in the patch, and lack of test case for the title stuff.
Anders Carlsson
Comment 14 2005-06-17 00:30:22 PDT
I removed the obsolete flag from attachment 2404 [details] because it's the final patch but without the title attribute. I opened a separate bug, 3586, for the title change.
Darin Adler
Comment 15 2005-06-18 22:17:54 PDT
I changed the title to reflect the fact that we already had this dynamically-added <script> support in TOT. What we're doing now is updating it to work better (which basically means more like Gecko at this point).
Anders Carlsson
Comment 16 2005-06-19 23:10:22 PDT
*** Bug 3501 has been marked as a duplicate of this bug. ***
Joost de Valk (AlthA)
Comment 17 2005-07-03 08:03:41 PDT
Reporter, please mark this bug as verified if it has been fixed for you.
Sjoerd Mulder
Comment 18 2005-07-04 01:01:05 PDT
I wish i could verify the bug but, i cant compile it yet, still waiting on my new imac( now got a 500 g3 testmachine :( and no Developer Tools )
Sjoerd Mulder
Comment 19 2005-08-25 06:43:55 PDT
The adding of the scripts works well now :), but in Mozilla you can do: oScript.onload = functionCallBack; The onload event is never triggered when the script load is completed(on TOT) (by setting the src attribute) Test: function callAfterLoad(){ alert('Script Loaded'); } var oHead = document.getElementsByTagName('head')[0]; var oScript = document.createElement('script'); oScript.setAttribute('type', 'text/javascript'); oHead.appendChild(oScript); // append to head oScript.onload = callAfterLoad; oScript.setAttribute('src', 'myfiletoload.js');
Darin Adler
Comment 20 2005-08-25 09:36:28 PDT
OK, then how about a new bug? Lets not keep using a single bug report for all sorts of different related fixes.
Darin Adler
Comment 21 2005-08-25 09:37:11 PDT
In other words, please write a bug about the fact that we don't support "onload' handlers on script tags. That's separate from what was fixed here.
Sjoerd Mulder
Comment 22 2005-08-25 10:46:21 PDT
(In reply to comment #15) Sorry for my new bug, but as the title was changed i thought that this was a general bug for 'improving dynamic script adding'. The original bug is solved!
Sjoerd Mulder
Comment 23 2006-03-08 09:11:25 PST
This bug is now also In Radar <rdar://4470861>
Note You need to log in before you can comment on or make changes to this bug.