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?

Solution 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

Solution 2

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

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

Solution 3

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.

Solution 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".

View more solutions

Comments

[Mert Mertce]

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.

[Splaktar]

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

[JMac]

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!

[Barmar]

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

[Robert Oschler]

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.

[Pysis]

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

[Mike Devenney]

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.

[Jools]

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.

[Lluís Suñol]

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

[Lluís Suñol]

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

[dolbysurnd]

a bit of extra info: use browsertools:// as the protocol as in //# sourceURL=browsertools://yourdomaingoeshere.com/action-openu‌​wws.js

[xr280xr]

This causes a file not being loaded dynamically not to show up in the Sources Page script list where it should be. As @JMac 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.