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.
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.
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.
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.
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).
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.
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.
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.: