How to debug dynamically loaded JavaScript (with jQuery) in the browser's debugger itself?

Question

A dynamically-added script is not showing up in the browser's debugger's scripts section.

Explanation:

I need to use and have used

if( someCondition == true ){
   $.getScript("myScirpt.js", function() {
       alert('Load Complete');
       myFunction();
   });
}

so that myScript.js can be dynamically loaded on meeting some condition... And myFunction can be called only after getting the whole script loaded...

But browsers are not showing the dynamically loaded myScript.js in their debugger's script section.

Is there another way round so that all of the goals may be achieved which will make one to be able to debug a dynamically-loaded script there in the browser itself?

Sprinkling

Possible duplicate of Is possible to debug dynamic loading JavaScript by some debugger like WebKit, FireBug or IE8 Developer Tool? – Laurenelaurens

use debugger; to auto stop in the dynamic loaded script, see javascript.info/debugging-chrome – Darrow

Answer 1

You can give your dynamically loaded script a name so that it shows in the Chrome/Firefox JavaScript debugger. To do this you place a comment at the end of the script:

//# sourceURL=filename.js

This file will then show in the "Sources" tab as filename.js. In my experience you can use 's in the name but I get odd behaviour if using /'s.

Since if a domain it is not specified filename.js will appear in a folder called "(no domain)" it is convenient to specify a domain for improving the debugging experience, as an example to see a "custom" folder it is possible to use:

//# sourceURL=browsertools://custom/filename.js

A complete example follows:

window.helloWorld = function helloWorld()
{
  console.log('Hello World!');
}
//# sourceURL=browsertools://custom/helloWorld.js

For more information see: Breakpoints in Dynamic JavaScript deprecation of //@sourceurl

Gonsalve

Note that it is changed to //#, although //@ still works in Chrome. Scripts in .html files also can be named in the same way. Be careful! Do not leave any blanks before and after '=' sign. – Forenamed

For me, the js file was being displayed in the sources list within a group called "(no domain)". Might be worth mentioning as I missed it at first! – Hogback

Just a tip. The Chrome debugger throws these pseudo-javascript files into the "(no domain)" node element in the Sources tab, at least when debugging on localhost. That's where I found them. – Politburo

Another thing to be wary of is the comment style. That "deprecation of/ /@sourceURL" link you gave mentions both "//# sourceURL=" and "/*# sourceURL=". That's because this can also be used for CSS, where you have to use block comments, as single-line "//" comments aren't valid. What surprised me was that you can't use "/* sourceURL=" in javascript. It just gets ignored. – Heterosexual

Afaik, most JavaScript minifiers remove these lines from production stages, making it useless for a production bug diagnosing. – Hypochondria

This causes a file not being loaded dynamically not to show up in the Sources Page script list where it should be. As @Hogback mentioned, it's actually under "(no domain)". I couldn't figure out why a script file wasn't being listed under its correct path until I finally noticed someone added that line at the end of the file and tried deleting it. – Nook

I found if I used browsertools it showed under a separate tree, but if I just used sourceURL=/file/this.js it showed under the same tree as my app, which I preferred. – Burd

Answer 2

I tried using the "//# sourceURL=filename.js" that was suggested as a workaround by the OP, but it still wasn't showing up for me in the Sources panel unless it already existed in my tabs from a previous time when it produced an exception.

Coding a "debugger;" line forced it to break at that location. Then once it was in my tabs in the Sources panel, I could set breakpoints like normal and remove the "debugger;" line.

Candlepin

It may also show up in the (no domain) listing under the Sources tab. – Knap

I also needed to use debugger;, and DevTools had to be open while the script was loading. – Nicotinism

a bit of extra info: use browsertools:// as the protocol as in //# sourceURL=browsertools://yourdomaingoeshere.com/action-openuwws.js – Hoyden

I used //# sourceURL=filename.js so that the js would show in the source tree, but I like using debugger; because I can put it anywhere, and I can place it in the source code before loading app. Once in app, it acts as the initial breakpoint, then I can add more via the DevTools or watch variables etc as per normal. – Burd

Answer 3

You can use //# sourceURL= and //# sourceMappingURL= at the end of your script file or script tag.

NOTE: //@ sourceURL and //@ sourceMappingURL are deprecated.

Entry

More deprecation information: developers.google.com/web/updates/2013/06/… – Delete

Sure, but afaik most minifiers will remove this lines on production stages. – Hypochondria

@LluísSuñol the whole point on sourceMappingURL is to debug code that has been minified and understand the Mapping. But personally, just debug not on production... but on source code. – Burd

Answer 4

Notice that the source file appearing in the sources tab this way will appear in the (no domain) group and, in case you want to debug it, you will need to add a debugger; line in your code, make that line be executed (usually at the start of the execution of your source file) and then add your breakpoints wherever you want.

In case you are debugging production stages, where you will probably have no debugger; lines in your code, you can make this happen by doing a local map with CharlesProxy to your "fresh copy of the source file with the debbuger line inserted".

Casa

This saved me! No matter what I did, the file didn't show up until I put in a debugger command. After that it persisted across page reloads and debugging sessions even after I removed the debugger command. – Only

Answer 5

When trying to track this sort of thing down in IE, I open the dev tools (F12) and then find where to place the breakpoint by using the following line in the console:

debugger;myFunction();

That switches to the debugger tab where you can step into myFunction() and set the breakpoint.

Arrowworm