When I put a debugger statement inside some code that is called onScroll, the Chrome development tools do something strange that I haven't seen before: instead of pausing the browser with a gray overlay AND pausing the dev tools debugger on the appropriate line, Chrome only does the latter. In other words, it pauses in the debugging pane, but the browser remains active, allowing me to continue scroll (or do anything else) in the browser.
Is there anything I can do to make the browser truly halt both the debugger AND the browser pane?
Related
Steps:
Put debugger in code
Run Code
Chrome stops at debugger
Note: I believe sometimes you have to refresh the screen or have multiple debuggers to see.
See Image
'never pause here' can not work
after I continue：
still paused
To totally ignore all breakpoints in Chrome, you must do as follows:
Open your page in the Chrome browser.
Press F12 or right-click on the page and select Inspect.
In the Source panel, press Ctrl+F8 to deactivate all breakpoints. (or: At the top-right corner, select deactivate breakpoints.)
All breakpoints and debugger statements will be deactivated.
I tested it in Chrome 79.0.3945.88 (64-bit) and I found that the debugger statement is ignored.
To stop hitting debugger statements, you must either set a "never pause here" breakpoint, OR you must pause stopping on exceptions.
This works because debugger breakpoints are considered exceptions by the browser.
If I put the debugger statement in my JavaScript source with the Chrome devtools open, it'll stop execution so I can interactively explore the current context from the console. It's really awesome.
But unfortunately it will also switch to the Sources tab and display the line where the debugger statement happened. Most of the time, I want to type JavaScript commands, so I have to manually switch back to the Console tab.
Can I avoid the tab-switching and stay in the Console tab?
Or am I using it wrong?
Right-click on the source-tab and select 'move to bottom'.
Looks like Chrome added a preference for this in the intervening 9 years: https://stackoverflow.com/a/69216922/66673
Quoting that answer:
I had the same issue and it was driving me nuts! The way I managed it to stop switching was to go to into the DevTools settings -> Preferences.
Under Sources options, uncheck Focus Sources panel when triggering a breakpoint.
There's a reason for that - and is that whenever the code has stopped, because of a breakpoint or a debugger statement, you'd usually want to actually see where the execution has stopped. So, the developer tools switches to the Scripts/Sources tab, and this is a common behaviour among the major browsers, that may also show the local variables, the call stack and so on.
The best thing you can do is to keep the console frame always open, so you're ready to work. Just press Esc or click on the second icon on the lower left corner. That's what I usually do.
Switch to the Console tab when you expect to get a large response from the command you type.
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 am on Windows 7, using IE8 and Visual Studio 2005. I have been enjoying the built in javascript debugger in IE8 for several months. About 2 weeks ago, I installed some security update for IE 8 (possibly KB978207) and all of a sudden the javascript debugger is now broken.
If I get a warning from IE 8 that an error occurred and asking if I want to debug using the built in debugger, if I hit yes, I get a grey popup in the top left corner (which I've never seen before) saying "JScript Debugger. Breaking on JScript runtime error - Object doesn't support this property or method". Then nothing happens. IE freezes up and then I get a Windows popup saying that IE 8 is no longer responding and asking if I want to end this process. If I try to end the process, nothing happens and I continue to get the grey popup. I usually have to kill debugging process from VS 2005, but the frozen IE8 still is present. It's not until later when the OS, finally cleans up the process that it will go away...
Edit (new info):
I tried removing the lastest security update and a silverlight update that came around the same time, but Windows automatically reinstalled them....
I then tried removing IE 8, and then adding it back to my system to reset anything related to IE8. This did not have any effect.
After reinstalling IE8, I did notice that, when I first tried to open the developer tools window by hitting F12 from a regular IE 8 window, I never saw anything, but I could see the developer tools title in the task manager list. I had to right click on the task and maximize the window, so I could actually see the developer tools window. Apparently this is a bug mentioned here: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/79b8ee54-c5f6-4467-ba6d-27491c95cd13
I've realized that the window will maximize if the iexplorer.exe process is not the debugged process launched from VS2005.
The grey popup I mentioned in my original post is from the developer tools window iexplorer.exe process.
If I launch my app from VS2005 and then hit F12, I see that the developer tools window is opened (I can see that window is opened under the IE icon in my taskbar), but it is not shown. If I try to maximize it from the task manager, this has no effect.
So basically, the developer tools window is freezing up when it tries to open under my debugged iexplorer.exe process launched from VS2005. The OS then asks if I want to kill the process since it's not responding, but it is unable to kill it. At some later point, the zombie iexplorer.exe process is killed succesfully (by the OS I presume).
Had the same thing happening. You clued me in on the solution by pointing out F12 starts Developer Tools in the taskbar but doesn't show up on the screen. Apparently the window is off screen in nowhere land and causes major screwups if you attempt to debug in this state. So my solution was to:
Close all IE instances
Start up IE
Start up Developer Tools (F12)
Hover cursor over the the IE button on the taskbar until context menu shows
Right-click the Developer Tools item in the context menu (not the taskbar button)
Click "Move"
Start tapping arrows until you see the window come back in view. Mine was off stage left so I had to hold down the right arrow.
The window will have been sized down to just a window title bar, so resize by dragging the right corner down and out.
Once the window is moved back and resized, close it to "set" the position. You should be good to go now.
May be the security patch has disabled script debugging in IE. It was a common problem when using the debugger of VS 200X
Now on try to enjoy FireFox with the FireBug Addon. It's really great to debug Javascript. :)