We Keep Coding

ajax not work inside callback of upvote (jquery plugin) [duplicate]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
When I find that I have a problematic code snippet, how should I go about debugging it?

Firebug is one of the most popular tools for this purpose.

All modern browsers come with some form of a built-in JavaScript debugging application. The details of these will be covered on the relevant technologies web pages. My personal preference for debugging JavaScript is Firebug in Firefox. I'm not saying Firebug is better than any other; it depends on your personal preference and you should probably test your site in all browsers anyway (my personal first choice is always Firebug).
I'll cover some of the high-level solutions below, using Firebug as an example:
Firefox
Firefox comes with with its own inbuilt JavaScript debugging tool, but I would recommend you install the Firebug add on. This provides several additional features based on the basic version that are handy. I'm going to only talk about Firebug here.
Once Firebug is installed you can access it like below:
Firstly if you right click on any element you can Inspect Element with Firebug:
Clicking this will open up the Firebug pane at the bottom of the browser:
Firebug provides several features but the one we're interested in is the script tab. Clicking the script tab opens this window:
Obviously, to debug you need to click reload:
You can now add breakpoints by clicking the line to the left of the piece of JavaScript code you want to add the breakpoint to:
When your breakpoint is hit, it will look like below:
You can also add watch variables and generally do everything that you would expect in a modern debugging tool.
For more information on the various options offered in Firebug, check out the Firebug FAQ.
Chrome
Chrome also has its own in built JavaScript debugging option, which works in a very similar way, right click, inspect element, etc.. Have a look at Chrome Developer Tools. I generally find the stack traces in Chrome better than Firebug.
Internet Explorer
If you're developing in .NET and using Visual Studio using the web development environment you can debug JavaScript code directly by placing breakpoints, etc. Your JavaScript code looks exactly the same as if you were debugging your C# or VB.NET code.
If you don't have this, Internet Explorer also provides all of the tools shown above. Annoyingly, instead of having the right click inspect element features of Chrome or Firefox, you access the developer tools by pressing F12. This question covers most of the points.

Internet Explorer 8 (Developer Tools - F12). Anything else is second rate in Internet Explorer land
Firefox and Firebug. Hit F12 to display.
Safari (Show Menu Bar, Preferences -> Advanced -> Show Develop menu bar)
Google Chrome JavaScript Console (F12 or (Ctrl + Shift + J)). Mostly the same browser as Safari, but Safari is better IMHO.
Opera (Tools -> Advanced -> Developer Tools)

There is a debugger keyword in JavaScript to debug the JavaScript code. Put debugger; snippet in your JavaScript code. It will automatically start debugging the JavaScript code at that point.
For example:
Suppose this is your test.js file
function func(){
//Some stuff
debugger; //Debugging is automatically started from here
//Some stuff
}
func();
When the browser runs the web page in developer option with enabled debugger, then it automatically starts debugging from the debugger; point.
There should be opened the developer window the browser.

