96

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?

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
TwiToiT
  • 1,159
  • 1
  • 9
  • 13
  • Possible duplicate of [Is possible to debug dynamic loading JavaScript by some debugger like WebKit, FireBug or IE8 Developer Tool?](http://stackoverflow.com/questions/1705952/is-possible-to-debug-dynamic-loading-javascript-by-some-debugger-like-webkit-fi) – GorvGoyl Jan 12 '16 at 07:27
  • 2
    use `debugger;` to auto stop in the dynamic loaded script, see https://javascript.info/debugging-chrome – yu yang Jian Apr 07 '19 at 12:10

5 Answers5

213

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.

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

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
Mark
  • 2,944
  • 1
  • 14
  • 17
  • 19
    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. – Mert Mertce Oct 02 '13 at 10:54
  • 11
    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! – JMac Mar 18 '15 at 16:39
  • 7
    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. – Robert Oschler Jul 21 '16 at 21:32
  • 1
    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. – Jools Oct 09 '18 at 12:28
  • 2
    Afaik, most JavaScript minifiers remove these lines from production stages, making it useless for a production bug diagnosing. – Lluís Suñol Apr 15 '19 at 10:14
  • 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. – xr280xr May 10 '21 at 23:58
16

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

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

xRavisher
  • 818
  • 1
  • 9
  • 13
13

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.

kevinpo
  • 1,525
  • 17
  • 19
  • 6
    It may also show up in the (no domain) listing under the Sources tab. – Splaktar Aug 19 '14 at 19:53
  • 1
    I also needed to use `debugger;`, and DevTools had to be open while the script was loading. – Barmar Jul 16 '15 at 16:59
  • 2
    a bit of extra info: use browsertools:// as the protocol as in `//# sourceURL=browsertools://yourdomaingoeshere.com/action-openuwws.js` – dolbysurnd Apr 24 '19 at 20:04
6

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

Lluís Suñol
  • 2,733
  • 3
  • 18
  • 30
  • 2
    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. – Mike Devenney Mar 06 '17 at 18:34
0

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.

Alan Samet
  • 969
  • 1
  • 11
  • 17