We Keep Coding

Chrome DevTools won't let me set breakpoints on certain lines

In the image above, I tried setting breakpoints on every line from line 437 to line 443. However, I cannot set breakpoints on lines 439 and 440. When the function runs, the breakpoints on lines 437, 438, 441, and 442 are ignored. Chrome breaks on line 443. This means that I cannot do some debugging before the first conditional runs.
When I click on lines 439 or 440, the breakpoint appears for half a second and jumps to line 443.
Is this a bug or am I missing something? How do I set a breakpoint at or before line 439?

If you are using js minification and sourcemaps, ensure that they are up to date with your source code.

I have same problem in chrome dev tool source panel snippets when I write some codes to test my idea.
Only way for me worked is close dev tool panel and refresh page then reopen
This problem happened after I modified codes in debug mode

This was frustrating for me today but I found the problem. I was trying to place a breakpoint inside an orphan function (nothing was calling it). As soon as I fixed it, all was well. Smart - but wish there was even a tiny hint that this was the case.

I think that my classmate and I had this issue as well today. We made our changes and then hit Ctrl + S (or Cmd + S) to save the changes in the debugger and then we were able to add the breakpoints.

This recently became an issue for me, running System.js and Babel, and with plain ES6 transpiling, I haven't gotten to minifying/mapping yet. A workaround seems to be to add your breakpoint to the !transpiled file, a matching breakpoint will automagically appear in the corresponding line in the raw file.

In my case, I could not put a break point on the calling function line, but it worked into the function... weird but at least it works.

I just had that problem and realized that what I saw in the dev tools source was not the code that actually ran in the browser.
Make sure you empty your cache and reload and have the up to date code.

My problems where in sourcemaps definitions.
I solved my chrome debugging problems with this article: https://www.mistergoodcat.com/post/the-joy-that-is-source-maps-with-vuejs-and-typescript
I was allmost there, all i had to change was at vue.config.js: devtool: "inline-source-map" -> devtool: "eval-source-map"

In my case it was, most likely, a bug in the devtools. When I clicked to set a breakpoint inside an async function nothing seemed to happen, no visual indication of the breakpoint. Although outside the function it showed the blue mark correctly.
But when I ran the code it turned out that all the breakpoints had been set actually.

In my case, it turned out the function I was trying to add a breakpoint in, was never called but I'm not sure why it didn't allow me to add a breakpoint that would never hit anyway.

Determining why Firebug won't gray/green lines

