I have a button which posts back through Ajax. I tried to find out what code executes when the button is clicked. I used Visual Event (screen capture below) to see how the event was bound but the info didn't help me enough. Then I set an event listener breakpoint on mouse clicks in Chrome. The breakpoint hit code in the main jQuery file which was also not helpful. So I blackboxed the file. Now when I click the button, no breakpoints are hit.
What's a systematic way to find the user code which gets executed? I also searched for 'live' and 'click' as text across the whole app. It was time consuming and didn't find where the click event for the button got attached. It's painful to do such a search. I would like to know the productive technique using Chrome's debugger or another tool. (Another browser's tips are OK)
Have you tried the Chrome profiler?
Launch the Chrome DevTools (F12)
Go to the Profiles panel
Ensure that Collect JavaScript CPU Profile is selected
Click Start
Perform your operation
Click Stop.
Then you should see a list of functions that were called.
There are several possible ways to do so. One is described by the user thesentiment. Another way is to use the DevTools' debugger.
Open the Chrome DevTools (F12)
Switch to the Sources panel
Click the Pause button () or hit F8
Perform your operation
=> The script execution will stop at the first line of the event handler function within jQuery. You can then step through to your actual event handling function.
Note that in Firebug this works much easier, because its Events side panel already displays the wrapped listeners, i.e. the functions that are called by a jQuery event listener:
Related
A button in a website triggers a popup menu when clicked (only when clicked, and not when hovered over). I want to be able to inspect this popup menu but after I right click it and select "Inspect Element", it disappears so I can no longer inspect it.
When the popup menu is displayed, I can see that an entry for it appears in the HTML in the Inspector tab but when I click the entry, the popup menu disappears an so does the HTML entry.
For cases in which a menu appears when a button is hovered over (not clicked) I would click an entry in the Inspector tab to switch focus to it, then I would just hover over the button and use the arrow keys to navigate to the entry in the Inspector tab. But since this button needs to be clicked, then I lose the focus on the Inspector tab.
I thought this could be solved by switching the focus to the Inspector tab in Firefox's Web Tools without clicking anything.
I've tried using different shortcuts such as Ctrl+Shift+C or Ctrl+Shift+I (opens the Web Tool) but I haven't been able to switch the focus to the the Inspector tab to navigate through the HTML after using these shortcuts.
I've also tried using inspect mode (the button left of the Inspector tab), which lets me inspect anything I click. The problem with this method is that to get to the menu I need to click a button first and inspect mode only inspect the first thing I click. Maybe there's a way to ignore the first click while on inspect mode?
EDIT:
Pressing the TAB key numerous times, sometimes focuses on the Inspector tab. Sometimes it just loops through the elements in the website and never focuses on the Inspector tab. Even so, the times I was able to use TAB to focus on the Inspector tab, the popup menu disappeared after pressing TAB about 20 times so I need a different method that doesn't use the TAB key.
I have a deviantart account so I was able to reproduce the issue you described.
The problem is that the popup that appears on click is hidden when the window is blurred or when the page gets clicked. And because focusing the inspector will always cause the content window to blur, there's no way you could switch over to the inspector while keeping the popup displayed.
So, as #Callahad said in a comment, the only viable option here is to use a breakpoint to force the javascript code to pause at a certain point in time that lets you inspect the popup without having it be closed under you.
Now, the question becomes: what is this point in time, and how can you set a breakpoint there.
When the popup appears: this happens when the edit button's element is clicked. If you could add a breakpoint to this exact line in the debugger panel, then you'd be able to click on the edit button, and step through the code until the popup is shown, and then switch over to the inspector again to inspect it. Unfortunately, the javascript event handler for this is in a onclick attribute on the node, and you can't set a breakpoint there.
When the popup is about to be hidden. This happens on window blur. To set a breakpoint there, you could try and follow these steps:
find the html element in the inspector (that's the element where events added to window are shown),
click on the [ev] icon next to it,
find the "blur" event in the list that appears,
click on the debugger icon next to it, this takes you to the debugger at the right line, hopefully
maybe pretty-print the code if needed, using the {} button in the lower left corner of the debugger
add a breakpoint at the right place in this code
and then just click to show the popup, and then click outside the window, this will pause the javascript execution where you added the breakpoint, which is, just before the popup gets hidden, therefore giving you a chance to switch over to the inspector and inspect the popup before it closes.
The popup also gets hidden on page click, so you could do the same thing by looking at this event.
Another valid approach could be:
Override the code that hides popups! Javascript is dynamic, so you could totally turn this to your advantage. Find the function in the deviantart code that hides popup, and change it.
By quickly looking at what was on the window object in the web console, I got lucky and found: Popup2.hideAll. So if you just run this in the web console: Popup2.hideAll = function(){}, and then open the popup, it will just stay there and never get hidden again until you reload the page. This gives you a good way to inspect it.
Last, one very good way to work with DOM changes like this would be to have the "break on DOM mutations" feature in the devtools. Firebug has this, Chrome devtools too, unfortunately Firefox doesn't yet.
The idea of this feature is simple, in the inspector: right click any node (in this case, the parent element of where the popup would appear in the DOM), select "break on mutation", then click to open the popup. When the popup gets inserted into the DOM, devtools would see this and automatically halt javascript execution.
I have a very large accounting system. In a user preferences section, the program has begun to act abnormally on my development machine only. No customers are reporting this, nor can I duplicate it on any of my other computers. Running Windows 8.1, others are on 7.0. Not exactly sure when this started happening because it's not the kind of thing one goes into on a regular basis. The preferences screen consists of a tab control and various standard controls. At the bottom is Okay, Cancel, and Apply buttons. All three buttons seem to be acting with the same strange behaviour. Clicking with a mouse does not generate a click event yet does not hang the system - mouseup follows and you can click it again and see the mousedown and mouseup but no click. However, since the Okay is defined as Default, pressing enter DOES create the desired click event, and all the code inside that even runs fine. Cancel and Okay also unload the form, but when clicked, that doesn't happen because none of the code gets executed, yet you can still navigate the screen (move between tabs and controls) but you can't even click the "X" button to close the form at that point.
Also, if you go straight in, and press enter, everything works and the form unloads, but if you do anything before pressing enter (or escape to cancel), like change a tab and/or edit a value, then press enter, the click event again does not run and the system semi-hangs.
I tried turning-off my anti-virus thinking that might have something to do with it, but no-go. Debugging is frustrating because while I finally got it execute the click event, the stop command inside that event (after debug.print "click") would allow stepping and success if just straight in and enter, but if anything else done as before described would stop at the stop statement (keyboard enter only still no mouse clicks under any scenario) and would do a total lock-out. In other lockouts where it would let me navigate, almost always selecting a new tab would cause a fatal error and it would force-unload VB for me, otherwise I had to use the task manager.
This is driving me nuts, but I don't know how else to debug it.
The culprit was tv_w32.dll which is Team Viewer. Turning-off Team Viewer allows my program to run normally.
I've got Firebug open on my website, and then I click a button which opens a popup window. However, Firebug is always greyed out by default in the popup window. I can click the icon or press F12 to start it, but I really need it to start itself, immediately, because I want to watch the AJAX requests that happen on page initialization of the popup window. By the time I click or press F12 it's already too late; it's missed those requests.
How do I get Firebug to persist in my popup window?
There is an option in the Firebug menu called On For All Web Pages, which opens Firebug automatically. Though unfortunately that also doesn't allow you to track the network requests.
So this actually looks like a bug to me. You should report that in the Firebug issue tracker, so it can be fixed.
My task is to implement a file upload form in a popup sub-menu panel. I am using XmlHttpRequest, so it's important to keep that popup opened until I receive an event status that file loading completed/failed. Onmouseover and onmouseout events are used to show/hide the popup.
On "hide" the popup panel is detached from the DOM, and cannot be used anymore as a listener for XHR events.
When I click form's "Browse" button, a system dialog window is opened above the browser. In IE, Chrome and Firefox in Windows the system dialog disables events handling by page. Which means if you move a mouse cursor out of the dialog window on one of the page element, the page won't do anything like reacting on mouseOver/mouseOut events. Unfortunately, in case with Chrome/Firefox on Mac (Safari is OK) the page elements do react on mouse over/out. And my popup menu becomes closed (due to mouseOut event handler for the popup) -> XHR response is not managed properly.
Assuming having an upload form in a popup is a must, what are the possible ways of keeping that panel/form visible while system Upload File dialog window is up? Probably a Mac specific solution.
Sample code can be seen here http://jsfiddle.net/xqvXG/
Solved this by freezing popup panel and covering the whole page with transparent div ('glass').
In case if user chooses file(s) and upload starts, I remove the glass and unfreeze the popup using the XHR function readyStateChangeHandler (or may do that in handler of load event).
If user clicks Cancel in system dialog window or closes it with "X" button - no events passed to the page and 'glass' remains on screen. Then any click on the 'glass' causes its removal and unfreezing (or simple hiding) the popup menu.
'Glass' is required to make a single one-click point (panel) for unfreezing the popup in case if Cancel/Close were pressed.
I wouldn't say this is a perfect solution (sometimes required extra action), but very close to what I was looking for.
I am using autoit to handle javas script popup code as
autoit.WinWaitActive("[Class:#32770]")
result =autoit.ControlClick("[Class:#32770]","","Button1")
But when I click on the button to open the popup it waits for a longer time & if the user is performing operations on another window, it will no go further. Only when the user clicks on the current window does it work. Means user should be focused on IE browser at the time of javascript popup.
Most tools that work up at the OS UI level (as autoit does) require that the window to be worked on has focus in order to have things like clicks or keyboard input end up in the correct window.
You'll probably want to set the focus first, then try to click, if you are using autoit
There are other methods for dealing with JS popups, especially with more current versions (1.9.0 or above) of watir, which are more elegant. Refer to the Javascript Popups page in the Watir Wiki
Do be aware that most of the solutions you see presume that the browser will have focus. If you need to run scripts at the same time as doing other work and don't want what you are doing to interfere, I might recommend using a virtual machine to run the scripts