I'm very new to JavaScript, jQuery, and JSON browser debugging. But I do know that the "Sources” tab in chrome dev tools is supposed to let me look at my JavaScript files in the browser so I can set and manage my breakpoints and effectively debug my code.
However, when i press Ctrl + Shift + I to open chrome dev tools, i can't see a list of my javascript files under the Sources tab.
I only something in the form of...
jslib.axd?=jquery-.7.2.min.js,query.validate.min.js,MyRegion.js,MyCountry.js,MyCategory.js
...which looks like a concatenated list of all my javascript files. But what i was expecting to see is a list of each of my javascript files.
Screenshot:
It looks like you have used a compression tool to combine all of your javascript files. What you see is not an error in Chrome - it's just all of your script files combined into one.
If you are still developing, just turn off whatever tool you are using to compress them (at least until you are finished your dev work). This will allow your scripts to load individually on the page.
Then you can use chrome dev tools to see each file listed.
If you want to set a break point. Use 'debugger' in your code like so :
//code here
debugger;
I never use Chrome to debug javascript but i'm sure you can do it easilly. Firebug in firefox is great and you can also debug in Visual studio if you use IE with 'debugger'.
Hope this help.
If you use chrome/firefox just press f12 it will open web development tool
now go to source/script section and select the js file in which you want to add a break point
just click on that line to add break point not run the function it will come to your break point and then you can debug through F10 for singe line and move for next break point press F8
Related
I'm very new to debugging JavaScript, let alone Typescript, let alone a Stencil project that uses tsx files (which I assume are a certain type of reactive Typescript files).
I hoped that by adding a debugger statement into the code, using a refresh in Chrome the Debugging tools would show up. But nothing happens. If I add a console.log at the same place, it behaves as expected. But nothing happens with a debugger statement.
What to do? I don't want to debug with tons of console.log everywhere. 😏
I'm using VSCode by the way. Don't know whether that is relevant. I read in https://github.com/microsoft/vscode-js-debug that JavaScript debugging should be built into VSCode. I don't care whether I debug inside VSCode or inside Chrome - as long as I am able to debug somehow.
Here is the repository, if somebody wants to give it a try or checkout configuration files: https://github.com/NothingAG/adg-components
Thanks a lot.
Instead of adding debugger statements in code you can always add breakpoints in Chrome Developer Tools.
Load your app in the browser
Open Developer Tools in Chrome (for example right-click on a page and choose "Inspect")
In Developer Tools choose tab "Sources"
Open the file you want to debug by hitting command-P. An input field appears where you can enter the name of the file you want to debug
Add a breakpoint by clicking on the line number in the gutter
Next time your app hits the breakpoint the debugger shows up.
Apparently the build tool (nx) runs a production build which is why debugger statements are automatically filtered out.
To fix it you can explicitly instruct Stencil to run a development build:
npm start -- --dev
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.
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
I am attempting to debug a page issue where IE 9 will work the first time on my requirejs/backbone application, but will fail on the page reload. However, when I attempt to debug this problem using the f12 IE developer tools, I cannot navigate to the source to set a breakpoint because IE does not load any of the files that RequireJS includes. How can I get around this issue to fix my IE headache??
I guess I am late for the party but hope my answer helps you and others as well.
The file that you want to debug or the line in the file, simply add this --> debugger;
before that line.
So, when require.js loads your script and encounter that string i.e. debugger; exists it will automatically be stopped at that line.
You can generate a single js File with require tools :
include requirejs in this single file
(http://requirejs.org/docs/optimization.html#onejs)
set optimise to
none (no source minified -
http://requirejs.org/docs/optimization.html#shallow)
In your index.html link this file instead of require.js.
You can debug with IE.
I have the same problem from time to time. What sometimes helps: Close all the files in Debugger view, leave the DevTools open, press Play to allow page to continue and then make your action on the page or reload - if it halts on the debugger; again, all the files will be loaded. But still investigating ;)
I encountered a strange problem today. Whenever i put a breakpoint in one of my js files, the breakpoint is not hit.
I use Visual Studio 2005 in combination with TFS.
In ie the disable script options are both disabled.
The only thing that changed is that I installed Visual Basic 6 for an old project, but I don't see how that would impact debugging via Visual Studio 2005.
Did anyone had this problem before, or better does anyone know a solution?
thx.
In order for Javascript debugging to work the Visual Studio needs to be attached as a debugger to the IE process and it needs to be able to resolve the phyiscal path of the javascript file with the URL of the same script loaded in IE.
Have you checked that when you start debugging in VS that it actually attaches to the IE process that gets spun up?
Customizer your toolbar, on the commands tab select the debug category then find the "Script Explorer" command, drag it to a tool bar. Close the dialog.
Using script explorer you should be able to find the script that ought to have the break point on. Ordinarily VS is able to combine the root path it specifies for the developer web server with the physical JS file path in order to determine what its URL would look like from the browsers perspective, it can then novate the break point from the physical file to the script loaded in the browser.
you can also use a debugger; statement in your js. IE will then prompt you to debug the script file and should give you the option to debug in Visual studio 2005/2008 if you have them.
Explained here
A collegue found the issue: the Just in time debugger was only set to handle Managed and native code, and no scripting.
I just had to re-set it in the visual studio options pane.