I use old good printf approach (an ancient technique which will work well in any time).
Look to magic %o:
console.log("this is %o, event is %o, host is %s", this, e, location.host);
%o dump clickable and deep-browsable, pretty-printed content of JS object. %s was shown just for a record.
And this:
console.log("%s", new Error().stack);
gives you Java-like stack trace to point of new Error() invocation (including path to file and line number!!).
Both %o and new Error().stack available in Chrome and Firefox.
With such powerful tools you make assumption whats going wrong in your JS, put debug output (don't forget wrap in if statement to reduce amount of data) and verify your assumption. Fix issue or make new assumption or put more debug output to bit problem.
Also for stack traces use:
console.trace();
as say Console
Happy hacking!

Start with Firebug and IE Debugger.
Be careful with debuggers in JavaScript though. Every once in a while they will affect the environment just enough to cause some of the errors you are trying to debug.
Examples:
For Internet Explorer, it's generally a gradual slowdown and is some kind of memory leak type deal. After a half hour or so I need to restart. It seems to be fairly regular.
For Firebug, it's probably been more than a year so it may have been an older version. As a result, I don't remember the specifics, but basically the code was not running correctly and after trying to debug it for a while I disabled Firebug and the code worked fine.

Although alert(msg); works in those "I just want to find out whats going on" scenarios... every developer has encountered that case where you end up in a (very large or endless) loop that you can't break out of.
I'd recommend that during development if you want a very in-your-face debug option, use a debug option that lets you break out. (PS Opera, Safari? and Chrome? all have this available in their native dialogs)
//global flag
_debug = true;
function debug(msg){
if(_debug){
if(!confirm(msg + '\n\nPress Cancel to stop debugging.')){
_debug = false;
}
}
}
With the above you can get your self into a large loop of popup debugging, where pressing Enter/Ok lets you jump through each message, but pressing Escape/Cancel lets you break out nicely.

I use WebKit's developer menu/console (Safari 4). It is almost identical to Firebug.
console.log() is the new black -- far better than alert().

My first step is always to validate the HTML and to check syntax with JSLint. If you have clean markup and valid JavaScript code then it is time for Firebug or another debugger.

Visual Studio 2008 has some very good JavaScript debugging tools. You can drop a breakpoint in your client side JavaScript code and step through it using the exact same tools as you would the server side code. There is no need to attach to a process or do anything tricky to enable it.

I use a few tools: Fiddler, Firebug, and Visual Studio. I hear Internet Explorer 8 has a good built-in debugger.

I used to use Firebug, until Internet Explorer 8 came out. I'm not a huge fan of Internet Explorer, but after spending some time with the built-in developer tools, which includes a really nice debugger, it seems pointless to use anything else. I have to tip my hat to Microsoft they did a fantastic job on this tool.

You might also check out YUI Logger. All you have to do to use it is include a couple of tags in your HTML. It is a helpful addition to Firebug, which is more or less a must.

I found the new version of Internet Explorer 8 (press F12) is very good to debug JavaScript code.
Of course, Firebug is good if you use Firefox.

Besides using Visual Studio's JavaScript debugger, I wrote my own simple panel that I include to a page. It's simply like the Immediate window of Visual Studio. I can change my variables' values, call my functions, and see variables' values. It simply evaluates the code written in the text field.

I'm using Venkman, a JavaScript debugger for XUL applications.

In addition to Firebug and browser-native developer extensions JetBrains WebStorm IDE comes with remote debug support for Firefox and Chrome (Extension required) built in.
Also supports:
coffescript: how to debug coffeescript in node.js with webstorm 6 source maps
node.js
Options to test this for free are the 30 trial or using an Early Access Version.

If you are using Visual Studio, just put debugger; above the code you want to debug. During execution the control will pause at that place, and you can debug step by step from there on.

As with most answers, it really depends: What are you trying to achieve with your debugging? Basic development, fixing performance issues? For basic development, all the previous answers are more than adequate.
For performance testing specifically, I recommend Firebug. Being able to profile which methods are the most expensive in terms of time has been invaluable for a number of projects I have worked on. As client-side libraries become more and more robust, and more responsibility is placed client-side in general, this type of debugging and profiling will only become more useful.
Firebug Console API:
http://getfirebug.com/console.html

By pressing F12 web developers can quickly debug JavaScript code without leaving the browser. It is built into every installation of Windows.
In Internet Explorer 11, F12 tools provides debugging tools such as breakpoints, watch and local variable viewing, and a console
for messages and immediate code execution.

IE 8 debugger doesn't stop on TypeError

I'm trying to get an angular.js/jQuery app running in IE8. I mostly have things working, but it spews a lot of console errors:
TypeError: 'undefined' is null or not an object
These errors in the developer tools don't have a source location (file & line) associated with them, and the debugger doesn't break on errors when these are being thrown, even if "Break on Error" is enabled.
Other than disabling portions of my code to search for the cause, is there any way to figure out where this is coming from? I'm getting dozens of them in every Angular digest cycle, so it's not as straightforward as figuring out what page actions cause them.
It's not obvious what, if anything, they're breaking on the page, but I haven't yet had the ability to test the whole thing, so it's hard to conclude they're benign; even if they are, I'd prefer to get rid of them; they're noisy and I'm concerned that they may be visible to the user under some IE error-handling configurations.

Though I've never used it, I've heard that DebugBar is an improvement over the standard IE8 developer tools.
Also, as JJZabkar mentioned in the question comments, Angular versions below 1.3 require certain shims to be in place to work with IE8 or below.
Another thing to be aware of, which is also described at that link he provided (https://docs.angularjs.org/guide/ie), is IE8's lack of support for custom element tags, which will foil any use of element-based directives (possibly causing errors) if you do not take certain measures.

Viewing the updated HTML in ie6

I am working with ie6 (unfortunately) and i am having a javascript error. Its wondrous error message gives me a line in the html source, but unfortunately the javascript that does run changes the code for the page(dramatically). So the error that its pointing me to is a closing div tag, not actual code.
Is there a way to view the updated code for the page so I can at least know where my code is breaking?
I should also point out what im developing in.
I am developing a sharepoint 2007 solution for an winxp and ie6 user base. I am working via remote desktop on a sandbox winserver 2008 r2 and can access the site from my terminal. Now, unfortunately in my sandbox server i have ie 8 in which my code works. So im stuck on ideas. If anyone knows how to view the updated source on the page, i would be very grateful.
Thanks.
Edit. I should also mention i dont have admin access on my terminal. So i cant install visual studio. It would take a couple weeks for an issue ticket for temp admin access to install it, and this is sort of important.

If you can't install anything and the error console information isn't meaningful, then about all you can do is start modifying your code until you can find which section is causing the error. The kinds of modifications you can do are as follows:
Comment out a chunk of code in a way that won't cause more errors. If the error goes away, then you know it's in that block of code or something that code calls. Put that block back in and then comment out a piece of it and so on until you narrow down where the problem is.
Start inserting alert("1"), alert("2") prompts into your code with the goal of identifying which alert the error comes before and after until you've eventually tracked down where it is. When you rule out an area, remove the alerts to make it feasible to still run the app.
On a more modern computer (e.g. Vista/Win7) go to Microsoft's site and download both Microsoft Virtual PC and the Windows image for XP with IE6. You can then actually install things into the VM and do real IE6 debugging or at least see what the actual error is.
Find a computer with XP/IE6 on it that you can install real debugging tools on.
Build your own dummy little debug window using a textarea and a couple functions that append text to it. Put that into your browser page and start sprinkling mydebug("Entering function foo") statements throughout your code so you can narrow down which statements occur before and after the error and eventually find the error. This is how I've done some IE6 debugging when it was't worth the trouble of setting up a full-blown debug environment for IE6. This works much better than alerts for some types of problems because it doesn't interrupt the flow of the app or require lots of user intervention and you can scroll back through the history.

If you are using visual studio you can use it to debug js errors in ie.
Go to the Advanced Internet settings in ie and make sure that the two
Disable script debugging settings are turned off (so that script debugging is enabled)
and that the setting
display a notification on every script error is enabled.
If you don't have visual studio installed you can download and install microsofts script debugger (it's free just google it) and use that, tho it is not as easy to work with and won't give you as much useful information

debugging javascript for IE6

firebug is quite useful tool that I can't think myself living without it. I also downloaded the js file that helps you get similar functionality when using IE6 hoping it would help me resolve some issues, however, the messages I receive are not quite friendly such as:
"Expected ':' (default2.aspx,16)" - on line 16 there is nothing that can possibly expect a ":"
or
"Object doesn't support this property or method (default2.aspx,198)" on line 198 nothing interesting that can require any support for anything.
my site looks like a different web site in IE6.. most of the css doesnt work, some of the jquery functions doesnt work and I need to get this site work in IE6. Any help would be appreciated in terms of;
how to know what the messages (like the ones above) mean in IE6 and how to effectively debug js in IE6?
where to start for css compatibility.. e.g. shall I create different css files for different browsers and load them by detecting the browser? or are there any common issues and hacks?
I am lost so please give me any direction to start..

You debug javascript in IE6 with:-
Microsoft Script Debugger
The QuirksMode website is useful site to determine which bits of CSS is implemented in what way by which browser. Note IE6 "standards" mode rendering is notoriously buggy.

You can try Companion JS. It is pretty good with respect to debugging. It requires Microsoft Script Debugger as well.
Companion JS thankfully supports "console.log" (via firebug). It is free tool. Debug-bar is a good CSS-DOM-Javascript debugger, but it is not free for commercial purposes.

The two tools I use are:
Web Development Helper
IE Developer Toolbar
They somewhat duplicate each other's functionality, but each one can be useful for different tasks. The Web Development Helper has a built in JavaScript console, it's not as good as Firebug but it's better than nothing and easier than the MS Script Debugger.

"Expected ':' (default2.aspx,16)" - on line 16 there is nothing that can possibly expect a ":"
The error won't be on line 16 of your .aspx file, probably not even on line 16 of the HTML source the aspx file produces. It'll be near line 16 of one of your linked .js files. Which one? IE won't tell you.
You could find out by adding extra lines at the start of each .js file and seeing what happens to the error line number, but it's probably better just to install Script Debugger already.
IE8 finally fixes this.
shall I create different css files for different browsers and load them by detecting the browser? or are there any common issues and hacks?
Start with standards-compliant CSS, and a Standards Mode doctype, and test in Firefox 3, or Opera, Safari, Chrome. Mostly they'll give you more or less the same results. Now test in IE7 and hopefully it'll just work.
The troublesome browser today is IE6. You may well need to add hacks for it. You can do this in a separate stylesheet if there's a lot of them, or just use the "* html" hack for the occasional rule.
All the older hacks, your Box Model Hacks and so on, you can forget about. They're only of use for IE5, which is dead, and IE6 Quirks Mode, which you shouldn't be using.

or have an AJAX call to send debug variables/messages to ASP (PHP) script that will log it. this will help if the problem is with variables undefined or having similar issues.

For what it's worth, I've found the line number errors are much more accurate when using a separate js file.
I still use IE6 as my primary browser when developing. It saves a lot of headaches later, since you will often find CSS issues much earlier in the process.
I also find it helpful to use a JavaScript logger to send debug messages. This being an alternative to a bunch of alert messages. Personally, I use the yahoo UI logger

I use one of two things for js debugging: Microsoft Script Editor or Firebug Lite. Go here for more info.
As for the CSS, I recommend a CSS Reset. And for the little differences in IE6, consider using conditional comments.
When making an an application to be used in multiple browsers, quirksmode is a lifesaver.
EDIT: blackbird is a nice cross-browser tool for tracking state.

I've used MS Script Debugger with some success, also IE Developer Toolbar and Firebug Lite. I recently learned about MS Visual Web Developer Express Edition, which has been a big improvement so far.

Permission denied to call method Location.toString

I'm using YUI,
and sometimes I'll see this "Permission denied to call method Location.toString" error,
It's reported in connection.js,
I didn't find any clue why this error occur yet.
Very strange

If you are dealing with any Flash through a cross-domain iframe, then it is quite possible that you are seeing a bug in Adobe's Flash Player that occurs with FF2 and FF3.
The bug is in Adobe's public JIRA here: http://bugs.adobe.com/jira/browse/FP-561
There seems to be no motivation to get it fixed, unfortunately.

If the script is executed from a different domain, or you are trying to access the contents of a frame/window/iframe of a different domain, you will see this error. Safari's behavior was a little different, at least in the v1-2 era (iirc), so you will probably want to test in that as well.
If you are including scripts via a different domain, you need to make sure your actual triggers/events are tied in and executed from inline scripts, or from a script file loaded from the same domain as your html for best results.

Hi I've answered a similar question
why/where the error “Permission denied for to call method Location.toString”.
This is caused by firebug showing errors from other windows in your console. In short, these errors will probably be nothing to do with your code at all.
If you want to test this theory, you can close all other windows in firebug, clear your console and test just your site.

Are you seeing this in Firebug, by any chance?
I'm getting the same thing in Firefox, off-and-on, after adding jQuery to my site. I'm calling the jQuery js from another site (different domain completely), which I figure isn't much different than calling it from Google's servers.
I have no code using jQuery at all as of the moment. And, while Firebug reports this as an error, it doesn't do so all the time. While I have it turned on, I'm seeing no errors in IE.
While there are different libraries involved, my guess is that Firebug is generating a false-positive.
Now if you're not using Firebug when you see this ... are you using YUI hosted on your own server? What browser are you using? Etcetera.
~James