Chrome Developer Tools keeps breaking where no breakpoints are set - javascript

When debugging JavaScript code using Chrome Developer Tools the debugger pauses on code where breakpoints are not set. I don't have the Pause on exceptions feature enabled, and there definitely are not breakpoints set (see attached image).
I asked a similar question before which was helpful but didn't quite solve this issue (previously I had the Pause on exceptions enabled). In the example below I swapped out the minified version of kendo.all.min.js for the unminified version, which allows me to see where the script execution is being paused, but I don't know why it is being paused. This happens a lot with jquery.min.js too.

I fixed my breakpoints problem by clicking the "Restore defaults and reload" button located in the “Settings” section. To find the button: In Developer Tools click the cogged wheel next to the top right three vertical dots. (Note: If using older versions of Google Chrome, click on the top right three vertical dots and then select “Settings F1”). The button “Restore defaults and reload” is at the bottom right.
Also note that it really restores defaults - you lose all previously saved breakpoints and any files you have open in Developer Tools will be closed.
I got this solution from: Chrome javascript debugger breakpoints don't do anything?

Accepted answer to Import/export Chrome devtools breakpoints & settings between computers reminded me to check "devtools-on-devtools" and in the DevTools' inner Application Local Storage remove the faulty element(s) of the JSON list value for key breakpoints to fix my same issue without resetting everything.
Later it happened again, so I wrote this console snippet:
((stores, matchKey, removeMatchingRegExp, dryRun)=>{for(let store of stores){
let r = JSON.parse(localStorage[store]), l = r.length;
r = r.filter(b=>!b[matchKey].match(removeMatchingRegExp));
if(!dryRun) localStorage[store] = JSON.stringify(r);
console.log(`${dryRun ? 'Would' : 'Did'} remove ${l - r.length} entries from ${store}:`, r)}; return 'OK'})
(['breakpoints', 'domBreakpoints'], 'url',
new RegExp('^https?://example.com/script.js$'), true)
Note:
Provided without warranty: Use at own risk. Backup your data.
Edit it - at least the RegExp argument - to suite your needs.
The last-most boolean should be false to disable dryRun.
Outer DevTools must be reopened for effect.

I was able to resolve this by updating Chrome. I don't think the version matters, just the process of updating resets all of the breakpoints that have been stored in the cache.

F8 has two functionalitys. 1. Skip ot next Breakpoint, 2.stop wherever the Browser is executing code. This works even if you have no breakpoint set. For example spamming F8 when you forgot to deactivate breakpoints might cause the browser to stop anywhere.
When you go to the debugger shortcuts you can see that F8 has the functionality to Pause / Continue. But it sadly seems like you can't split them on two different keybinds.
Since I know this feature I never ran into this "bug" anymore.

I'm posting this answer in case it will help someone who, like me, missed an important clue as to the cause of the phantom breakpoint behavior. In my case, it was "user error" --mine. The root cause was a forgotten "debugger;" statement in a JavaScript file that was itself generated from TypeScript. I had removed the debugger; statement from TypeScript locally, run and tested without issue from localhost. But I had pushed the version with the statement to remote and it built and released to our dev site with the statement present. The dev site build excludes the TypeScript source files. When the debugger statement was hit, Chrome tried to load the .ts source and displayed "Could not load content..." I just assumed it was at a breakpoint (I'd set many during testing). And when I saw "No breakpoint" I assumed Chrome was experiencing the issue addressed in this thread. If I'd bothered to look in the Call Stack trace, I would have seen the source code line in the .ts file and pretty quickly figured it out. Here's a screenshot:

just disable the cache and reload the page, the breakpoints will show up again

Related

Loading sourcemaps and debugging in Safari?

