Okay so I'm familiar with a few techniques for debugging events attached to elements. Events like click, mousedown, focus, etc.
Those are easy, but what I am trying to do is log the sequence of events triggered by jquery plugins (like sliders, form plugins, etc) when the document loads. There is some native markup what gets mutated when the page loads and new elements are introduced and some old ones changed or deleted.
Now I tried chrome tools and firefox and setting breakpoints to break on subtree modification on certain elements I'm sure are being changed but that only works after the page is finished loading.
What method would you guys suggest for debugging this kind of situation?
There is no code involved, its just an abstract, general situation.
After the page has finished loading, click on the "pause" button in Chrome Developer Tools, refresh the page, and it will pause right away -- you would be able to step through until the point you want prior to load. Make sure JQuery file, plugins, etc. are on the Development, unminified versions for this to work.
Related
I have a page with so many elements I dont need but I cant remove them because I dont see them in the html templates so I assume javascript is creating them at some point.
I would like to use Firefox developer tools to detect which functions are doing that in order to stop the page from creating those elements. What should I do? I use Firefox 53.0.3
Thank you.
First of all, you should verify whether the HTML is really added via JavaScript or it's already part of the page source.
To do that, right-click the page and choose View Page Source from the context menu or press Ctrl+U. In the source view search for the element, e.g. via its ID or its contents.
If you find it, it is obviously added within the server-side script, so you need to check there where it's added. If you cannot find it, it's added via JavaScript.
If the element is added by a specific action you do on the page, you can use Firebug's feature called Break on Child Addition or Removal, which allows to stop the JavaScript execution at the line where the change happened. To do so, right-click the parent of the element and choose the above option from the context menu.
A second way to find out where the HTML is added is by setting an event breakpoint for the load event. To do that, switch to the Events side panel, right-click the load event handler and choose Set breakpoint from the context menu:
Then reload the page. The script execution will stop at the related line. Starting from there, you need to step through the code until you reach the line where the element is added.
Having said that, Firebug is officially discontinued in favor of the Firefox Developer Tools and Firebug's Script panel doesn't work anymore in current versions of Firefox. (Also the option to set the breakpoint is missing.) Unfortunately, the Firefox DevTools are currently (as of Firefox 54.0) still missing the feature to break on DOM changes. There is already a bug report for it, though.
Having said that, the second option to stop at the page load is also available there. To do so, switch to the Debugger panel. In there click the button to expand the side panels (), then switch to the Events side panel. There you need to check the load event listener:
Then follow the steps as described above, stepping through the code until you reach the line where the element is added.
This is an extension of Brock Adams answer regarding the detection of userscripts by web administrators. Found here: link
What I'm going to discuss is hypothetical, as obviously avocation of this is not likely good behaviour.
Now. Userscripts in browser games. Let's take any browser game such as Neopets.
If you build a big fancy script to automate processes on any given neopets page, you likely need a control menu to activate various functions. One may use a floating iframe, or just add buttons on the page itself and hook them all up in the userscript.
The issue with this is that you're still changing the page itself, through addition or modification. Any administrator looking for scripts can check for triggered DOM manipulation events, could count iframe/input tags, etc.
My question is therefore, to minimize detection by administrators, how can you control different functions of a userscript running on a page without elements being added to the page itself (DOM)?
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.
We are building a site, and it has a ton of jQuery plugins and misc code from several developers. Somewhere a keydown even was trapped by the document. (Basically the spacebar no longer has it's default browser usage, i.e. scrolling, selecting checkboxes, etc.) Using Chrome's debugging tools, the origin is jquery-1.7.2.min.js line 3-- Not a lot of help.
I was able to "fix" the issue by running $(document).off('keydown'); at the end of window.onload function, but I dislike this fix terribly.
Is there an easy way to find out where the original binding occurred? (My guess is that some plugin defaults to "document" when not supplied with an element.) What I have done so far:
Grepped through the source for "keyCode" and removed any plugins that trap the spacebar. Removed other non-obvious plugins. I can continue with this, but I'm looking at a lot of grunt work.
You can open the developer tools in chrome, click inspect element on document's body element, scroll the right panel down to the bottom and view Event Listeners, it is probably attached to the body element or some other very big container. Check the listenerBody under the keydown event.
I am trying to write a JavaScript script that is "overlayed" on top of a Facebook page. It uses DOMContentLoaded to detect when content is loaded, then adds some extra stuff in. However, because Facebook doesn't actually "reload" the page when going to a new page (it just uses AJAX), the DOMContentLoaded handler doesn't run again, even though there is new stuff to look through.
Anyway, to detect the change, I thought about using onhashchange since Facebook used to change the page's hash, but in Firefox 4 (I need to support Firefox 3 and later with this, but no other browsers), Facebook doesn't change the hash anymore and in pre-Firefox 3.6 there is no onhashchange.
I thought about using DOMNodeInserted, but would that really slow down the page? (I really can't have any slowdowns in this script.)
you might want to monitor the windows.history object, see the following answer, on how facebook uses it to update pages:
"Redirect" page without refresh (Facebook photos style)
For lightweight pages it generally doesn't have noticable effect. However, on bulky pages (I tried this on gmail) it makes that really really slow that I cannot even compose a message smoothly. And that event was added to a very simple span element which just had a single link in that. The events like DOMNodeInserted and DOMSubTreeModified are real show stoppers.
UPDATE: For all those trying to find an answer to this, note that these methods DOMNodeInserted (or DOMSubtreeModified) really had performance problems, so according to new ECMA specs it is a much faster listener : MutationObserver for doing the same thing (and more).
https://hacks.mozilla.org/2012/05/dom-mutationobserver-reacting-to-dom-changes-without-killing-browser-performance/