I can't seem to figure out the Chrome debugging tool.
I have chrome version 21.0.1180.60 m.
Steps I took:
I also noticed that the Watch Expressions don't work either. It keeps telling me that the variable that I want to watch is undefined.
Further testing found that it's my code that's causing the breakpoint to fail. It seems that it fails on the "$("#frmVerification").submit(function(){" line. It doesn't step into the breakpoints inside that function().
Below is the:
//function to check name and comment field
var test = "this is a test";
var test2 = "this is another test";
function validateLogin(){
//if(userEmail.attr("value") && userPass.attr("value"))
return true;
//else
//return false;
}
//onclick on different buttons, do different things.
function ajaxRequest(){
}
$(document).ready(function(){
//When form submitted
$("#frmVerification").submit(function(){
var username = $("#username");
var token = $("#token");
var action = $("#action");
var requester = $("#requester");
if(validateLogin()){
$.ajax({
type: "post",
url: "verification.php",
data: "username="+username.html()+"&token="+token.val()+"&action="+action.val()+"&requester="+requester.val(),
success: function(data) {
try{
var jsonObj = $.parseJSON(data); //convert data into json object, throws exception if data is not json compatible
if(jsonObj.length > 0){//if there is any error output all data
var htmUl = $('<ul></ul>');
$.each(jsonObj, function(){
htmUl.append('<li>' + this + '</li>');
});
$("#errOut").html(htmUl);
}else{
alert("Your account is now activated, thank you. If you have already logged in, press OK to go to the home page. If not, you must log in first.");
window.location.replace("home.php");
}
}
catch(e){//if error output error to errOut]
$("#errOut").html("PHP module returned non JSON object: <p>"+data+"</p>");
}
}
});
}
else alert("Please fill UserName & Password!");
return false;
});
});
This question is related to
javascript
debugging
google-chrome
Make sure you are putting breakpoint in correct source file. Some tools create multiple copies of code and we try on different source file.
Solution: Instead of opening file using shortcut like Ctrl+P
or Ctrl+R
, open it from File Navigator. In Source tab, there is icon for it at left top. Using it we can open correct source file.
I had the same issue in a 10K line file. The breakpoints were being ignored,
hard coded _debugger statements worked, but they can't be toggled and can be annoying when placed in a loop.
My solution, which is a bit of a hack but it works is to add the following to the top of the file:
let myDebuggerFlag = false;
let myDebugger = function () {
if (myDebuggerFlag) {
debugger;
}
}
then I add a myDebugger(); inline where I would usually use a breakpoint.
to turn debugging on i simply enter myDebuggerFlag = true; on the console line. (you have to step out of myDebugger first of course.
I need my damn breakpoints! Very strange behavior - the normally red spot in Sources was going grey; these and debugger;
breakpoints would still appear to hit but show somewhere in some non-executable HTML.
After a couple hours of hacking away code the breakpoints were finally being hit correctly, however had more or less just the equivalent of "Hello World" left. Hahaha.
So I had some serverside data being output in the page (in my case in a @razor statement), but it would be the same in any similar case.
There was some incorrectly formed 0A/0D chars in the server output - the old carriage returns - causing Chrome the confusion with its own line numbering.
Cleaning the server injected HTML and I got my breakpoint.
Now let's see how much of this code I can CTRL-Z back...
Pretty late answer but none of the above helped my case and was something different
while referring the javascript file type="text/javascript" was missing in the legacy application i was working
<script src="ab.js" ></script>
below one worked and breakpoints were hitting as expected
<script src="ab.js" type="text/javascript"></script>
This may be a Chrome bug. Unfortunately Chrome routinely breaks debugging. It often has some kind of memory leak and it often breaks or changes every few releases.
Debugging with formatted sources is currently extremely unreliable.
It's possible you're also trying to break on dead code.
To be certain it's not the browser you should also try to debug it in firefox.
make sure that you have opened javascript console(or sources) in your chrome window. otherwise it will never hit the breakpoint. you can open javascript console by option button in right upper corner-->tools-->javascript console.
I'm not sure how it worked, but hitting F1 for settings and at the bottom right, hitting "Restore defaults and reload" worked for me.
I had a minifier that was stripping out debugger
statements ¯_(?)_/¯
I'll add yet another random answer just because this question came up in response to my several searches. I have jQuery objects that have public and private methods. The pattern is:
myObject = (function($){
function publicFunction() {}
function privateFunction() {}
return {
theOnlyMethod: publicFunction
}
})(jQuery);
If I put a breakpoint on a line inside a private function, Chrome will not debug it, the line moves down to the return statement! So to debug, I have to expose the private functions! This is new to me this morning (8/20/2020, Version 84.0.4147.125 (Official Build) (64-bit)), I can't believe I've not run into this in 3 years.
My solution was to clear the Local Storage, Session Storage, and Cookies from the Applications tab. After that, Chrome would pause script execution on the breakpoints defined in Sources.
This is a late answer, but I had the same problem, but the answer was different.
In my case, there was a sourceURL reference in my code:
//@ sourceURL=/Scripts/test.js
When this Javascript file is minified and loaded by the browser, it normally tells Chrome Dev Tools where the unminified version is.
However, if you are debugging the unminified version and this line exists, Chrome Dev Tools maps to that sourceURL path instead of the "normal" path.
For example, if you work locally on a web server, then in the Sources tab in Chrome Dev Tools, the path to a given JS file will be http://localhost/Scripts/test.js
If test.js has this at the bottom
//@ sourceURL=/Scripts/test.js
then breakpoints will only work if the file path is /Scripts/test.js
, not the fully-qualified URL of http://localhost/Scripts/test.js
In Chrome 38, staying with my example above, if you look at the Sources tab, every file runs off http://localhost/
, so when you click on test.js, Chrome loads up http://localhost/Scripts/test.js
You can put all the breakpoints you want in this file, and Chrome never hits any of them. If you put a breakpoint in your JS before it calls any function in test.js and then step into that function, you will see that Chrome opens a new tab whose path is /Scripts/test.js
. Putting breakpoints in this file will stop the program flow.
When I got rid of the @ sourceURL
line from the JS file, everything works normally again (i.e. the way you would expect).
I met this several times, at first it works well by localhost, suddenly, the breakpoints don't work, i switch to 127.0.0.1, then it works again. Hope helps.
Make sure that you're using the same host in the URL that you were when you set up the mapping. E.g. if you were at http://127.0.0.1/my-app
when you set up and mapped the workspace then breakpoints won't work if you view the page via http://localhost/my-app
.
Also, thanks for reading this far. See my answer to the Chromium issue here.
I encountered similar problems in both chrome and firefox though it may not be the solution for your issue. Am sharing here in the hopes it may help others. I have encountered this situation before in other unrelated projects but never understood why until it cropped up again today.
Scenario:
I have one page that uses two bootstrap modals that come from the same source and one set of javascript files (blueimp's awesome jquery fileupload).
BS Modal 1 is rendered on page load (via php) and is always present on the page. It is used for adding a new related record. (CakePHP....think SalesForcey type stuff)
BS Modal 2 is used for editing existing related records and it's html content is pulled in from an ajax call and appended to the DOM via jQuery.
Javascript supporting both modals included via standard html <script>
tags.
I noticed that breakpoints are only triggered on Modal 1. They do not work when the code is being executed on the dynamically added Modal 2, even though it is quite obvious that the code is indeed being evaluated and run. Alert boxes pop up, codey type things get executed and output follows the logic set forth in the code.
I have not dived deeper to investigate further because I'm pressed for time, but wanted to put it out there and give back to the community.
PS: I use SO all the time, but this is my first post, so go easy on me :-)
So, in addition to Adam Rackis' answer, if you have errors in your javascript file above the breakpoint, you won't reach it regardless if you flag it, or put in debugger;
.
Here's an example:
if (nonExistentVar === "something") {
console.log("this won't happen as the above errors out");
}
debugger;
console.log("this won't print either")
I had an issue where Chrome's breakpoints weren't firing anything. When I tried to use 'debugger' in my code, I could only step through the code in the VM version of my code. My issue was that I was mapping the resources incorrectly. Re-mapping fixed my problem.
I got a similar problem. Breakpoints where not working unless I used debugger;
. I fixed my breakpoints problem with "Restore defaults and reload". It's located in the Chrome Developer Tools, Settings, Restore defaults and reload.
Probably this bug https://code.google.com/p/chromium/issues/detail?id=278361
This is reproduced with my Chrome 31.0.1650.57 (Official Build 235101) on Linux.
I'm restarting browser to fix it.
Source: Stackoverflow.com