I'm tearing my hair out here due to Firebug's seeming propensity to refuse to hit breakpoints in critical sections where it would be really, really helpful to be able to step through the code to help see what is going on. I have read elsewhere that Firebug won't hit a breakpoint if the line number isn't the right color: it used to be green, but lately I notice it seems to be the difference between light gray and dark grey, where light-gray lines are the ones the Firebug won't break on.
I am looking for any suggestions as to how to get Firebug to recognize that it should be able to break on a line. Often it will refuse to honor breakpoints on ten or twenty lines in a row, as if it suddenly got confused parsing a function and just gave up until the function was over. In some cases, simply commenting out one line (and then reloading of course) makes Firebug suddenly recognize the rest of the function, but without any rhyme or reason that I can see, even to the point that simply adding something innocuous like an extra semi-colon makes it go back to not recognizing the lines again. In some cases it seems that do/while loops confuse it, but even in a function without such a loop I am currently having trouble.
I have already tried all the other things I could find in other threads, such as resetting all, restarting the browser, using the latest version, etc.
Update: In one case I was able to get Firebug to recognize lines by changing:
do {
...
} while (condition)
to
while (1) {
...
if (!(condition)) break
}
Firefox 23 / Firebug 1.11.4
Update: It seems that whenever I find a section of code like this, I can get the problem to go away by creating a new empty javascript file (adding a reference in the HTML file) and moving the affected function to that file. Suddenly the lines get greened (it's back to green again now, no idea why...)

Javascript firefox issue

I developed a .htm document with an in-built script for javascript to run a program. In google chrome, the program works fine, but I got a beta test complaint that it didn't work on firefox 14.01 or opera. On testing with firefox 14.01, I can confirm it doesn't work (I assumed opera to be the same). I cannot insist the audience upgrade their browsers, as this is supposed to be widely compatible.
Doing a little tracing of the issue, I installed Firebug, which, on clicking the Javascript button to generate a coordinate the first time, it worked (clearly showing the function is defined and exists), but the second time, Firebug complained that:
"ReferenceError: GenerateCoord is not defined".
This wouldn't be so ironic if it only did this after generating an (encrypted) coordinate (thus calling GenerateCoord that is supposedly 'undefined').
If one looks in the code, one can clearly see that the function GenerateCoord is clearly defined before it is called. I would say firefox has an 'onclick' issue, but then it begs the question why did it work the first time I clicked it (calling GenerateCoord via 'onclick') but not the second?
Reloading the file allows the button to work the first time, and the first time only. I am baffled as to how firefox can call a function one time that it then says is undefined the next. Am I missing something here?
Javascript and HTML code can be viewed here:
http://pastebin.com/4qykTfEW
-
How do I solve the problem, and is there an easier solution than re-writing the code to avoid onclick (that seems to work in certain circumstances but not others)?

The problem is that using document.write overwrites the entire HTML page, thus inadvertently removing the GenerateCoord script. I'd suggest appending the link to the document (in ShowTarget) rather than attempting to re-write it.
For example, have a container element where the link should be:
<div id="links_container"></div>
Then to append the links, use:
document.getElementById('links_container').innerHTML = Link;

"SCRIPT5039: Redeclaration of const property" in IE9

This has been asked already, but the solution there did not help me. What does this mean exactly? My regular HTML page uses a "script" tag to load my main_script.js file, where the first thing I do is:
var internetExplorerSucks = 30;
The variable used be be called FPS, but I thought it might have been taken by some random default global, so I renamed it to something that obviously isn't already taken. Still it fails to work. I get this error in the IE debug console:
SCRIPT5039: Redeclaration of const property
main_script.js, line 1 character 1
I tried making it a global by taking out "var", still didn't work. It should be noted that this is not in any function, just literally the first line of code in the file.
Some background: All of this code works perfectly in Chrome, Firefox, and Safari on Windows, OS X and Linux. IE is the only browser this does not work on. This project involves using an HTML5 canvas, which I got to at least display in IE 9 (I am using version 9), but this code does not immediately pertain to the canvas at all. In fact, I cannot seem to declare any variables whatsoever in my main_script.js file. I am able to, however, create functions without running into an error. Is that what I have to do? Put everything in a function (that would involve a lot of moving things around)?
Anyway, thanks for the help.
P.S. Internet Explorer is a nightmare.

I had the same problem in my code and it turn out that IE show wrong line were the redeclaration appear. In my case it was history I use later in the code. You should check whole code for redeclaration of the constants. You can try to comment out part of the code and see when it throw that error.

Javascript: Unresponsive script error

I get an error message from Firefox "Unresponsive script". This error is due to some javascript I added to my page.
I was wondering if the unresponsiveness are caused exclusively by code loops (function calling each other cyclically or endless "for loops") or there might be other causes ?
Could you help me to debug these kind of errors ?
thanks

One way to avoid this is to wrap your poor performant piece of code with a timeout like this:
setTimeout(function() {
// <YOUR TIME CONSUMING OPERATION GOES HERE>
}, 0);
This is not a bullet proof solution, but it can solve the issue in some cases.

According to the Mozzila Knoledgebase:
When JavaScript code runs for longer than a predefined amount of time, Firefox will display a dialog that says Warning: Unresponsive Script. This time is given by the settings dom.max_script_run_time and dom.max_chrome_script_run_time. Increasing the values of those settings will cause the warning to appear less often, but will defeat the purpose: to inform you of a problem with an extension or web site so you can stop the runaway script.
Furthermore:
Finding the source of the problem
To determine what script is running too long, click the Stop Script button on the warning dialog, then go to Tools | Error Console. The most recent errors in the Error Console should identify the script causing the problem.
Checking the error console should make it pretty obvious what part of your javascript is causing the issue. From there, either remove the offending piece of code or change it in such a way that it won't be as resource intensive.
EDIT: As mentioned in the comments to the author of the topic, Firebug is highly recommended for debugging problems with javascript. Jonathan Snook has a useful video on using breakpoints to debug complex pieces of javascript.

We need to follow these steps to stop script in Firefox.
Step 1
Launch Mozilla Firefox.
Step 2
Click anywhere in the address bar at the top of the Firefox window, to highlight the entire field.
Step 3
Type "about:config" (omit the quotes here and throughout) and press "Enter." A "This might void your warranty!" warning message may come up; if it does, click the "I'll be careful, I promise!" button to open the page that contains all Firefox settings.
Step 4
Click once in the "Search" box at the top of the page and type "dom.max_script_run_time". The setting is located and displayed; it has a default value of 10.
Step 5
Double-click the setting to open the Enter Integer Value window.
Step 6
Type "0" and click "OK" to set the value to zero. Firefox scripts now run indefinitely, and will not throw any script errors.
Step 7
Restart Mozilla Firefox.

Excellent solution in this question: How can I give control back (briefly) to the browser during intensive JavaScript processing?, by using the Async jQuery Plugin. I had a similar problem and solved it by changing my $.each for $.eachAsync

there could be an infinite loop somewhere in the code
start by commenting out codes to identify which section is causing it
too many loops: there might be a chance that your counter variable name clashes, causing the variable to keep resetting, causing the infinite loop.
try as much as possible to create hashes for your objects so much so that read time is O(1) and in a way caching those data
avoid using js libs as some of the methods might cause overheads. eg. .htm() vs .innerHTML
setTimeout() yes and no -- depends on how you chunkify your codes