I am trying to debug a MVC app that uses JQuery.
Firstly I have version 1.3.3 of Firebug and I have set
the Break on All Errors option and have added a deliberate
error but it is not breaking on the error.
Secondly after I have activated something that has a javascript
function and put breakpoint in and then let it continue, it then
no longer hit s that breakpoint if I reactivate the function.
Thirdly can you put watch expressions in for JQuery statments
because I have, and it says undefined in watch list window.
Malcolm
From what I remember, one of the newer patches of Firefox broke Firebug's javascript debugging. You can try upgrading to the 1.4 alpha (http://getfirebug.com/) but that causes other issues.
Another thing to note, is that sometimes it lets you put a breakpoint on any given line, but from my experience its really only when the line number turns green that you can rely on that breakpoint working.
I was disabling and re-enabling firebug back and forth when to fix it at one point, but I often had to kill the firefox.exe process. Anyway, when the line numbers are green you're good to debug once before having to disable and re-enable again (at least that was my browser's behavior).
Related
Until two weeks ago I was able to set a breakpoint in JavaScript code by adding a debugger; statement. For Internet Explorer, when this statement was hit, this would cause me to automatically go back to the Visual Studio debugger.
I could optionally toggle a breakpoint for the line in Visual Studio, but this wasn't necessary, and it wouldn't set a breakpoint on its own without the debugger; statement. When a breakpoint was set in this way, it would show a red filled in circle on the line of JavaScript code.
On April 4th this stopped working.
Now if I add a debugger; statement nothing happens. If I try to toggle a breakpoint in Visual Studio, I get a red open circle. Hovering over the circle gives me the error that "The breakpoint will not currently be hit. No symbols have been loaded for this document."
I've searched for that error message, but what I have found has been about C#, not JavaScript.
I thought the problem might be something we did to our source code, so I checked out a much older version, but I still had the same problem. Our other developer started having the same problem on his main machine at the same time I did. But he has a laptop he uses less often that didn't see the problem. It was a bit behind our source control and he ran it forward one commit at a time until the present version and never saw the problem.
How do we get our breakpoints to work again? How do we get Visual Studio to load the JavaScript symbols? (or is that even really the problem?)
I've been relying on Firebug for two weeks, but I need to go back to IE because of the VS integration.
Stuff I've already looked at:
In Visual Studio, Tools -> Options -> Debugging -> Just-In-Time, Script is already checked.
In IE Tools -> Internet Options, Advanced tab, Browsing section, Disable script debugging is not checked, either for Internet Explorer or for Other.
In VS, Properties menu after right-clicking on the solution, Common Properties -> Startup project, selected Multiple startup projects, set start action on the project with our JS code. The result of this was my "Internet Explorer" button turned into a Start button that couldn't run the project - it just gave the error message "The debugger cannot continue running the process. Unable to start debugging."
Right click on the project, select Properties, go to Web -> Debuggers. The options I get are ASP.NET, Native Code, SQL Server, and Silverlight. Only ASP.NET is checked. Enabled all of the others, but nothing changed.
Cleaned and rebuilt the whole solution.
Project properties -> Build: Define DEBUG constant and Define TRACE constant are checked. On the Advanced dialog, Debug info is set to full. Not sure if that even has anything to do with JavaScript.
Debug -> Options and Settings -> Debugging -> General: uncheck Enable Just My Code
In the end after a lot of changes, I saw this error message "Ignored debugger statement in eval code at line 2600. To stop at this statement, disable Just My Code."
I had already tried the Just My Code fix, but I tried it again, and my breakpoints came back:
Debug -> Options and Settings -> Debugging -> General: uncheck Enable Just My Code
When breakpoints are triggered they show up in a special eval'ed code window that includes a copy of the code where I put the debugger statement. I think that's how it was working before. Apparently there are a few places in our code where breakpoints work no matter what - those didn't need this fix, and they don't show up in the special eval window.
I rolled back all the other changes I had made today one by one, and in the end it looks like disabling Just My Code fixes it. I had even messed with creating a _references.js because I was seeing an error from JavaScript Language Service about it, but that doesn't seem to be necessary.
Thank you to those who pitched in with suggestions, including those who posted answers and deleted them because you realized I'd already tried it. Obviously trying things more than once can sometimes be a good idea.
I'm seeing an odd bug in IE that I'm not seeing in Chrome. Specifically, this involves some JS code not firing when a (Telerik) wizard is navigated back to it's first step.
When the user clicks their "Previous" button, some data isn't being properly loaded. Hitting F12 and bringing up the developer console has shown me the following Warning:
DOM7011: The code on this page disabled back and forward caching. For more information, see: http://go.microsoft.com/fwlink/?LinkID=291337
Ok, so I go to the link provided and I noticed the documentation states:
In order to be cached, webpages must meet these conditions:
...
- The F12 Developer tools window isn't open
This is a problem, because when I use the navigation buttons within my wizard WHILE the dev window is open, it behaves properly, just as it does in Chrome.
How can I debug my related Javascript so I can figure out what's going on? Also, I understand what caching is but I'm not exactly sure what this is about and I have no idea why Chrome behaves differently. Is there a way that I can force IE to behave like chrome and cut on (or off) whatever features that are causing this issue?
Yuck. Back to old school debugging for you.
Short of putting the whole browser into a Windows debugger, you can pretty much forget about setting breakpoints. All you can do is log.
If you are lucky and your problem isn't too deep, you can use a sprinkling of simple alert() statements to let you know the state of things at various stages in your code. One nice thing is that you can serialize objects now pretty nicely; for example, you can do JSON.stringify(this), which will probably give you a giant output, which you can copy and paste into your IDE and unpack. A major upside to doing this is that the alert will block, so you can take your time studying the output. A major downside to this is that race conditions are now much more likely.
Alternatively, you can add a <textarea> to the page and throw your JSON.stringify(this) results into that. Because this means extra DOM mutations, it also increases the odds of race conditions, but not by much. (If race conditions are a possibility, you can do this:
(function () {
var currentState = JSON.stringify(this);
setTimeout(function () {
document.querySelector('textarea').value = currentState;
}, 1000);
})()
Even though these are now asynchronous, if you use this multiple times in sequence, these will execute in that same sequence (unless you change the timeout period).
If you are doing actual page navigations (and not just changing the URL with pushState()), then actually reading those logs is going to be a problem. The solution is to put the page in a frame and write the content out to a sibling frame. As long as both frames are running on the same domain, you will have no problem pushing the data into the sibling frame. If you can't put them on the same domain, you are kind of screwed.
What is changed, from the point of view of running AJAX application, when the IE Developers Tools are opened?
I'm tracing now some Schrödinger bug. It's about dropdown lists from PrimeFaces in IE. They are sometimes not opening after click, and they got 'unblocked' after one maximizes browser or unzooms the content. Because those dropdowns are realized on the basic of normal input, with attached div, I supposed it's something with wrongly calculating the place to show that dropdown popup. I've also supposed AJAX errors.
But after opening IE Developers Tools it's hardly possible to reproduce the error. No error is showed in console, no AJAX request hangs, and, what's more, everything seems to function more.
The error is only for IE, so the developers tools are the only way to debug it. However, when they are opened, it seems that the observation changes the state somehow, like in quantum mechanics...
So, I need to know, what could be changed by opening those developers tools, that prevents the bug from showing up?
--edit--
It has nothing to do with console.log. It is the problem with calculating the size of invisible elements. The problem was solved by adding scroll to the body. However, the question is open, how the IE Developers Tools were influencing those calculations.
If you really want to always include using console, I suggest using a polyfill for it:
(function(b){
var a=0;
var c=function(){};
var d=["log","assert","clear","count","debug","dir","dirxml","error","exception","group","groupCollapsed","groupEnd","info","profile","profileEnd","table","time","timeEnd","timeStamp","trace","warn"];
b.console=b.console||{};
for(;a<d.length;a++){
b.console[d[a]]=b.console[d[a]]||b.console["log"]||c;
}
})(window);
This a minified example that I tried to make readable. It's something I found awhile ago and modified some. I think the main thing I modified is that if you call a method that wasn't originally implemented by the browser's native console, it will call console.log. If console.log wasn't natively implemented, it just calls an empty function. The original version of this code didn't include this fallback to console.log.
This will "guarantee" that console calls will not fail. You can change the d variable to only include calls you are sure you will use, otherwise there's some extra unnecessary processing.
When you are in the infinite loop or recursive calls, basically the browser stops responding to anything (either on Chrome or FF). You cannot see logs, cannot get into debugger, even you cannot open the console itself. The browser just simply freezes. This is so annoying. It seems I can do nothing but sitting here scratching my head... Anyone can shed light on how to solve this?
Another trick you could try is to have the Web developer tools in Chrome open and try to hit Pause when the Browser apparently hangs. Then it should break at the line where it's currently executing. With some stepping out you should get to the bottom of this.
Assuming you know (or suspect) the function where the infite loop happens you could add code like this:
var calls = 0;
function iSuspectToBeLoopingInfititely() {
calls += 1;
if (calls > 100) { debugger; }
}
This will stop the JavaScript debugger in Chrome once the method has been called 100 times.
Note: Chrome will only break for debugger; calls if you actually have the Developer Tools window open.
Found another way of debugging. In my case the error was caught and so no errors where logged to the console. Found the bug with the checkbox Pause on caught exceptions. You find the option in den dev tools unter the Sources tab. To show and enable the checkbox click on the last icon:
After enabling this, the debugger pauses on every caught exception.
I had issues in Chrome, I would see in the browser window 'Paused in debugger' but couldn't see where as maybe Chrome was confused since it was in a loop ... In Firefox, it recognized its taking too long and then a popup comes up after 30seconds to 1minute saying the file and general line # its frozen on which helps out to debug further and set Breakpoints around that area.
I solved this by placing Chrome breakpoints along all functions in the function file that I knew was causing the issue. I started with one debugger in the file so the execution would stop, which made it easier to add the chrome breakpoints.
Click the code numbers on the left side of the source file in Chrome Dev Tools "Sources" tab to add a blue debugger breakpoint. Place several of these and you can use the command buttons at the top right of the Sources tab dash to step through the functions. You can even add console.log items that will run on each time you step through.
Additionally, note that at any point in the paused execution, you can switch to the "Console" tab and type the name of any variable or function, and you'll get the current value of that variable or function.
I've been looking for a solution to use Javascript to open or activate Firebug.
You see by default, Firebug is deactivated/closed at the corner of the status bar.
You need to click the icon to activate Firebug (the icon becomes coloured).
Is there a way to activate Firebug via Javascript in the javascript code?
see following:
// check if firebug is installed and activated
if(window.console && window.console.firebug){
// do firebug debugging and so on
}else{
alert('Firebug is not installed or activated.');
}
If you are trying to troubleshoot your own code, you can use the javascript "debugger" command to cause firebug to break on a given line of code. You will have to enable firebug debugging first for that web page. Maybe that's more along the lines of what you were looking for?
I don't think you want to trigger Firebug to open on an end user's browser; this would, at best, cause confusion for the average user.
Well, if Firebug is deactivated then its not active and cannot respond to anything. You have to actually turn it on before it can accept calls from a web page.
If there is, that option could possibly be a security hazard. Basically, you're telling FF to start up the debugger. If you could tell this debugger to even do a few things more then it could be misused by hackers.