What have I done?
I'm running a ASP.net / Polymer website in VS2010 Development server.
It all used to run fine I could set a breakpoint in some JavaScript, run the site in Debug mode and it would break at the set location.
I obviously changed something though because now I can only set a breakpoint once the Javascript is loaded or by putting a debugger; statement in the code
Actually, I can set a breakpoint (or appear to) but it doesn't break at that location
Just me being stupid again
It turns out the problem was because I had added the folder containing the Javascript source to the workspace (by right clicking in the Sources pane)
Having done this the folder tree which used to appear under the localhost:nnnnn parent in the Sources pane no longer showed
Don't remember adding them but obviously I did
Removing the folders fixed it
I mainly put this answer here so that the next time I do the same thing and look it up on Stack Exchange I will find the answer
I have found the best way to add a breakpoint with Chrome is just adding this in the code:
debugger;
So long as the code is actually run and you have the javascript console open it will be caught.
But sometimes the I have found the dev tools get broken and require the entire browser to be restarted.
Related
[The Past] (that I could cope with, get around by): from time to time I used to run into a problem in which Chromium Developer Tools would not associate running code with the actual files it downloaded. At least that's how it 'feels'.
The code file would not be visible from the Google Dev Tools even though the code would be executing. If, one tapped the 'browse-files' icon - the file would not be on the list. Thus there would be no way to place a breakpoint and debug the file.
The work around that used to work for me. When this happened I usually tracked the source of code by messages written into the Console Terminal as Chromium would indicate the source of its invocation (of console.log()) right next the logged message. The name of the 'file' would usually be some random thing. So, no wonder breakpoints were not being hit as it turned out that for some reason Chromium deemed not 'swarm.js' to be executing but some random 'VM2231~.js' - with 'dynamic files?' always following the 'VM[NUMBER]' pattern - for whatever the reason.
Anyway, the 'workaround' used to work. Around the case of files not being listed within the Developer Tools, at least. So back then I ended up debugging files looking like so:
Present Case:
But, today even that ceased to work for me.
All of the sudden, breakpoints are neither being hit nor am I able to see the source of code triggering console.log() invocations as these happen - for some of the code files.
Notice below that for some invocations - the source is simply not depicted to the right. If I place breakpoints within the corresponding file, these breakpoints would never be hit, as well.
In short:
breakpoints are not being hit.
the source of console.log() invocations for some of the source files is not depicted, at all.
Thus, the code executes, still I'm unable to work further as I'm unable to debug.
If that helps anything, these are JavaScript modules, loaded dynamically at runtime.
I have a JavaScript file which i want to debug and test, so i want to add some breakpoints to it. now i read that i can do so using Firefox F12 tool. so i did the following steps:-
i navigate to my application.
click on F12.
then under "Debugger" tab i can see all the script which are loaded with the ability to add breakpoints to it.
But I can not find a way to write a custom JavaScript and add breakpoints to it.. is this possible ? or the JavaScript need to be already loaded inside the page to debug it ?
Thanks
Just open your console, and use debugger as one of your statements and the debugger will stop there;
(function(){
var x = 1;
debugger;
console.log(x);
})()
One relevant point:
"You can place a debugger; statement anywhere in your JavaScript code. Once the JS interpreter reaches that line, it will stop the script execution, allowing you to inspect variables and step through your code."
Running a script in your computer
Normally you would have to run an local apache server to do this.
The other option is run the script with node.js. You have plenty of debug options.
Here you got a excelent tutorial about debugging on Node (called Bug Clinic):
https://nodeschool.io/#workshoppers
Although I used pretty code and had set up the breakpoints in "Pretty code" tab, debugger keeps working in minified code. (I can't see exactly where I am and need to continuously switch between source and "pretty code").
On same pages with same script it sometimes work and sometimes don't. I can't find the cause or any difference in the way I activate it.
Is there any way to force debugger to use "pretty code"? Any Ideas or additional questions? Should this be reported as a bug?
EDIT: I still don't understand what is going on but there is a fix for it. So when this situation happens, just edit script and add "debugger;" keyword after the cursor. It will make a breakpoint. Then, if you use "pretty code", debugger will stay inside prettified code. As I said, I don't understand why is this happening so I'm still waiting for answer(s).
EDIT: Current browser version is 42.0.2311.135 (64-bit).
EDIT: Dave pointed out that there is a reported bug on something very similar. https://code.google.com/p/chromium/issues/detail?id=415406 It says it's related to file size but I can't confirm this. I changed title to reflect these findings.
In Chrome and Safari, simply select the 'Scripts' tab, find the relevant file and then press the "{ }" (pretty print) icon located in the bottom panel.
You can call this a bug. You can call it a dillema.
Open ticket from Aug 9, 2013
(Chrome v. 28)
Bug Reporter's observations
I've been spending some time debugging this, and familiarizing myself
with how to develop devtools locally; I'm not sure if all of this is
helpful, but here's a braindump of what I've looked at so far and some
hunches:
When attaching a breakpoint in the original .js file, the UI seems to
get confused and assigns the breakpoint to the associated .coffee or
.ts file per the sourceMap association [see image-1, attached]
However, when unchecking the breakpoint to disable, the UI correctly
updates to show the breakpoint in the right place in the .js file.
[see image-2, attached]
It seems to me there is either an incorrect lookup happening in
WebInspector.CompilerScriptMapping.rawLocationToUILocation or
WebInspector.CompilerScriptMapping.uiLocationToRawLocation
Open ticket from Sep 21, 2014
(Chrome v. 37)
Chromium Developer's Observation
This is not something that could be solved easily. The breakpoint
manager is build around the idea that the breakpoint is always shown
in the "best possible" UI location, which is uncompiled source in case
of source maps. Fixing this would require us to use breakpoint's
primary ui location as a hint to where it should be shown. Moreover
since execution line will be shown in the uncompiled sources by
default, it is essential that we keep showing our breakpoints in them
as well. So this all ends up in the need to show breakpoints (and
execution line) on several ui locations at the same time. All actions
with these locations should work smoothly etc.
This is a significant effort and does not sound like a "GoodFirstBug"
to me.
Conclusion:
Prettify does not seem to create a new non-minified version. Rather it is rendered. This makes sense. With all the different frameworks and flavors (e.g. Coffee), if the debugger created a new file, there is high potential for error.
The breakpoint
manager is build around the idea that the breakpoint is always shown
in the "best possible" UI location, which is uncompiled source in case
of source maps.
I interpret this to mean the Chrome browser and debugger will continue running from the minified version. When you set a break-point in a "pretty" file, the debugger sets it in the minified file and gives the developer a "pretty" rendering of debugger stepping through minified file.
This is a lot for the debugger to manage, and can be rather fragile. We can call this a bug or a very ambitious feature for which many things can go wrong.
**
I have added this thread to both bugs and emailed both developers assigned to it.
**
As of 2020, similar behavior still occurs in a specific situation:
You open a source-mapped document, i.e. it shows "(source mapped from ...)" on the bottom of the window
You prettify it
You place a breakpoint in the prettified version
The debugger will stop in the ugly source-mapped file
The solution seems to be to go to the original source from which you mapped, prettify that, and place the breakpoint there.
Chrome 79.0.3945.88 ; Webpack 4.41.2
Seems like you are clicking the "{ }" (pretty print) icon located in the bottom panel and setting a breakpoints there without attaching a source map of the original file.
When given a .map file, Chrome dev tools and map each line of executed minified code to the original source file using the data in the .map file. Otherwise it will just do it's best to indent/format the minified file.
I suggest you use grunt uglify or similar to minify your js which will automatically generate a map file for debugging. See the following links for more information on how to do this.
http://blog.teamtreehouse.com/introduction-source-maps
Javascript .map files - javascript source maps
How about this?:
Generate the pretty-print version of your "min" version and save using your "min" version name: Substitute the "min" for a pretty "one"
simply put debugger; at top of the js code.
ex:
function add(n1, n2) {
debugger;
let sum = n1 + n2;
return sum;
}
To debug a third-party npm library during local development.
Update package.json from "node_modules[package_name]\package.json"
"main": "dist/package-minified.js" -> "main": "dist/package-formatted.js"
Rebuild your project
You will be able to set a breakpoint to the third-party js library.
Usually, libraries come with both formatted and minified js files. You will find them under node_modules[package_name]
dist/[package-name]-src.js
dist/[package-name]-min.js
Possible to set a breakpoint for the code block of javascript like the screenshot below.
How can we use them? VS always ignores.
If Internet Explorer is set as the browser when debugging, Visual Studio is, in theory, able to stop at breakpoints set at client side script. To use the feature, you will need to make sure that "Disable script debugging" is checked in your IE Internet Options, Advanced tab.
However, I have found VS script debugging to be a bit flaky; the breakpoint is not always hit, especially with VS2010 or earlier. My personal experience is that it works best in VS2012 or later.
That being said, if you're using VS as the client-side script debugger and you find that your client-side breakpoints are not getting hit, it is best to insert a "debugger;" line prior to the line you would like to break at to ensure that it is picked up by the VS script debugger.
pennstatephil posted a link above that indeed provides more information on the subject: http://msdn.microsoft.com/en-us/library/7seh8d72.aspx
Edit: I'm not able to add comments, but in response to sb9's comment about why one would use IE, I find debugging in Visual Studio a lot more convenient when investigating script behavior before postbacks occur and server-side behaviors occurring immediately after postbacks. Also, sometimes the VS/IE combination will catch errors that Chrome and Firefox/Firebug reports with a nonsensical error message.
In Visual Studio 2017 there is an option to enable/disable script debugging
Just enable it and you should be good to go.
There are seemingly infinite possibilities to why this happens. I just solved this problem after hours of searching.
My particular issue is that my breakpoints were disabled immediately after my coworker enabled bundling (see description here). I had to go into our BundleConfig.cs file and comment out the line that said:
BundleTable.EnableOptimizations = true;
After I did that, they were hit. You'd want to add that line back in for deployments.
Another scenario for the inability of the debugger to stop at the break point is if one uses bundling.
To debug JavaScript files, we need to remove bundling.
I hope this will help someone.
Yes you can put the break-point on client side page in Visual studio
First Put the debugger in java-script code and run the page in browser
debugger
After that open your page in browser and view the inspect element you see the following view
My goal is to be able to see which javascript functions have executed since the start of an audit. This is most comparable to me placing a breakpoint at the start of every method in every javascript file that's loaded, and then writing down a list of all the functions who have a breakpoint that was hit.
Does this tool exist? If not, why do developers not need it? I find myself looking at a page, seeing 'something' happening, but not being able to get a handle on what is happening. In a large environment I could see this task becoming insurmountable.
Cheers
Yes. Firebug (for Firefox) is the most popular.
http://getfirebug.com/
Also, IE9 and Chrome... press F12 to bring up the developer window.
With all of the tools mentioned here you can set javascript break points, see the stack, and even profile your scripts.
Check out console.log to help you out -
http://getfirebug.com/wiki/index.php/Console_API
Google Chrome's javascript console (which is some nice visual profiling) -
http://blog.chromium.org/2009/06/developer-tools-for-google-chrome.html