87

When using Chrome and it's JavaScript debugger, every time I reload my page / scripts, my breakpoints are lost and I have to go find the script file in the pop-up, find the line of code for my break point, click to add it, etc.

Is there a way to save these breakpoints so it breaks even after a page refresh (other debuggers I have used do this)?

Alternatively, is there a clean way in my JavaScript code I can type something to tell chrome to start tracing (to pause on a line)?

Scott Szretter
  • 3,938
  • 11
  • 57
  • 76
  • 3
    Chrome Developer Tools should keep JS breakpoints between refreshes. Are you using ` – J. K. Nov 23 '11 at 14:25
  • +1 This happens to me a few times a day as well on Chrome on OSX. Mostly breakpoints work well, but then sometimes, the breakpoint just won't stick when I refresh! – dano Sep 21 '12 at 18:18
  • You will also loose breakpoints if something is changed in the ?querystring of the script (for example, a cachebuster) Not sure about #hash – oriadam Sep 11 '16 at 19:37

9 Answers9

75

You can put a

debugger;

to break in most of the JavaScript environments. They will persist for sure. It's good to have a minifier that rids the debugger and console.log calls for the production environment, if you are using these.

In the recent versions of Chrome browser, there is a "Preserve Log" option on the top of the console panel, next to the filters. In the older versions, right clicking on the empty console window will bring that option ("Preserve log upon navigation"). It's handy when you don't have console.log statements or hard-coded debugger calls.

update: I found a tool on github, called chimney, which takes a file and removes all the console.log calls. it gives a good idea about how to remove debugger calls.

Ege Özcan
  • 13,971
  • 2
  • 30
  • 51
  • 3
    checking the Preserve Log Upon Navigation seems to be the real ticket to getting chrome to act like it did previously – chrismarx Apr 05 '13 at 19:47
  • here is a nice alternative for web workers: http://stackoverflow.com/a/4985794/300011 – Ege Özcan May 13 '13 at 06:59
  • I had forgot about the `debugger;` lol spent like half an hour trying to figure it out. – Eric Bishard Sep 05 '16 at 03:40
  • Preserve Log didn't work. – Kuronashi Nov 11 '21 at 09:25
  • @Kuronashi if you could find the option and it still didn't work, it means that the page gets served different (and/or differently named) files js files or bundles each time. If you are using a framework or a CMS, make sure there are no cache-busting development plugins are enabled. Some development configurations can also cause this. – Ege Özcan Nov 11 '21 at 11:46
44

Set your breakpoints, switch to the Network tab and select the Preserve Log Upon Navigation toggle button. Now the breakpoints should be there when you refresh.

Or the JavaScript way is to use 

debugger;
pradeek
  • 21,445
  • 2
  • 31
  • 32
21

Also, do you send your JavaScript file(s) from the server to the client with an attached query parameter to the URL with the current Epoch time? This is used to prevent caching of the JavaScript file(s).

When this is the case, it seems like the Chrome Developer Tools interprets the file to be a different one after the refresh, which will (correctly) remove the breakpoints.

For me, removing the query parameter made the CDT keep the breakpoints after refresh.

Community
  • 1
  • 1
sjogren_me
  • 393
  • 3
  • 8
  • 3
    Thank you! ExtJS 4 includes a "_dc" parameter to keep files from being cached and would clear breakpoints every time. Adding ``Ext.Loader.setConfig({ disableCaching: false, enabled: true });`` to the app config disables it. – Brian Topping Oct 29 '12 at 00:58
  • @BrianTopping Thx for that hint. Why the hell did they do such a stupid thing as attaching dynamic query params to prevent caching. It's the browser (dev-tools)/server that should control it... – Juri Mar 19 '14 at 09:48
  • @sjogren_me, how did you remove the query parameter in Chrome Dev Tools? – jds Apr 09 '14 at 19:26
  • You're a hero. Some weak devs shipped `date('His')` query string and this reminded me! – lkraav May 05 '21 at 09:59
12

This is probably happening for scripts that you're dynamically loading or evaluating from other scripts? I can say for myself that this scenario really irritated me until I discovered the sourceURL property. Placing the following specially formatted comment on the last line of the script you want to debug will 'anchor' it within Chrome so it has a frame of reference for it:

//# sourceURL=filename.js

Your manually-placed breakpoints will now persist between page loads! The convention actually originated from the sourcemap specification, but Chrome at least honors it as a standalone technique. Here's a reference.

jtrick
  • 1,329
  • 18
  • 23
  • 1
    THIS is the one that I needed. The other answers require changing library behaviour ("remove the query parameter") or accepting the loss of all existing breakpoints ("just add _debugger;_"), neither of which are actually what I think the OP wanted. Definitely not what I wanted. The cause on my end was js files all have timestamps, which confused DevTools in Chrome. Thanks @jtrick because I believe this is the primary answer to the OPs primary question, "Is there a way to save these breakpoints?" – Dr Sank May 13 '21 at 20:49
  • The reference link on post is broken. This is the updated one: https://developer.chrome.com/docs/devtools/javascript/source-maps/#sourceurl_and_displayname – Marco Sacchi Nov 08 '21 at 18:50
2

For people using ExtJs 6.x:
instead of disableCaching in the Ext.Loader you could add a "cache" or "disableCacheBuster" query parameter to the page's URL. This will remove the "_dc" parameter from the file and enable chrome debugger to persist the breakpoint.

See bootstrap.js in your application (config parameter disableCaching).

kaah
  • 121
  • 1
  • 3
  • 1
    there seems to be other formal way by setting value in app.json for loader.cache: true, https://www.sencha.com/forum/showthread.php?303932-Setting-a-breakpoint-in-Chrome-disappears-on-refresh-is-there-a-workaround – Saurabh Sep 01 '17 at 19:49
2

You can use the debugger; statement in your source to make the debugger break there.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
0

You can put debugger; before the code where you want to start debugging. Once the page starts loading,it would stop at the debugger; statement. Then you can easily apply the debugging point as per your requirement.

sandeepConnected
  • 9
  • 2
0

As said by @jtrick, use the comment:

//# sourceURL=filename.js

it is the best way to obtain the persistence of breakpoints between page refreshes and also between closing and reopening of chorme, even in versioned (to have control over browser cache) or dynamically included javascript/css files.

This is the updated reference link:

While not part of the Source Map spec, the @sourceURL allows you to make development much easier when working with evals. This helper looks very similar to the //# sourceMappingURL property and is actually mentioned in the Source Map V3 specifications.

By including the following special comment in your code, which will be evaled, you can name evals and inline scripts and styles so they appear as more logical names in your DevTools.

//# sourceURL=source.coffee

If you have a server-side cache for the versioned files served to the browser, you can append the comment in the source code at the time of the cache generation, without having to modify the original source files.

NOTE: on the comment you can also specify a virtual path to the file, this way you can organize your dynamically loaded or versioned content on a tree displayed in chrome devtools > navigator panel > sources > page treeview. I.e.:

//# sourceURL=https://yourdomain.com/libs/ui/widget.js

Marco Sacchi
  • 712
  • 6
  • 21
0

Chrome Developer Tools should behave the way you expect but you can put debugger; statements in your (development!) code to pause the execution.

J. K.
  • 8,268
  • 1
  • 36
  • 35