For Web front end programming, since any JavaScript can set up an event listener for “mouseover” or “mouseenter” for an element, if we are to track down what is the code that is responsible for making a hover box come out?
For example, if you see that when you hover the mouse over an element, with the class hover-box-cont, and you grep for the existing code base, and there is no hover-box-cont occurrence that is part of JavaScript code which looks like it is $(".hover-box-cont").mouseover() or mouseenter() (and in fact there is no JS code at all related to hover-box-cont), then what is a good way to track down what is the code that is responsible for popping up a hover box?
(Since the page is partly in AngularJS, I also grep for hoverBox because AngularJS directives automatically use the JS name hoverBox to map to hover-box in the HTML, but I can’t find anything for hoverBox either)
One method I thought of was to set a listener (handler) on an inner element on the event mouseover, and set a breakpoint on that handler code, so that it is possible to “step over” the code line by line to see which line of code is executed afterwards. But to my surprise, when I use another app to cover up the region and show the item that I set a handler on, and I move my mouse over it and click, the hover item already pops up before the breakpoint on my handler. I thought it might bubble up from my inner element first, before going to that outer region for the handler I am trying to track down.
There are about 20 external JavaScript files (some local, some on CDN), so it is difficult to track them down one by one, or what if we can go through all 20 of them one by one, what if there are 50 JavaScript files? There should be a better way than to reading into those 50 JS files one after the other?
2
Three approaches I would try that might work, depending on your code and how the handlers and elements interact;
First, you could try using the Chrome dev tools “Timeline” tab.
- Click record
- Perform your action
- Stop recording
- Analyze result to see if the JS that caused the element to change can be tracked down
Second thing you can try (again in Chrome) is to find the element that changes on mouseover in the “Elements” tab.
- Select the element that you think responds to mouseover.
- On the right side of the dev tools there is a “Event Listeners” tab.
- Uncheck “Ancestors”
- see if the is a handler listed for “mouseover”.
- If no handler is listed, choose that elements parent and check again, moving up the element hierarchy.
If you do find a handler this way, it will be listed with a link that navigates to the source where the handler is defined. Go there, set a breakpoint, and perform the mouseover again. Then you can work backwards up the stack trace.
Third attempt, which should work if the mouseover works by manipulating a class on the element to cause the change.
- Again find the element that changes in the “Elements” tab of the dev tools.
- Right-click on the element and pick “Break On… > Attribute Modifications” and also “Subtree Modifications”
- Perform the mouseover and see if the script debugger halts on the element change.
If it does stop, it will be at the line of code that changed the DOM element, so you will have to backtrack up the stack trace to find the origin of the call.
Edit:
If you want to text search all loaded .js files, in Chrome open the dev tools to the “Sources” tab. Press shift+ctrl+f (on Windows. Not sure what the Mac key is) which will open a search input that will search across all loaded script files.
Hopefully one of these helps. Good luck!