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.
Related
I am building a web based JS REPL (similar to http://jsfiddle.net/), but I find it really annoying to have to switch between the Chrome Developer Console and my own code to debug. I have a text area on the left (using the wonderful Ace Editor) and clicking a preview button loads another window into an iframe on the right with the code I was editing. It made me wonder, what if I was able to add breakpoints to my code editor in the browser window and when it hits the breakpoint I could see the state of variables, step through the code, and remove breakpoints all while still editing the code in the editor. Very similar to real debugging, but in the browser instead of an editor like Eclipse.
I think a Chrome Extension is the right way to go. I can make calls to the debugger using the debugger API, then add breakpoints, step over, step out, etc. using this protocol. This works great and I can even get the current state of variables when the breakpoint is hit using Runtime.getProperties.
The problem is... that once I pause the code to debug, everything on the entire page freezes (of course, because I'm debugging). Can anyone think of a way to get around this? The ideal solution would allow me to freeze and debug the result on the right in the iframe and still manipulate the code on the left.
Is there a way I can set up javascripting in Chrome's console so that it does not process my statement as soon as I hit return. If I'm trying to test something out by just writing some javascript there, it processes before I'm done writing.
//here I am writing in the console
if ($(el).size() === 0){
//now I hit return because I want to type some stuff if this evaluates to true
//but return submits it as a finished piece of javascript and of course
//I get SyntaxError: Unexpected end of input before I can have a chance
//to finish the logic
I know I can hit shift+return and get a line break, and though that's a small inconvenience, it's still a bit of an inconvenience. Is there anyway I can tell it to hold off processing until I hit a macro like shift+return?
It's the same way in Firebug. Maybe there's an option there. Or maybe someone knows of a good third party add-on. Thanks.
In the comments I posted the ticket for the request for support, but it has been there for awhile. Chrome does have snipplets, but you have to enable them.
In the address bar type about:flags
Enable Developer Tools experiments
Restart the browser
Open the Developer Tools open the settings menu [gear on bottom right corner]
Click the Experiments tab [on left], check Snippets support
Restart the browser
In the Scripts panel, there will be a Snippets tab, click on it.
Right click on the area below and from context menu select New
You can than Edit and Run the code like a file. Run it with the context menu or play button.
A multi-line console effectively lets you do what you want. Chrome has a request for this but is otherwise not really available.
Firebug Lite for Chrome does allow it. Just click the little red button at the bottom-right of the Javascript console.
Since I installed Visual Studio 2010 from scratch about 2 months ago, it behaves slightly different when debugging JavaScript code being run in IE.
When I set a breakpoint, it opens a duplicate of the view with the term "[dynamic]" in the header and marks the breakpoint in there.
When a JavaScript error happens during execution, it does the same before it marks the line of code that threw the error.
This "dynamic" view is editable but edits have no effect - they are not saved to the file.
I find this behavior pretty uncomfortable. Everytime I notice an error in the code during debugging, I happen to fix it in the dynamic view. I hit save. VS does not complain. Next I refresh the page in IE, and - bang - the changes are lost, it loads the untouched old version again.
I haven't been able to find out how I can turn these views off. Before I re-installed Visual Studio it did not do that. It would only create "dynamic" views for script found in inline script tags in HTML files.
Try this
IE > Internet Options > Settings (under browsing history) > Check for new version of stored pages : Every time I visit the webpage.
This works for me in IE10.
Other option is to open Developer tools and select cache option Always Refresh from Server as show in the image below
Try hitting CTRL+F5 on the web page. That did the trick for me.
The problem was that I had opened other IE windows from a previous debugging session, so the dynamic javascript files were still cached.
Having developer tools open - F12 - should also cause the cache files for the page to be cleared on each refresh.
Changing the encoding of the JS file in question, from a Windows codepage to UTF-8, fixes this for me.
Narrowing it down, it appears that OEM Extended ASCII characters in the file (e.g. ALT-254 which I use for a bullet) trigger the problem with the Windows codepage files.
(Visual Studio 2013 Update 5, IE11)
For Google Chrome:
Open developer tools(F12)
Open Network Conditions Tool
Select Disable Cache
I had the same problem of not being able to hit a break point in new code. And breakpoints on old code in the same page will bring up the [dynamic] version. The edited page is not reloaded. This just started for me a week ago in both VS2012 and VS2013. Using refresh page and/or Ctl-F5 did not work for me. BUT, reading this thread pointed me to using F12 to open Developer tools. Leaving that window open, while hitting refresh does the trick. Thanks guys.
1) Run the page Without Debugging (Debug-->Start Without Debugging)
2) While the web page is open in Internet Explorer, press Ctrl-F5 so
that the IE cache is cleared. Ensure IE has the focus.
3) Close IE and re-run the page with Debugging (Debug-->Start
Debugging).
This fixed the issue for me.
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.
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).