We ran into an error that only occurs on Safari browsers, so I dusted off my OSX partition on my Macbook and am trying to debug it but I can't find out how to see the original source code and set a breakpoint.
My main file is main.d7f60b0631c7822cabf3.bundle.js and the last line of the file is this, which points to the sourcemap file which does exist because I can type in the url and get it, and it works in firefox and chrome:
//# sourceMappingURL=main.d7f60b0631c7822cabf3.bundle.js.map
In Firefox I can go to the debugger tab in dev tools and under sources I see my original source file webpack:///src/app/app.component.ts and I can open it and set a breakpoint.
In Chrome dev tools I go to the 'Sources' tab and do the same thing navigating a tree to webpack:// - . - src - app - app.component.ts.
Is there a way to achieve the same thing in Safari? From memory since I"m writing this on Windows I can't see any files in the debug tab, just a list of breakpoints. In the resources tab I can see the bundle and an arrow that looks like I should be able to expand it, but clicking on that arrow does turn it from right to down like it is expanded but nothing is displayed. Other files like jquery do seem to have the original source under them when expanded...
I had the same question, and found the answer in another posting here:
How do I toggle source mapping in Safari 7?
(short version, in the debugger, command-click on whatever symbol you want to look at, and it should jump to the original source. For reference, I'm working with TypeScript compiled to JavaScript)
The author points to this documentation:
https://developer.apple.com/library/content/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/ResourcesandtheDOM/ResourcesandtheDOM.html#//apple_ref/doc/uid/TP40007874-CH3-SW4
In the process, I also noticed that in the Resources tab in the Safari debugger, it shows the foo.js with a turner next to it, which expands to show the original foo.ts file (and I assume with a more complex source, it might expand to show multiple sources if they get concatenated together?)
Personal opinion: I think the turner is a great solution to this problem... odd that the debugger defaults to showing the "compiled"/"transpiled" source rather than the stuff one is logically wanting to debug.
First be patient while the browser processes all the source maps.
Whenever that finishes, you should be able to search for any original source file by entering the name of that file into the input field located at the bottom of the pane with the placeholder "Filter". It's a pretty counterintuitive UX IMO. Hope this helps someone!
Screenshot:

Why doesn't debugger stop at breakpoint?

I have the problem that the chrome debugger for JS doesn't stop every time I execute one certain function. I tried debugger; and also setting breakpoints where I want the code to stop by putting a blue tag on the gutter next to the line on the left.
any ideas why this happens?
Without a clear reproduction plan, it is very hard to tell why your breakpoints are not hitting.
But, one surest way of stopping on a line is writing:
debugger;
to the location where you want to stop. Without any blue signs on the gutter, the debugger will halt.
NOTE: Be sure to clear all the debugger; when you are done with it.
More info is here
What I found worked was to set my breakpoints using the suggestions above, then in the extension's console run:
location.reload(true);
This re-opens the extensions, set off my breakpoints and allowed me to debug!
It appears that the problem is related to the debugger loading after the extension, thus not capturing the breakpoints. Hope that helps!
I had an issue with breakpoints being hit that I just resolved.
Breakpoints within javascript in the html were not being hit, although I could set and hit breakpoints in included Javascript files.
I found that the problem was that the source file was included twice. The base html page (not dynamically included) has the sourceURL tag in it. This caused the same javascript to exist twice in the source pane, causing the issue.
I removed the "sourceURL" tag from the base html page, and breakpoint resumed working
For me this appears to be a bug in chrome - nothing would cause a breakpoint to be hit, not even debugger. I had to close and re-open Chrome, and then my breakpoints worked.
Also, it's possible that breakpoints are disabled. You can toggle this in the debugger or by pressing Ctrl + F8
Maybe you add your target file to blackbox, so debugger could not be triggered on it.
solve:
ref: https://developer.chrome.com/devtools/docs/blackboxing
Had you add folder to workspace accidentally?
If yes, your devTool breakPoint would stop work on this file.
After I remove folder from workspace, breakpoint feature is back!
With client solutions like angular js, the modules and controllers are picked up independent of the file name. Most probably you would have created a backup/copy of file in the same folder as the actual file you are debugging. This might be the js file getting called instead of one you intended. You can delete that file and it should work fine.
I found that code referenced by a tag with the async property inside of it don't stop at breakpoints in developer mode.
This may sound dumb... but it worked for me... Simply closing and re-opening the browser restored JS debugging functionality.
to test your function debug point you can call that function right from console.. it will call and hit your breakpoint
Check if your function is called properly. For me, I resolved the problem by conceptualising the flow of my program and found out that the function calling had some errors. After figuring that out, it was easy to continue.
I had the same problem and it turned out that reason was that I had enabled bundle, i.e.
in the BundleConfig.cs I had BundleTable.EnableOptimizations = true;
When I changed it to BundleTable.EnableOptimizations = false; it worked.......
If you are using the VS, check if configuration is DEBUG. When is Release the MVC minify the JS.

Finding an infinite (or very large) loop in JavaScript using Chrome Dev Tools

I'm using a third party statistics library which seems to have loads of issues. It's both large and compressed, so it's not particularly easy to debug. I'm using the Chrome Dev Tools and I was wondering what options there might be for ranking functions by the number of calls by their name, maybe? I thought the answer was the Profiler tab, but the profiles I captured are only documenting the JS files referencing "line 1" in long chains.
This thing is freezing my app and I'd rather avoid making changes to their code as much as possible, even if its for the sake of debugging. I'm happy to clarify anything that's not clear.
EDIT: I seem to remember a recent demo of chrome dev tools somewhere showing a timeline that depicted function blocks stacked vertically based on the time increment going horizontally called "flame charts" or something similar... That would be ideal, but I can't remember the link right now for the life of me. Not opposed to using Canary on this one at all if anyone knows what this tool is?
The latest video about DevTools is here http://youtu.be/x6qe_kVaBpg?t=19m44s
It covers different topics about DevTools and includes a section about CPU profile too.
So, you need to record a cpu profile and look into it.
Also you can use FlameChart view on it.
You can click on an item in BottomUp or TopDown or even a FlameChart bar and see the function body in the Sources panel.
If you sources are minified, as in the screenshot, then you can press a button in the status bar of Sources panel. It looks like two curly braces {}. Then DevTools will format the sources.
and that action will affect all the links to the source file in all other places like Timeline, CPUProfile etc. As example in the first snapshot you saw a function O.Pk that was at line 778 of minified version of the script. After pretty printing the source file the link to the function was changed automatically. Now it is pointing to the line 15871.
Looks like the answer is the "Timeline" tab. Seems to work in regular chrome. I set the tab to record just before I triggered the action that caused the hang, once the hang stopped (took about 20 seconds), I stopped recording and used the left and right selectors to zoom in on the master timeline (at the top) where I saw an longer execution period (at the top) with "Events" selected.
From there I just expanded the dropdown and I got what I was looking for. (I blurred out the js filenames to avoid singling out the library) but I'm including a screenshot.

Why is Firebug hitting non-existent break points?

I've been using Firebug to debug some javascript I have on one of my pages. Recently it has started hitting non-existent "break points" at seemingly random spots in my javascript. It seems like most of these points are in third party libraries like jQuery, but it also stops on custom javascript.
I'm not seeing any errors at these lines and I definitely don't have break points there. Can anyone think of why Firebug would be stopping here? It's getting to the point where I have to hit the "Continue" button about 20 times to get the page to finish Javascript execution...
I had this problem and fixed it like so:
Uninstall firebug in the firefox add-ons manager
Close firefox
rm -rf profile_folder/firebug
Delete all firebug-related lines from profile_folder/prefs.js
Reinstall firebug
Hope this helps!
There is nothing wrong with firefox, this is happening because you might have enabled auto breakpoints. Check here http://getfirebug.com/wiki/index.php/Script_Panel for more details about what i am talking about. Disable them on console and script panel and everything will be solved.
This question is old, but it is also the top result for searches: like firebug random breakpoints.
In my experience, assuming this is not due to break on exception or other settings, every time this happens to me there is some collision with jQuery, or another library. Sometimes even name spacing does not keep you safe, and this is very hard to debug.
Most recently I had a function named: name_space1.nestedns.focusCursor(). Something was messing with my focusCursor function.. didn’t figure out what, just changed the name.
Farther in the past I had a function or var named ns.companyabreviationToolTip... and there was collision and breaking on this as well. Changed ToolTip to something obscure, and everything was happy. Maybe firebug has a secret break on collision setting. If this is a bug, I hope it does not get fixed… it seems useful.

Firebug doesn't load JavaScript files or stop execution on breakpoints

I'm new to Firebug and having a lot of trouble.
JavaScript files usually show up empty, or load partially (some of the time)
Lines are not available to set breakpoints on frequently (line numbers are greyed out)
When I do set breakpoints, script execution often does not stop on them
I'm using Firebug 1.3.3 and Firefox 3.0.11. I have disabled all other Add-ons. I'm loading Javascript from localhost. Sometimes closing the window and re-opening the page I was on clears things up, but that never lasts for more than a couple page loads.
I'm working on learning jQuery, which obviously has a huge library, but I imagine many other people use Firebug for the same, so that shouldn't be a problem. Also, most of the time (but not always), Firefox loads and executes the JavaScript no problem; just Firebug can't see it.
Due diligence:
These discussions seem to cover the same problem, but have no answers:
"Firebug not showing Javscript errors" - http ://groups.google.com/group/firebug/browse_thread/thread/443848cd11be48e1?pli=1
"firebug does not always load javascript" - http ://code.google.com/p/fbug/issues/detail?id=1644&q=empty%20javascript&colspec=ID%20Type%20Status%20Owner%20Test%20Summary
(Sorry I'm new, and not allowed to hyperlink those)
A couple suggestions. Make sure that you have the console, net, and script panels of Firebug all turned on.
You should see in the net panel what js files have downloaded. In the console panel, you should be able to type console.log(jQuery) and get back function().
This should confirm that jQuery is actually loaded and running.
Then go to your script panel, and you should see four options across the top. Inspect, Edit, Static, and then a drop down list of your scripts. That's the one you want. Select the script that you want to debug.
Based on your question, you probably know some of this already, but confirm that all of that is working first.
When you don't see jQuery in the scripts list, can you do console.log(jQuery)?
PS. It's not a matter of size. I routinely load js files that are 10x the size of jQuery.
Edit: A few more suggestions:
1) Reduce to simplest case and add back. Remove all your scripts other than jQuery and then add your other scripts incrementally. Is there one that consistently breaks it.
2) Put try / catch statements around suspicious code blocks. I've often found that FB stops reporting errors after an uncaught exception has been thrown.
try {
// your code here
} catch (e) {
console.log(e)
}
3) Setup another FF profile to test if you get the same problem.

Categories

Resources