IntelliJ underline in red every error reported by JSLint and I can see the respective indications on the rightmost margin of the document.
However, I would like to see all of the jslint errors in one window and be able to navigate from error to error.
Is it possible?
Thanks.
Run Analyze | Inspect Code with the JSLint code inspection enabled in the profile.
Related
I don't know anything about javascript but I can't get these two scripts to work together, if anyone could fix my mistakes I'd be very grateful. The scripts are premade from http://www.mf2fm.com/rv/ and function just fine on their own. I've tried to solve the issue myself but I'm unfortunately entirely clueless. I got this error when I tried to test running what I pasted below on a test site; "JavaScript error: Uncaught TypeError: Failed to execute 'appendChild' on 'Node': parameter 1 is not of type 'Node'. on line 48" Line 48 being: document.body.appendChild(stars[j]); if that's any help. The problem seems to be localized to these lines, though they run fine without the second script.
addLoadEvent(clicksplode);
function clicksplode() { if (document.getElementById) {
var i, j;
window.onscroll=set_scroll;
window.onresize=set_width;
document.onclick=eksplode;
set_width();
set_scroll();
for (i=0; i<bangs; i++) for (j=sparks*i; j<sparks+sparks*i; j++) {
stars[j]=createDiv('*', 13);
document.body.appendChild(stars[j]);
}
}}
Well, for one thing, you're copying a script that dates back to 2002 at the very latest. These belong in a museum. I had a whole nostalgic flashback to the 90s loading up that site from your source code.
The error you're getting is that value of stars[j] is not a DOM Node, so appendChild() doesn't know what to do with it.
Since it seems like you're already familiar with the dev console, I'd suggest putting a breakpoint in at that line 48 where you see your error and seeing what is actually being passed to appendChild(). Then you can walk up the stack trace to see where that bad value is coming from. You can also, in chrome dev tools, turn on "pause on exceptions" to automatically stop your code in the debugger when an error is thrown. It's the icon of a pause button in a circle in the upper right of the source tab in the chrome debugger.
Best of luck!
When debugging JavaScript code using Chrome Developer Tools the debugger pauses on code where breakpoints are not set. I don't have the Pause on exceptions feature enabled, and there definitely are not breakpoints set (see attached image).
I asked a similar question before which was helpful but didn't quite solve this issue (previously I had the Pause on exceptions enabled). In the example below I swapped out the minified version of kendo.all.min.js for the unminified version, which allows me to see where the script execution is being paused, but I don't know why it is being paused. This happens a lot with jquery.min.js too.
I fixed my breakpoints problem by clicking the "Restore defaults and reload" button located in the “Settings” section. To find the button: In Developer Tools click the cogged wheel next to the top right three vertical dots. (Note: If using older versions of Google Chrome, click on the top right three vertical dots and then select “Settings F1”). The button “Restore defaults and reload” is at the bottom right.
Also note that it really restores defaults - you lose all previously saved breakpoints and any files you have open in Developer Tools will be closed.
I got this solution from: Chrome javascript debugger breakpoints don't do anything?
Accepted answer to Import/export Chrome devtools breakpoints & settings between computers reminded me to check "devtools-on-devtools" and in the DevTools' inner Application Local Storage remove the faulty element(s) of the JSON list value for key breakpoints to fix my same issue without resetting everything.
Later it happened again, so I wrote this console snippet:
((stores, matchKey, removeMatchingRegExp, dryRun)=>{for(let store of stores){
let r = JSON.parse(localStorage[store]), l = r.length;
r = r.filter(b=>!b[matchKey].match(removeMatchingRegExp));
if(!dryRun) localStorage[store] = JSON.stringify(r);
console.log(`${dryRun ? 'Would' : 'Did'} remove ${l - r.length} entries from ${store}:`, r)}; return 'OK'})
(['breakpoints', 'domBreakpoints'], 'url',
new RegExp('^https?://example.com/script.js$'), true)
Note:
Provided without warranty: Use at own risk. Backup your data.
Edit it - at least the RegExp argument - to suite your needs.
The last-most boolean should be false to disable dryRun.
Outer DevTools must be reopened for effect.
I was able to resolve this by updating Chrome. I don't think the version matters, just the process of updating resets all of the breakpoints that have been stored in the cache.
F8 has two functionalitys. 1. Skip ot next Breakpoint, 2.stop wherever the Browser is executing code. This works even if you have no breakpoint set. For example spamming F8 when you forgot to deactivate breakpoints might cause the browser to stop anywhere.
When you go to the debugger shortcuts you can see that F8 has the functionality to Pause / Continue. But it sadly seems like you can't split them on two different keybinds.
Since I know this feature I never ran into this "bug" anymore.
I'm posting this answer in case it will help someone who, like me, missed an important clue as to the cause of the phantom breakpoint behavior. In my case, it was "user error" --mine. The root cause was a forgotten "debugger;" statement in a JavaScript file that was itself generated from TypeScript. I had removed the debugger; statement from TypeScript locally, run and tested without issue from localhost. But I had pushed the version with the statement to remote and it built and released to our dev site with the statement present. The dev site build excludes the TypeScript source files. When the debugger statement was hit, Chrome tried to load the .ts source and displayed "Could not load content..." I just assumed it was at a breakpoint (I'd set many during testing). And when I saw "No breakpoint" I assumed Chrome was experiencing the issue addressed in this thread. If I'd bothered to look in the Call Stack trace, I would have seen the source code line in the .ts file and pretty quickly figured it out. Here's a screenshot:
just disable the cache and reload the page, the breakpoints will show up again
I'm having a problem where all my javascript errors appear to be coming from dojo.xd.js or a sub-module. I'm using chrome debugger and many dijit features such as dijit.declaration and dojo.parser.
This is a bit annoying as it makes it hard to locate simple errors or slip ups. I'm hoping I can add an option that allows my debugger to show where in my non-dojo code a option would occur.
I'm new to dojo so I might be making a simple mistake.
Example error from what should be a nullpointexception in non-dojo code:
typeError
dojo.Deferred.reject.errback dojo.xd.js:14
Errors that occur inside deferred and async chains are handled by Dojo and that can confuse the error messages a bit.
If you are using the chrome debugger you can tell it to immediately halt the program execution whenever an exception occurs by clicking on the "stop sign" in the "Script" tab until it turns blue.
I think missingno's suggestion is a good one (worth a try - I haven't used the method).
Also, another way I've used to get at the erroring code is:
Set a breakpoint in the dojo code where the error is showing
Use the stack breadcrumb navigator and move backwards into the
code that threw the error
In Firebug, the stack navigator is just above the script listing that shows the breakpoint.
I've been using Firebug to debug some javascript I have on one of my pages. Recently it has started hitting non-existent "break points" at seemingly random spots in my javascript. It seems like most of these points are in third party libraries like jQuery, but it also stops on custom javascript.
I'm not seeing any errors at these lines and I definitely don't have break points there. Can anyone think of why Firebug would be stopping here? It's getting to the point where I have to hit the "Continue" button about 20 times to get the page to finish Javascript execution...
I had this problem and fixed it like so:
Uninstall firebug in the firefox add-ons manager
Close firefox
rm -rf profile_folder/firebug
Delete all firebug-related lines from profile_folder/prefs.js
Reinstall firebug
Hope this helps!
There is nothing wrong with firefox, this is happening because you might have enabled auto breakpoints. Check here http://getfirebug.com/wiki/index.php/Script_Panel for more details about what i am talking about. Disable them on console and script panel and everything will be solved.
This question is old, but it is also the top result for searches: like firebug random breakpoints.
In my experience, assuming this is not due to break on exception or other settings, every time this happens to me there is some collision with jQuery, or another library. Sometimes even name spacing does not keep you safe, and this is very hard to debug.
Most recently I had a function named: name_space1.nestedns.focusCursor(). Something was messing with my focusCursor function.. didn’t figure out what, just changed the name.
Farther in the past I had a function or var named ns.companyabreviationToolTip... and there was collision and breaking on this as well. Changed ToolTip to something obscure, and everything was happy. Maybe firebug has a secret break on collision setting. If this is a bug, I hope it does not get fixed… it seems useful.
In our application we have a lot of JavaScript functions and sometimes an "[object Error]" alert comes out from nowhere when using IE7. It happens sometimes. The problem is that I can't figure out which exact function is causing that error. Any hint on how I can debug this?
Thanks.
If you are using IE, then when there is an error in your JavaScript code, there will be an error indicator on the left bottom of the browser window, you can click it to see which line of the JS code goes wrong
base on this article, it is a bug in IE7
Go to the Developer Tools debugger and select Break on Error.