Closed Bug 18843 Opened 26 years ago Closed 24 years ago

dynamically added SCRIPT not executable

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: martin.honnen, Assigned: vidur)

References

(
URL
)

Details

(Keywords: dom1, relnote, testcase, Whiteboard: relnote-devel DIGBug)

Attachments

(7 files)

bug demo (press insert as script then f1()/God to check script execution
1.08 KB, text/html
Details
Load script defer via innerHTML
1.14 KB, text/html
Details
example of how to make a |nsCommonString| from a buffer into which you have done an i18n translation
1.17 KB, text/plain
Details
fixes in content
89.52 KB, patch
Details | Diff | Splinter Review
fixes in string
386 bytes, patch
Details | Diff | Splinter Review
content patch v1.1
89.28 KB, patch
Details | Diff | Splinter Review
string patch (the previous one was incomplete)
2.76 KB, patch
Details | Diff | Splinter Review
When I have added a SCRIPT element it shows up in the DOM but the inserted javascript is not defined. Press the insert as script button then the other buttons to check the variable and to try to execute the function. <HTML> <HEAD> <TITLE> some test </TITLE> <SCRIPT> function addScript (js) { var head = document.getElementsByTagName('HEAD')[0]; var script = document.createElement('SCRIPT'); script.setAttribute('DEFER', 'true'); var cont = document.createTextNode (js); script.appendChild(cont); head.appendChild(script); alert(head.lastChild.firstChild.nodeValue); } </SCRIPT> </HEAD> <BODY> <FORM> <TEXTAREA NAME="script" ROWS="5" COLS="60" WRAP="soft"> function f1 () { alert('Kibology'); } var God = 'Kibo'; </TEXTAREA> <BR> <INPUT TYPE="button" VALUE="insert as SCRIPT" ONCLICK="addScript(this.form.script.value);" > <BR> <TEXTAREA NAME="exec" ROWS="5" COLS="60" WRAP="soft"> f1(); </TEXTAREA> <BR> <INPUT TYPE="button" VALUE="eval script" ONCLICK="eval(this.form.exec.value);" > <INPUT TYPE="BUTTON" VALUE="f1" ONCLICK="f1();" > <INPUT TYPE="BUTTON" VALUE="God" ONCLICK="alert(God);" > <INPUT TYPE="button" VALUE="# SCRIPTs" ONCLICK="alert(document.getElementsByTagName('SCRIPT').length);" > </FORM> </BODY> </HTML>
Whiteboard: [MAKINGTEST]puttmann@netprojects.de
Whiteboard: [MAKINGTEST]puttmann@netprojects.de → [TESTCASE]puttmann@netprojects.de
<HTML> <HEAD> <TITLE> some test </TITLE> <SCRIPT type="text/javascript"> function addScript() { var head = document.getElementsByTagName('HEAD')[0]; var script = document.createElement('SCRIPT'); script.setAttribute('type', 'text/javascript'); var cont = document.createTextNode('function f1(){alert("works!");}'); script.appendChild(cont); head.appendChild(script); } addScript(); </SCRIPT> </HEAD> <BODY> <p onClick="f1();">call added Function</p> </BODY> </HTML>
QA Contact: gerardok → ckritzer
In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.
I'm not completely convinced that a dynamically added SCRIPT element should execute. The only case where it make sense to dynamically add an inline SCRIPT element is within an editor (for a web script, one could just do an eval). There may be a case for executing scripts defined by SCRIPT elements with a SRC attribute - there is no other way for a web script to dynamically execute scripts in an external file. Brendan, any thoughts?
Oops. Brendan, see previous comment.
If you reckon that document.write("<script ...>...<\/script>") should work with and without a src= attribute (and it does in 4.x, I believe, although it was variously busted, esp. with src=, in 3.x), then I think DOM level 1 creation of script content should work the same. At first, I thought I agreed about the src= case: it makes sense to execute the script tag, by loading the url and evaluating its content. So that made me want the case without src= to execute too. Then, to help editors add scripts without executing them, we'd need some DOM method or parameter to say "just add this, don't execute it". But now I'm wondering: what happens when you insert an image or other element bearing a src= attribute with the DOM -- does the image get fetched? And what kind of options might there be for suppressing script execution (or image src= loading when inserting an image element, for that matter)? As you say, for inline scripts, one can use JS's eval() function to get almost the same effect. Some day, we may have a load() method by which JS could also express what script src= does (see bug 14949). So now I'm less moved by the appeal to completeness -- that we want DOM insertion of a script src= element to cause a script load and eval, because there's no other way to get that effect, and no other obvious use to such a DOM operation apart from the editor case, which we do care about -- i.e., where an editor written using the DOM wants to insert, but not evaluate, a script tag. IOW, if we had load() as well as eval() in JS, wouldn't we want the DOM insert operation for script tags to work the way an editor wants it to, and the way it works today: not load and/or eval the script? But again, what does a DOM insert operation for an image src= element do? Symmetry may break here. /be
This bug will have a heavy impact on "web applications" which dynamically load javascript components from .js files after the document has loaded. In particular, it has crippled my SWAT library (of re-usable GUI elements, see http://www.joehewitt.com/swat) which attempts to do a document.writeln('<script src="blah.js"></script>'). In IE4/5 and NS4 this causes the js file to load and execute, which is the desired result. Under mozilla this fails. Somehow there must be a mechanism for loading javascript files dynamically.
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Yes, the ability to download and execute scripts after the document has finished loading is absolutely essential for applications developers. I think Brendan's option to suppress script or image fetching is the best solution. But, if you decide that you don't like it, then here's another possibility: Dynamically added <SCRIPT> elements could be downloaded and parsed but *not* executed. This is acceptable to applications developers (who are the main users of <SCRIPT SRC=> elements) because they simply have to wrap their code in a function (good practice anyway), and then call that function when the element's 'load' event fires (an 'error' event similar to the IMG element's would also be useful). This behaviour should also be acceptable for the editor. The minor restriction being that it might not be wise to enable editing of the element's onload handler. (I guess this is why DOM2 doesn't seem to specify a 'load' event for the IMG element?)
nominating for nsbeta2 based on: - visibility - feature (DOM Level 1 Standards Compliance) broken
Keywords: nsbeta2
This is still a bug on: - MacOS9 2000-04-27-08-M16 Commercial Build - Linux6 2000-04-27-09-M16 Commercial Build - Win98 2000-04-27-09-M16 Commercial Build
Putting on [nsbeta2-] radar.
Whiteboard: [TESTCASE]puttmann@netprojects.de → [nsbeta2-][TESTCASE]puttmann@netprojects.de
M16 has been out for a while now, these bugs target milestones need to be updated.
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
OS: Windows 95 → All
Hardware: PC → All
Target Milestone: M16 → Future
Marking relnote. Is there any alternative means by which developers such as Joe can get their libraries to work?
Keywords: relnote
Mass update of qa contact
QA Contact: ckritzer → janc
Whiteboard: [nsbeta2-][TESTCASE]puttmann@netprojects.de → [nsbeta2-] relnote-devel
I believe the script defer attribute defined in HTML 4.0 might be useful here. Attaching a demo using innerHTML to load a script with defer that works in IE but not Mozilla.
"defer" is not in the HTML4 spec is it?
It is part of HTML4.01 and was also in HTML4.0. See http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1
*** Bug 66240 has been marked as a duplicate of this bug. ***
*** Bug 66240 has been marked as a duplicate of this bug. ***
*** Bug 66398 has been marked as a duplicate of this bug. ***
I think, it would nice to have a possibility to dynamicaly load JavaScript! For me, I need it, because I don't know what all my or from other persons the webtools need while they are in use ... and so, the tools must load there scripts self. Is it possible to target this problem to m0.8 or m0.9 ??
Keywords: dom1
Component: DOM Level 1 → DOM HTML
Nominating for nsbeta1 consideration. Would like dynamically generated markup to be treated the same as static markup if possible. IIRC there was also some external JS library developer who had a library that depended on this.
Keywords: nsbeta1
QA contact Update
QA Contact: janc → desale
Did some work to give vidur tools useful for this bug. In particular, made it possible to create a |nsCommonString| that adopts your own buffer. See bug #74726. I'll attach an example of how this new functionality can be exploited here.
*** Bug 55560 has been marked as a duplicate of this bug. ***
Whiteboard: [nsbeta2-] relnote-devel → [nsbeta2-] relnote-devel DIGBug
Keywords: nsbeta2
Whiteboard: [nsbeta2-] relnote-devel DIGBug → relnote-devel DIGBug
Attached patch fixes in content — — Splinter Review
Attached patch fixes in string — — Splinter Review
The patches above have an sr=jst. Waiting for an r= from heikki. Tests can be found at http://blueviper.mcom.com/vidur/tests/scripts/. The tests are script[1-11].html and script[1-4].xhtml
Hmm... vidur, I though you said you had moved this away from Future milestone (yeah, the devious vidur is hiding bugs from PDT's eyes in the Future milestone ;). Here goes: 1. I think you have wrong types in IDL, namely nsresult, PRInt32, AString. PRInt32 at least should be long. 2. You seem to have a bogus comment about aScriptLength in nsIScriptLoadeObserver.idl. 3. In GetScriptLoader implementations you do not stabilize the COM ptr before using it. Not a big deal in our code (we do it all over the place), but still... 4. I really, really dislike nsScriptRequest. It has public data members, and this class alone forces you to do quite a few casts (another bad thing). I would like you to at least check if you could make some data members const (so nobody can change them after construction) or better yet, make it into a private interface to avoid those casts. We have public data members in event system and it has caused us a lot of grief. 5. Why do you do static_cast in InNonScriptingContainer, why not QI? 6. What if an element is without node info (HTML (?), so I am wondering how this can work)? You do not bail out of the function in that case, but use the pointer anyway. This pattern appears elsewhere as well: you use NS_ASSERTION but do not bail out/provide safe path out of the function. Please check these. Also, please use the explicit NS_WARN_IF_FALSE and NS_ABORT_IF_FALSE instead, and if you think a warning will do please use that instead of abort 'cos it makes life hard on Mac, for example. 7. What if you have script elements inside noscript elements? Does this stuff still work? 8. You have documented the values that can be thrown in IDL, yet you can throw other values as well (looking at the code). Please add a comment that those are not the only things that can be thrown. 9. Don't cast nsXPIDLCString to (const char*), use .get(). 10. Use NS_ENSURE_ARG in ProcessRequest(). 11. Will GetContext() always return context != 0 when the return value is successful? You assume so in EvaluateScript(). It would be safer to check both return and out param. 12. Don't (void) the return value of nsIURI::GetSpec(), it could be out of memory (?) 13. I think you have a typo in NS_ASSERTION(request,"StreamLoader's request went away prematurely... the variable name should be something else (now I can't find the place so spelling might be a bit off...) Also, have you checked compiler warnings? I am guessing there might be some new... What about jrgm's page load tests, and leak/bloat (this is quite a substantial change, after all)? Just out of curiosity, what would happen if I have nesting script elements?
I've changed the milestone to 0.9.1. Responses to your comments: 1) PRInt32, nsresult, AString are valid xpidl types. 2) Removed bogus comment. 3) Stabilized pointer before use. 4) nsScriptRequest is an internal class and I believe it's fine as it is - including the public data members. It's questionable whether it needs to be a nsISupports. Even if it weren't and I used a nsVoidArray for storage of requests, I'd still need static casting. An internal interface would be one way to go, but isn't it overkill for something that has file scope? 5) The cast up is cheaper, but I changed it to a QI. 6) Made sure that all assertions were followed with bail out code. Many were not mine but were in code copied from nsHTMLContentSink.cpp. 7) Harish and I decided that SCRIPT elements inside NOSCRIPT was a pathalogical enough case that it can be ignored. 8) Not sure the comments made sense anymore. I've removed them. 9, 11 and 12) Came from nsHTMLContentSink.cpp - they have been fixed. 10) Done. 13) Good catch! I fixed this. I'll do the leak/bloat tests, but I don't think performance is an issue here. Any reason you think it's imperative to run jrgm's tests. We support SCRIPT elements that contain JavaScript that does document.writes of other SCRIPT elements. This does work and is part of the test scripts referred to above.
Target Milestone: Future → mozilla0.9.1
Fix checked in on 5/16/01. Script execution and loading is now driven by a per-document script loader. Both SCRIPT elements in loaded content (originally evaluated in the content sinks) and dynamically added elements are evaluated on insertion into the document tree by the loader.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
It is good that dynamically loaded scripts are now supported. Four questions though. 1) If you remove the script element does the functions and variables go away? 2) If you modify the script text property (for an inline script element) does the script element re-initialize? 3) If you add an external script (one with a src attribute) does it now work? 4) If I add a script do I have to use the DEFER attribute in order for the script to be parsed? I am not sure about how #1 should work, but #2 should act as if you removed the script element and replaced it with one with the new text value, and #4 you should not need the DEFER attribute. Jeff.
1, no, scripts are not, and can not easily be unloaded. 2, no, modifying the content of a script does not cause the script to be re-evaluated, don't expect this to change. 3, yes, adding a script tag that has a src property, or contains text, the script (the content, or the code loaded from the src) is executed, inline script might be executed synchronously, external scripts are executed once they are loaded from the network. Order of execution is guaranteed to be the same as the order of insertion (time wise) into the document. 4, you do not need to use defer, mozilla does not yet support defer in any way.
Checked in changes on 5/18/01 that implement onload and onerror events for SCRIPT elements with a SRC attribute. These events do not bubble.
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
tested and verified ...worked fine for me....marking as verified build id: Linux 2001-06-07-13-0.9.1 Windows 2001-06-07-06-0.9.1
Status: RESOLVED → VERIFIED
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: