In e.g., Chrome Dev tools, it is easy to set a breakpoint in the Javascript for a website. When you are stopped at a breakpoint, it is easy to log out the value of any variable in the scope of the breakpoint, and you can even use watch expressions to have this done automatically.
However, what I would like to do is add console logging to a script from within the browser, so that I can see values without stopping execution of the script in a breakpoint.
My use case is that when developing, I will often use console logs for debugging. I may add a console log, compile, start my dev server, navigate to the place in the app where the code is executed, and observe the log. However, for my team's workflow, it would be useful to be able to add additional logs without having to recompile etc. Is there a way to do this in Chrome?
Starting at Chrome 73, you can use Logpoints, which are basically non-breaking breakpoints which only do logging for you.
Before Logpoints was a thing - you could set a conditional breakpoint in devtools and just write console.log(someVar) inside the conditional statement, and it would work since console.log doesn't return anything, and hence not stopping at the desired breakpoint.
Adding a console log is something Google recently add.
In the selected row instead of left click,click right click and select 'add logpoint', a small text box will pop up, enter the variable you want you console log.
If you do not see this feature update your browser.
Related
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.
I have really complex page with a lot of javascript to fix. It involves a lot of functions and I need to find out one specific function, which triggers on dragging Raphael JS object. I can't figure out which one that is.
Is there some possibility to log whatever runs "right now" to console?
I know, that the output would be messy, but I would get a chance to see, what happens, whan I grab the object with my mouse.
If JavaScript is executing at that precise moment, pressing the Pause icon in the Sources tab of the Developer Tools will stop the script and show you the call stack.
If you want to debug what happens when particular event listeners happen (for instance on a drag-and-drop script), you may be able to do this by right clicking the page element, selecting Inspect Element, then in the right column of the Elements tab, scroll to the bottom and view the Event Listeners attached to that element. Clicking on a particular listener will show you the script source of that listener, and you may be able to add a breakpoint at that point. (Beware that compiled scripts can make this difficult to comprehend)
When investigating problems with a page, either my own or a third party page, one trick is to sprinkle breakpoints liberally on scripts I suspect that fire on button press etc. Then I manipulate the page with the Developer Tools open so that the breakpoints will cause debugging to halt when a breakpoint is hit.
Other tricks if it's your own code is to use console.log statements logging activity to the console, or debugger (which are like software breakpoints). And of course the old-school alert dialog box generating statements can still be useful too.
I might be wrong but you should manually use console.log() to write to browser console.
Have you tried :
console.log(yourObject)
Where yourObject is the draggable element ?
In the new chrome console, there is in depth object browsing, maybe you can find what you want in your object prototyppe.
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'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.