With Chrome DevTools open I can place a breakpoint in a Javascript file and step through the code displayed in the "Sources" tab as it executes. The problem is that every time I hover over a variable I get an unwanted tooltip that pops up with the value of that variable.
For example if a section of code is let a = 1; then any time my cursor happens to pass over a I get a popup displaying 1. Some variables such as DOM elements can be quite large and frequently get in the way as I am trying to look at the code. I find this annoying and would like to disable this feature. Is there a way to NEVER see these tooltips?
Related
I'm following this tutorial on how to use DevTools to insert breakpoints. I've opened the example page and have added a breakpoint on the click event, as in part 2 of the tutorial.
However, when I click the button, DevTools does not highlight function onClick() { in the get-started.js file, as the tutorial says it will. Instead, it highlights a minified function in a minified file (end.min.js):
Why is this happening? And how can I fix it? I would like to follow the tutorial, but it's pretty difficult with the breakpoint being added to the minified file.
I am not sure where end.min.js is even coming from: the Network tab doesn't show it being loaded. I'm not sure if it's related, but when I try to view the source of the page, Chrome shows the "loading" icon forever.
Is Chrome doing something clever with
It seems like an extension (I'd say a password manager) is adding event listeners too, and your breakpoint first catches this listener.
You can either test with the extension disabled (you may need to refresh the page), or just press "Resume" to go to the next listener.
Are you sure you're following the tutorial? I have followed this:
DevTools lets you pause your code in the middle of its execution, and
examine the values of all variables at that moment in time. The tool
for pausing your code is called a breakpoint. Try it now:
Go back to the demo and open DevTools by pressing Command+Option+I (Mac) or Control+Shift+I (Windows, Linux).
Click the Sources tab.
Click Event Listener Breakpoints to expand the section. DevTools
reveals a list of expandable event categories, such as Animation and
Clipboard.
Next to the Mouse event category, click Expand
Check the
click checkbox.
And the expected error shows:
Also you have to activate pause on caught exceptions, and seeing the image that you have provided it seems like you don't have that activated.
But I see if you open DevTools when you reload the page, another error pops up, maybe if you close DevTools, reload the page and try again?
I want to see what code is modifying a DOM element on a webpage, so I set a breakpoint in Chrome by right-clicking on the element in the Elements tab of the DevTools inspector and choosing "Break on..." -> "Subtree Modifications". The script modifies the element when the page is loaded (and not after), so I want to preserve the DOM breakpoint and refresh the page.
The process for saving breakpoints in javascript code doesn't seem to apply to DOM breakpoints.
For now I added a debugger; line before any other code runs, added a DOM breakpoint, and continued.
In Chrome, DOM breakpoints are not preserved upon refresh, they are thrown away, and then restored after the onload event. See bug report 571519, and this comment from that report:
We are preserving DOM breakpoints upon reload, but the breakpoints are only restored upon onload event. So if you expect breakpoint to trigger before that or it is set on a node that is added lazily, breakpoint is not restored. We should fix that though.
This is the workaround:
pause the Javascript, either with a normal breakpoint or with debugger; line of Javascript
remove all DOM breakpoints and add the DOM breakpoints that are needed
resume.
I believe this didn't have a proper explanation for the answer because I face the issue as well. the steps goes as follows.
open developer tools by pressing console f12,
you need to try to slow down your webpage rendering so you can be able to quickly pause javascript execution, the trick I use is to go to the network tab and set the online drop-down field to slow 3G so the pages become slower to render.
select the sources tab then on the left sidebar check breakpoints and make sure all break points are removed, if there are still some breakpoints set then remove them
click on the pause execution button on your
go back to your webpage and reload it, with the network set as slow 3g, your page becomes slower to render then you can quickly go back to sources and pause the execution the moment you can see your HTML dom is loaded. in this way your webpage is in a paused state
go to your element tab, find the element you want to set breakpoint on and set it. then go back to sources tab and click continue execution this will make the execution stop at your element's break point
Is there any tool to record the change of DOM by Javascript and then re-run it slowly to debug ? Basically I want to log the html source code every second and then go through them one by one to see how the javascript is changing the page.
There is huge javascript which is difficult for me to understand. It is minified. I am only interested in watching how that script changes the state of a particular node in DOM. The changes are very fast and I want to observe it slowly.
Update:
I can add break point to pause execution of javascript whenever a dom element changes. But as I have said the element is changed too frequently. It there is something like "pause execution of JS when the number changes % 100 == 0" it would serve the requirement well
You can set breakpoints in the Chrome dev tools, which will pause all script execution on that page and give you time to examine everything.
To open the dev tools, press F12 or CtrlShiftI on Windows, or CmdOptI on Mac.
Go to the "Elements" tab, right-click on the element you want to observe, select "Break on...", and choose the events on which you want to pause.
Then let the script run, and a dark overlay should appear, saying "Paused in debugger".
If not selected automatically already, go to the "Sources" tab in the dev tools.
From there you can see the entire call stack, and see and modify all global and local variables and closures.
With F8 you can resume script execution (until the next breakpoint), and with F11 you can step forward into the next function.
Of course you can still use the console and the "Elements" tab while the page is paused.
If you need finer breakpoints, you can set a breakpoint in the source code, or replace a function in some object reference.
To set a breakpoint in the source, find your script in the "Sources" tab, prettify it via the {} button at the bottom left, and click a line number in the script. The line number should get a blue arrow after that.
To set a breakpoint by replacing a function, you'll need some object reference to work with.
Let's say we're working with jQuery, so we have a $ variable, which has a .ajax() method. We can inject a breakpoint there by doing the following:
var oldAjax = $.ajax;
$.ajax = function()
{
debugger;
return oldAjax.apply($, arguments);
};
If there is no object like $, to which you have access from the console, you can still use it, if you can set a breakpoint so that such an object will show up somewhere in the variable scope of one of the invoked functions.
From there you can right-click the value of the variable, select "Store as Global Variable" and then proceed with the method above, just using temp1 instead of $.
I'm trying to inspect CSS properties from an input into a table cell. The input appears on click and disappears on lost focus, as when I try to inspect it.
How can I do it to don't lost focus while I move to another window (the inspector)?
In Chrome browser, open Developer Tools and select Elements tab, then
open the contextual menu of the parent node of the element you want to inspect, in the contextual menu click on Break on > Subtree modifications.
Afterwards you just need to click on the page and you'll get on the inspector without losing focus or losing the element you want to inspect.
In chrome devtools settings, there is an option named Emulate a focused page which is disabled by default. After enabling this option, if you click anywhere on the devtool window, it wouldn't cause loss of focus on any element in the DOM.
For Chrome version >= 86:
Open devtools and then press Command+Shift+P (Mac) or Control+Shift+P (Windows, Linux) to open the Command Menu. Start typing Rendering in the Command Menu and select Show Rendering. There you can enable Emulate a focused page.
After that, just click on any element to focus, and then click anywhere on the devtool window. You would see that element doesn't lose the focus. So now you can easily inspect or debug.
For Chrome version < 86
Go to devtool settings -> preferences and under Global option, enable Emulate a focused page.
You can capture the disappearing element if you pause JavaScript execution without moving the mouse. You can do so with a keyboard shortcut or by triggering a debugger statement. This works for elements whose appearance is controlled by JavaScript, rather than CSS :hover (if CSS, see Dumba F.'s answer).
Keyboard shortcut
This approach works for pages which don't use JS to trigger special behavior on keypresses. These instructions are for Google Chrome, but can be adapted to other modern browsers:
Open up Developer Tools and go to Sources.
Note the shortcut to pause script execution—F8 (there may also be another shortcut depending on your OS).
Interact with the UI to get the element to appear.
Hit F8.
Now you can move your mouse around, inspect the DOM, whatever. The element will stay there.
debugger statement
To trigger a debugger statement which executes while the hovered element is visible, use setTimeout:
Open the JS console, and enter:
// Pause script execution in 5 seconds
setTimeout(() => { debugger; }, 5000)
Cause the hover to open and wait for the script execution to be paused.
(Same as Nick Farina's answer)
If all else fails, type this in the Console:
setTimeout(() => { debugger; }, 5000)
Then you've got 5 seconds (or change the value to anything else) to make whatever you want to debug appear.
None of the other answers worked for me - the DOM tree kept getting modified (i.e. stuff I care about disappeared) right before the script paused.
Not sure if this works in your situation but normally (and in every case worth to mention in this regard as it is a great tool) in Chrome Developer Tools you can simulate element states and one is also :focus.
To do so go to the Elements tab in the Developer Tools and make sure you are in the Styles section on the right (this should be the default location when you start the Developer Tools). Now just beneth the Styles in the top right corner you have an icon Toggle Element State. When you click it you can simulate :active, :hover, :focus and :visited for the element you selected on the left in your code view.
In Chrome on the developer tools page for the page under test... click the options menu and open settings for preferences... under DevTools enable 'Emulate a focused page'
Then in the test page cause the elements to appear. This worked to keep my popup search results is focused to stay on the screen so I could work with it.
Not a real solution, but it usually works (:
Focus the element
Right click for context menu
Move down to developer tools
I had a very difficult situation and no answer was working from here (I didn't verify the answers changing the container, which is the body for me, or the original event, because I don't know that). I finally found a workaround by breaking via the Control Event Listener Breakpoints in Chrome Inspector. Maybe that is also a cross browser way of breaking for complicated situations where even F8 or right clicking mouse hide the popup again:
Click right of element in chrome devtools ;-)
Paste the following Javascript in the browser developer console:
// Delayed console log of parent element with disappearing child element(s)
// Once code is trigger, you have 3 seconds to trigger the hidden element before it snapshots.
// The hidden elements should appear in the console ready to inspect.
var timer = 3000; //time before snapshot
var parent_of_element_to_inspect = 'div.elementcontainer'; //container of element to snapshot
setTimeout(function(){
console.log(document.querySelector(parent_of_element_to_inspect).cloneNode(true));
},timer);
I have a quicker fix since I'm not very good with using tools, here's what i do.
event.originalEvent.preventDefault();
event.originalEvent.stopImmediatePropagation();
event.originalEvent.stopPropagation();
If you open Chrome DevTools and then trigger the element inspector using keyboard shortcuts, it should solve the problem.
Mac: Cmd+Opt+J and then Cmd+Opt+C
Windows: Ctrl+Shift+J and then Ctrl+Shift+C
[
I am trying to understand how to get from the chrome debugger the following info : there is an event on page triggered by a click on an input file type tag. But it is impossible for me to trace back the mecanism : which js file is called when the event is triggered. Is there a way do get this info from the debugger ?
Do you have a look at the Event Listeners entry in the right-hand window? If I right-click the 'Google-Chrome' tag at the bottom of your post, and select Inspect Element, I get the html tag highlighted. If I then look in the right-hand pane at the Event Listeners, I can see that this element has handlers for blur, click, keyup, keydown, mousedown, mouseout, mouseover. Yet just looking at the html I can't see that. If I expand the event handlers, I can see that they all point to "jquery.min.js : 3". This is because the file has been minimized and is only 4 lines - each of which is probably 20 or 25,000 chars long. Minimized scripts are difficult to analyse unfortunately.
Try it with a page that doesn't use minimizes scripts and you can click the link in the event handler window to be taken directly to the pertinant function - unfortunately, you are taken to the start of the line concerned, which makes jquery.min.js a waste of time to do this with. You can always use the non-minified version of a script for debugging purposes, switching over to the minified version for production.
With other's pages, you can sometimes get away with saving a local copy, before linking an unminified version of the script.