Closed Bug 566446 Opened 15 years ago Closed 10 years ago

javascript added to document through appendChild are not handled by jsd

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: rauldmiller, Assigned: jorendorff)

References

Details

(Whiteboard: [firebug-p2])

Attachments

(1 file)

reporter's testcase
1.46 KB, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729) Apparently the scripts created by appending script elements do not use the normal paths and are not seen by Mozilla's jsd infrastructure. They do not come through onScriptCreated and I can't see them via enumerateScripts. So I don't have any way to debug them. Reproducible: Always Steps to Reproduce: <html> <head> <script type="text/javascript"> function addNewScriptToHead() { var newScriptElem; var newScriptText; newScriptElem = document.createElement('script'); newScriptElem.setAttribute('type', 'text/javascript'); newScriptElem.text= 'function runNewScript() {alert("hi there")}; function runOtherScript() {alert("hi again!")}; function kilroy(id){document.getElementById(id).innerHTML= id}; function breakIntoDebugger(){debugger}; kilroy("hostDiv1")'; document.body.appendChild(newScriptElem); }; setTimeout(addNewScriptToHead, 1); // wait, so DOM is complete setTimeout(function(){kilroy('hostDiv2')}, 3000); </script> </head> <body> <div id="hostDiv1"></div> <div id="hostDiv2"></div> <hr /> <br /> <button onclick="runNewScript()">Run one of the newly added functions to ensure that it is real. This should alert the string "hi there"</button><br><br> <button onclick="runOtherScript()">Run the other newly added function to ensure that it is also real. This should alert the string "hi again!"</button><br><br> <button onclick="breakIntoDebugger()">Break into the debugger</button> If you load this page in firefox you can see from the first two buttons that the dynamically added javascript is working. However, the third button fails to do anything useful even when [for example] firebug is active. </body> </html> Actual Results: If you load that page in firefox you can see from the first two buttons that the dynamically added javascript is working. However, the third button fails to do anything useful even when [for example] firebug is active. Expected Results: breakIntoDebugger() should break into the debugger.
> Apparently the scripts created by appending script elements do not use the > normal paths Actually... they do. At least on the Gecko side they follow the same exact codepaths as any other script.
Attached file reporter's testcase —
This is just another case of jsd not wanting to handle line number zero scripts. _newJSDScript (jsdc=0x118ec6420, cx=0x101a4c000, script=0x119b686d0, function=0x11eb15b60) at /Users/timeless/devel/mozilla.org/mozilla-central/js/jsd/jsd_scpt.c:100 103 lineno = (uintN) JS_GetScriptBaseLineNumber(cx, script); (gdb) n 104 if( lineno == 0 ) (gdb) p lineno $28 = 0 (gdb) l 99 100 JS_ASSERT(JSD_SCRIPTS_LOCKED(jsdc)); 101 102 /* these are inlined javascript: urls and we can't handle them now */ 103 lineno = (uintN) JS_GetScriptBaseLineNumber(cx, script); 104 if( lineno == 0 ) 105 return NULL; there's already a bug asking someone to improve the behavior of this.
#0 JS_EvaluateUCScriptForPrincipals @ lineno=0 #1 nsJSContext::EvaluateString @ aLineNo=0 #2 nsScriptLoader::EvaluateScript 756 rv = context->EvaluateString(aScript, 757 globalObject->GetScriptGlobal(stid), 758 mDocument->NodePrincipal(), url.get(), 759 aRequest->mLineNo, aRequest->mJSVersion, nsnull, 760 &isUndefined); aRequest->mLineNo = 0 Afaiu, there's some unimplemented contract where people are not supposed to give line number 0 to stuff if they want to be nice. If we're lucky, jorendorff has already covered this.
Assignee: nobody → jorendorff
Component: JavaScript Debugging APIs → DOM
Depends on: 332176
QA Contact: jsd → general
Well, there is no line number associated with the script. Any line number would be a lie. If jsd can't handle such scripts, that's jsd's problem, no.
Component: DOM → JavaScript Debugging APIs
QA Contact: general → jsd
If 0 is special, then maybe -1 would be an appropriate value for scripts that do not appear in a file?
never mind, no, -1 would not work. First because that is an unsigned and second because it is a base number to which other numbers would be added. Sorry for the noise.
rauld: this is manageable at either level. don't worry about it. There's a patch for this in the other bug.
See Also: → 417040
The other bug seems to be https://bugzilla.mozilla.org/show_bug.cgi?id=417040 where people were aggreeing that calling jsd with a line number of zero was a bug.
See Also: → 332176
Some of the Firebug user bug reports related to this bug: http://code.google.com/p/fbug/issues/list?q=label:jQueryScript It prevents certain scripts loaded by the popular jQuery framework from loading.
Whiteboard: [firebug-p1]
Whiteboard: [firebug-p1] → [firebug-p2]
bug 566446 has another test case that I believe is this bug.
Since there may be a patch for this very important problem over on bug 332176, I am nominating this bug to be reviewed.
blocking2.0: --- → ?
I don't see us holding the release for this, but the other patch should get approved if it gets r+'d and looks reasonably safe.
blocking2.0: ? → .x
This should be [firebug-p1]. This has become the standard for async loading. Just about every "widget" JS added to webpages uses it (Google Analytics, and AdSense, for example). jQuery, Dojo, ExtJS4, etc. use it as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
We can't debug jQuery or dojo on Firefox.
Test case on http://code.google.com/p/fbug/issues/detail?id=4348 works great on Web Inspector.
Component: JavaScript Debugging/Profiling APIs → JavaScript Engine
The test case works in JSD2. Tested with Firefox 30.0a1 (Nightly) + the built-in debugger / Firebug 1.13.a8 with JSD2 support. So I believe this issue can be finally closed. Sebastian
JSD was removed in bug 800200, so I close this one now. Sebastian
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: