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.
Related
My Visual Studio code editor keeps underlining my code incorrectly and I don't know how to stop it.
Here is an example of my JavaScript being squiggled:
I have tried installing prettier, eslint but it does nothing to solve this.
How can I stop these squiggly lines from appearing incorrectly? I want them IF they are correct.
If I click on the problems tab, it shows this:
Solved! Thanks to zscoop98's answer, I was able to find this page which showed there exists an option standard.enable in settings.json that, after setting that from true to false, it solved the issue and there are no longer these annoying red squiggly lines.
And you can uninstall ESLint extension in vs code to get rid of red lines.You can search ESLint extension in extions folder of vscode
I was debugging some code in Chrome and randomly some of the breakpoints I had started showing up like this
The syntax (IMO) would imply that it is breaking on both of those points, but it doesn't. In fact, it doesn't perform any different than a regular breakpoint. But I am left thinking, What is this? Why is it here? How did it appear?
FYI: My Google Chrome is up to date (Version 58.0.3029.110 (64-bit))
EDIT: the second one is clickable and is another breakpoint when clicked but the question still remains. What are they? And why did they just suddenly appear?
The first one is a regular line break. The second one is a break on the call to clearErrorMessage. In this case they're really the same, but if you had chained function calls or nested functions here the multi-line breakpoint becomes incredibly useful.
Is it possible to get a breakpoint when debugging, so that it stops each time when the certain class is accessed, otherwise it runs normally.
It's very common use case when one don't want to stop on jquery functions or other common libs functions, and want rather to stay on a specific js-file, but has no idea of what there could fire a bug, so one don't want explicitly to set a breakpoint on every line in the js file to catch all accesses on that file. Are there any options for Chrome DevTools for that debugging functionality?
Update:
Or maybe there is another way to get the similar functionality by ignoring whole libraries such as jquery, if there should be a breakpoint, so that only other files will be handled with debugger? That would be still not the best solution for the case, but anyway saves much time.
Update2:
the second approach is described here, but I have Chrome 26, and unfortunately cannot update it in the next one-two months, so this feature doesn't work for my browser now.
The only way to do it would be to sprinkle debugger; statements inside your file. At the begining of the file and at the begining of every function body should be enough.
Reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/debugger
You can set conditional breakpoints to in the Sources panel. If you right-click on the line-number gutter it will show you a context menu for different options you can use, one of which is conditional breakpoints.
Like, if(condition) break;
Click Edit Breakpoint to do this
If you know the function(s) being called, you can use function breakpoints
debug(function);
function(...args);
When you call the function, it will hit the breakpoint. These aren't saved on page reload, but you can set a line breakpoint once you hit the function breakpoint.
This can get kinda tedious though.
If you have a array of functions, you can do
[function0, function1].map(debug)
#Tibos answer would be good if there was some sort of babel transform to insert debugger; at the start of every function, instead of inserting it manually.
You press F12 => select Sources => press CTRL+O => entry file name => finaly make breakpoint
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...)
I have been using Eclipse for some weeks now and I start getting used to it.
However, one thing really annoys me:
When editing JavaScript (I didn't try any other language yet), the editor window keeps jumping to the start of the document I am editing.
This mostly happens when the code currently contains syntax errors and mostly while / after deleting lines.
Especially constructs like { = and sometimes unterminated strings / comments seem to cause this problem.
When it happens, only the view scrolls to the top of the document - the cursor stays where it was before the "jump" occurred.
Anyone having an idea on how to fix this?
I believe the problem described above is related to this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318095
The work around is to disable the "Link with Editor" option from the Project Explorer. Which is to say make sure the icon with two arrows facing in opposite directions at the top of the file tree is not enabled. Disabling this option resolved the issue for me.
Looks like a problem with the implementation of the JavaScript editor. Most probably the jump occurs when the JavaScript-Parser is not able to parse your document and throws an exception. You might consider to report a bug to the eclipse project (maybe there is already such a report?).
As a workaround you might consider to adapt your way of typing the code a bit. Try to write the code in a way that does not confuse the parser (for example it might help to immediately close a newly created comment and THEN write the content instead of open the comment, write the content and finally close the commend). Same for strings, blocks ...
I am having the same problem. I had this line of code in my file and I could consistently reproduce the issue:
$.preload(preloadImages
, {
base:assetsUrl+'b/images/',
ext:'.png'
});
I changed it to the following and I no longer have the problem.
$.preload(preloadImages, {
base:assetsUrl+'b/images/',
ext:'.png'
});
I get this Phenomenon, when i'm editing in a Java-Class while still residing in a Debug-Process. The Debugger recognises the Change and reevaluates the Code and jumps back in order to be able to reexecute only the changed Code.
Hii i got solution goto
Window->Preferences->search autosave
and disble it and hit apply and close button.
this worked for me !