Ok, I'm having a weird problem:
I have a button that is inserting divs into the DOM. When the button is clicked, the first time, the div always appears immediately on the page. However, subsequent button clicks do not insert any more divs.
Now here's the strange thing, after I insert additional divs, and they don't show up, I select inspect element with the chrome developer tools, and the div instantly appears after invoking the developer tools. I can see the
$('#list').before('<div class="mybox">some text</div>');
It basically doesn't seem like chrome is refreshing, even though the new elements are being input into the DOM, the browser window doesn't reflect the changes until I go into the developer tools. But I can't figure out why?
You're right. It is a weird problem. And it happened to me too.
In my case, I was relying on an external library to create an element for me at startup. I'm still not sure what the root cause is, but I solved it by calling setTimeout(myFunctionThatSetsUpTheElement, 1).
Hope this helps.
Related
When I use Firefox developer tools to edit the body of a webpage, the page buttons either disappear or stop functioning like in the example below. This does not happen in Chrome and all the buttons work fine as they suppose to.
here are the steps that lead to the problem:
I go to the webpage that I need to work with, then I need to edit a few things in the page so I press Ctrl+Shift+C to open the dev tools, right click on <body> then Edit As HTML and change what I need to change and apply it and it works just fine with Chrome but in Firefox and other browsers the buttons stops working or disappear.
Here's the link to the example page. (This is only an example not the real page I'm working with, because the real one is in Arabic and requires more steps.)
This is because the Firefox DevTools obviously do the same as when you copy the outer HTML and then execute this
document.body.outerHTML = `*copied HTML*`;
inside the DevTools' console.
That's why all the event handlers as well as iframe contents are gone after you finish editing the HTML, e.g. in this case you can't edit the code at the left side and there is no output shown at the right anymore.
The Chrome DevTools seem to do something smarter here and recognize what has changed and only update those parts when you save the HTML. Therefore the output on the example page is still visible afterwards and the code can still be edited.
I've filed an enhancement request for that, so the behavior in this case can get improved.
On my website, I have a lot of code, many js vendors, etc.
On one specific page, I have king of a right sidebar that pops out for less than half a second, never enough for me to click on it and try to debug this weird thing (I'm thinking of putting a display none on its class).
I've tried to go through the dom and place dom breakpoints in my chrome browser but it's not doing nothing.
Does someone know how I could debug something like this ?
Thanks a lot !
Use "inspect element" to detect the sidebar and then navigate to the class or id which has the display:none; property. Then you can click it on or off in the developer toolbar...
As a freelance Wordpress developer I find myself thrown into projects where things are just 'broken' - with the problems regularly ending up being some kind of path issue/syntax error/etc in javascript.
I am in the situation right now where I am trying to get something that works in Site A to work on Site B. Basically the problem involves a mouse over event that causes a div with class name 'overlay-ico' to appear.
I'm sure there must be some kind of debug tool in Chrome, Firefox, etc that allows me to easily do this without reviewing all the source code?
Update:
I am familiar with being able to inspect the HTML (at least in a basic way), but I don't see how this shows me what would trigger an event to occur.
I am also know that there is a console, which as I understand it, only outputs errors, or something that has been explicitly directed to console output.
There must be somewhere in the code that is waiting for a mouse over event, that triggers 'overlay-ico' to appear. I'm sure I could do it if I did a search for 'overlay-ico' through all the source code - but I'm thinking there must be a faster way to find it.
In Windows, F12 opens the debug panel in most browsers.
In Chrome, you can inspect an element and then click into the Event Listeners tab in the right pane. That may show what you're after. It's hard to say without seeing it.
I'm currently toying around with some autocomplete form fields, and am finding it very hard to inspect the generated drop down items. As soon as I click on the "inspect element" button or try to right click on the dropdowns, the original autocomplete input runs an onclick event (or something that triggers on a focus change) and hides, deletes or otherwise modifies the element I was trying to inspect.
Is there a way to work with the debugger so that the mouseclicks and other commands I give to it don't get intercepted by the script I'm trying to debug?
I currently have this kind of problem on both Firebug and on Chrome's inspector. The only solution I can think right now would be setting some smart breakpoints inside the appropriate event handlers but that is hard to do if I don't know what event handlers to look for or where they are hidden in the original code...
You could set a breakpoint and inspect after it is triggered, I have noticed that freezes the DOM.
You need to use breakpoints. As far as tracking down what's happening where, Chrome's "Call Stack" window can be very helpful.
Cheers
In Firebug you have a Break on next item in Script panel. Since Firebug 1.10, there's a keyboard shortcut for this: Ctrl+Alt+B on Windows (it works even if focus is in the page, not in Firebug).
You'll probably need to have Script panel focused in Firebug since this is a shared shortcut for Break on... which differs in each panel.
It generally freezes the DOM although it's not 100% reliable.
It's also not ideal because it will stop at any JavaScript execution, and will not be helpful if there is some aggressive polling in the background, or global capturing of keyboard events. Anyway it's still better than nothing.
Chrome pauses Javascript execution on F8; it took a bit of repetition but pressing F8 at the right time prevented JS from defocusing the element.
If you are having problem selecting the element, you can try cmd + shift + c on Mac to select the element without right clicking it.
If its DOM manipulation problem, you might try to force state on the input element by right clicking on the element in the Elements panel and set force state to focus.
Open the docked DevTools first (the undocked approach will not work due to the OS limitations.)
Once the autocomplete box is displayed, right-click it and select "Inspect Element" in the context menu. The focus will move to the DevTools but the autocomplete box will still be shown (this worked for me on Linux, tip-of-tree Chromium, M25. Your mileage may vary.)
/**
* Utility to freeze actual DOM state, for example dropdown menu
*/
function easyBreak() {
function doBreak() {
// put breakpoint here to freeze actual dom and write to console easyBreak()
// you have 3 seconds to get to desired state
var a = 0;
}
window.setTimeout(doBreak, 3000);
}
You could use DOM breakpoints.
I'm having a similar case here : I want to inspect dropdown items that only show when the input has focus.
On Chrome, I right-click on the parent element and choose Break on > Subtree modifications.
It will pause - like it does with JS breakpoints - anytime the DOM changes within that parent. You can then inspect the children while the DOM is frozen.
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.