Created attachment 702225 [details] script-loader.js STR: 1. Open a Scratchpad 2. Load the attached script 3. Open the Debugger 4. Run the script Expected results: Script appears in the <head> of the document. Actual: No script visible. For bonus points, trigger the contents of the script and watch the breakpoint hit on the <head> element in the source view.
Created attachment 702258 [details] script-loader.js v2 Fixed a typo and added a trigger for the pause. This is the newScript packet the server sent: context17", "type": "newScript", "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=830699", "startLine": 0, "lineCount": 3, "source": "conn4.source28" } Gecko or SpiderMonkey use the URL of the document where the dynamic script was created, which is to be expected, but with a starting line number of 0.
So I tried it on a URL without any scripts, and the debugger does the right thing and display a single script with the page URL and the contents of the scratchpad (which may not be what you'd expect, but it's better than nothing!). Bug 566446 mentions that JSD has the same issue (and it affects Firebug) only worse, because it treats scripts with startLine == 0 as errors. It is also quite similar to bug 332176, which we already know. I don't know how or if Gecko/SM could relate the dynamically-added script's starting line to the modified markup of the page. The only shred of evidence that something like that is possible, is the View Selected Source context menu item in the modified page. We need to find out how View Source gets this update markup, and whether this is something the debugger should do as well, or it can be somehow provided by SpiderMonkey. And by the latter I mean to have the Debugger API return a startLine that correponds to the updated markup through onNewScript.
Jim, we could probably use a consult here. This would allow us to do some interesting things with scratchpads and dynamic scripts.
Created attachment 8894984 [details] test.html Just putting this into a simple html page you can run. The new debugger still doesn't handle this properly. We likely need to change the server here.