I'm trying to debug a Javascript error which only occurs in Internet Explorer. I have Microsoft Script Debugger installed, and have used it successfully in the past. On this error, though, I select "Yes" to do-you-want-to-debug?, and it opens up Script Debugger, which displays nothing. Running documents window is empty, call stack is empty, as though nothing is being debugged.
Can anyone tell me what causes this?
I've had these sorts of issues before with the Microsoft Script Debugger but never managed to find a solution - if you have a license the script debugger inside Visual Studio 2008 is far far better.
There is an article here about how you can use VS 2008 Express (free) as a script debugger.
I've seen this issue with code inside a try/catch/finally block--for some reason the debugger gets confused by the finally block. Try commenting them out.
I know this is old but I thought I would point out that this is still an issue. Microsoft plain sux. Developers are being forced to support products that are broken....this is a crime
Related
[RESOLVED]
I get this error message when I click on the Check Accessibility icon on the CKEditor toolbar: t(...).closest is not a function. I see this message when I use the Firefox debugger.
The version of A11ychecker I am using was last updated, 30 Mar 2018.
This error occurs on line 3119 of plugin.js, which reads: expected: t(this).closest(".quail-test").data("expected").
I have tested this issue using the following versions of CKEditor: 4.5.10 and 4.9.2.
For me, the issue occurs every time the Check Accessibility button is clicked AND an accessibility issue exists. If no accessibility issues exist, Firefox does not display an error. It may be worth noting that the message box which is displayed always shows the message The document does not contain any accessibility issues, even when issues exist.
The code is running on Windows Server 2012 R2. The JQuery version being used is: v1.2.6.
This issue also occurs when using Internet Explorer.
Does anyone have any ideas on this one? I have also posted on GitHub.
[RESOLVED]
It transpired that a variable referenced in one of the many included JavaScript files, was undefined. This has apparently gone unnoticed for years. I only found it because I was updating JQuery using the jQuery Migrate plugin, and it wrote a message to the console telling me that a variable was undefined.
As soon as this was rectified, the Accessibility Checker sprang to life.
It certainly shows that j.swiderski was on the right track. Thanks for that.
Possible to set a breakpoint for the code block of javascript like the screenshot below.
How can we use them? VS always ignores.
If Internet Explorer is set as the browser when debugging, Visual Studio is, in theory, able to stop at breakpoints set at client side script. To use the feature, you will need to make sure that "Disable script debugging" is checked in your IE Internet Options, Advanced tab.
However, I have found VS script debugging to be a bit flaky; the breakpoint is not always hit, especially with VS2010 or earlier. My personal experience is that it works best in VS2012 or later.
That being said, if you're using VS as the client-side script debugger and you find that your client-side breakpoints are not getting hit, it is best to insert a "debugger;" line prior to the line you would like to break at to ensure that it is picked up by the VS script debugger.
pennstatephil posted a link above that indeed provides more information on the subject: http://msdn.microsoft.com/en-us/library/7seh8d72.aspx
Edit: I'm not able to add comments, but in response to sb9's comment about why one would use IE, I find debugging in Visual Studio a lot more convenient when investigating script behavior before postbacks occur and server-side behaviors occurring immediately after postbacks. Also, sometimes the VS/IE combination will catch errors that Chrome and Firefox/Firebug reports with a nonsensical error message.
In Visual Studio 2017 there is an option to enable/disable script debugging
Just enable it and you should be good to go.
There are seemingly infinite possibilities to why this happens. I just solved this problem after hours of searching.
My particular issue is that my breakpoints were disabled immediately after my coworker enabled bundling (see description here). I had to go into our BundleConfig.cs file and comment out the line that said:
BundleTable.EnableOptimizations = true;
After I did that, they were hit. You'd want to add that line back in for deployments.
Another scenario for the inability of the debugger to stop at the break point is if one uses bundling.
To debug JavaScript files, we need to remove bundling.
I hope this will help someone.
Yes you can put the break-point on client side page in Visual studio
First Put the debugger in java-script code and run the page in browser
debugger
After that open your page in browser and view the inspect element you see the following view
I'm developing in Javascript for quite a long time now. Usually when I hit an error in IE I know roughly where it originated even if the message received from IE is useless bunch of text. When I don't know where the error originated, I usually try to "delete" parts of my code, until the error doesn't repeat itself, and that start manually checking line by line until I find the error.
I'm sure that it's far from the best approach, so I'd like to ask you how you debug error like these:
If you are using IE8+, you can press F12 on a page to open the Developers Tools.
This contains a JavaScript debugger, much like Firebug & Chrome Dev Tools
EDIT:
In response to the comment under the question, if IE is throwing a cryptic error that you are unsure of, there is a couple of steps I would do.
Is it an IE only error? Does the same error occur in Firefox? Chrome?
Is the error occurring in a 3rd party library. If you believe it is, use an un-minified version of the library.
Can you replicate the error outside of your website? Can you make the error occur in a http://jsfiddle.net/ for instance?
If you still can't narrow down the issue, post a question on SO with your code, any error messages, and expectations of the result.
HTH
Try using non-minified version of jQuery - it will give you a better idea where exactly the error is. Also, if you use VS 2010 to debug your js code in IE, it will break at the error line. This always works fine for me.
IE is the only browser that I've managed to successfully use the fantastic Visual Studio script debugger with - in my experience Visual Studio is hands down the best script debugger out there, so quite often I find myself in the reverse situation to you (running broken scripts in IE just so I can use the script debugger)
See How to debug JavaScript in Internet Explorer for instructions on how to use Visual Studio Express to debug scripts in IE - if you own a full edition of Visual Studio then its much simpler (just attach to IE as normal).
Something broke and I get "Object Expected" error on my live site, but I can't figure out where. If I run visual studio at the same time, it breakpoints it and shows the error as being half way along the viewstate, highlighted yellow... which is useless as its just gobbledegook.
How can I debug this? I want to know what javascript its trying to run that is breaking it.
Firefox and Firebug.
http://getfirebug.com/
Never debug Javascript without it.
Check out ScriptCanary.com so you can get all the details from live site errors and vastly improve your chances of quickly fixing them.
I have a few scripts on a site I recently started maintaining. I get those Object Not Found errors in IE6 (which Firefox fails to report in its Error Console?). What's the best way to debug these- any good cross-browser-compatible IDEs, or javascript debugging libraries of some sort?
There's no cross-browser JS debugger that I know of (because most browsers use different JS engines).
For firefox, I'd definitely recommend firebug (http://www.getfirebug.com)
For IE, the best I've found is Microsoft Script Debugger (http://www.microsoft.com/downloads/details.aspx?familyid=2f465be0-94fd-4569-b3c4-dffdf19ccd99&displaylang=en). If you have Office installed, you may also have Microsoft Script Editor installed. To use either of these, you need to turn on script debugging in IE. (uncheck Tools -> Internet Options -> Advanced -> Disable Script debugging).
You could also use Firebug Lite - which will work in IE & Opera. It's an external lib that will help you track down problems. It's sometimes more convenient than dealing with the MS Script Debugger.
Firebug
It's only for firefox but it should let you figure out what's happening on IE especially once you have the script line numbers.
You can use Visual Studio and enable debugging in browser
You can install FireBug plugin for Firefox, it's really good!
You can try to install IE8 beta 2 and use it in compatibility mode with built-in debugger.
Also in any line of your JS code you can write
debugger;
and this will be threated as breakpoint for any of the debug tools you use.
Cheers!
Aptana Studio provides JavaScript debugging for Firefox and IE
Firebug is the best all around client-side debugger. I frequently use it to debug CSS code as well as javascript. It allows you to easily find offending areas of code. I especially like the ability to modify tag attributes in the firebug pane and see the effects immediately before committing. Very useful for anyone designing websites.
You could use this tool apparently - Microsoft Script Debugger
Personally I try to go through the code and figure out what's going on - it gives you the line number where it goes wrong right?
To make the Microsoft Script Debugger more user friendly (and to add javascript error messages that actually are helpful to IE), I highly recommend Companion.JS.
Firebug seems to be the most useful so far. When a page is running on firebug, it can be very handy to log messages into firebug via javascript calls to console.log('your log message'); but don't execute that code in IE since the console object is only in scope when firebug is running.
For IE, other folks have mentioned the Script Debugger. Although it is not primarily for javascript debugging, it can be useful to also add the IE developer toolbar, which allows you to easily and dynamically inspect the style and other properties of your page's DOM.
In response to mopoke, for IE6 you definitely want to use Visual Studio for debugging if you can get it. For all intents and purposes, the MS script debugger is useless. You're better off using some form of tracing (not alerts) than using the MS script debugger. Dojo Toolkit, for instance, provides a debug console for tracing, but you can write your own by dumping messages to a secondary window or div.
The script debugger needlessly prompts you on each error in IE6 and even then doesn't give you enough state context to make it useful in a sufficiently complex JS app. Visual Studio is more tightly integrated and much friendlier. Just my experience.