Closed Bug 566446 Opened 14 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: