So I am working on an issue where on load an item is gaining focus and I don't want this to happen, I am attempting to figure out why this is happening.
so I go into chrome and set the Event Listener Breakpoints for focus and DOMfocusIn/focusOut, but it doesn't seem to matter, the page will load, and I will see the anchor tag (used for a button) gain focus right after, but it doesn't trigger the breakpoint.
What is more weird is that when I break on load of the page and resume it, it no longer gains focus (although everything else seems to work fine)
Why does hitting a break point prevent focus?
and Why does it not hit a break point when I set the event listener to focus?
is there a way to give focus unintentionally? (ie. without an obvious focus function call)
I think this is a bug, I found a way to figure this out. essentially I added an onFocus function to anchor tag in question and made an alert with the following code:
alert(arguments.callee.caller.toString());
This shows who was calling the onFocus, and it actually worked, so I think this means it is a chrome specific bug.
I had to add the onFocus with javascript due to the code being in a taglib and no onFocus attribute available, but it worked.
Related
I need to execute some native code to interact with the macOS menu bar, ideally immediately after it got initialised. IMHO, a good time would be right after the JavaFX application window becomes visible.
From the documentation, I thought that Window.onShown should do exactly that:
Called just after the Window is shown.
But that does not seem to be the case. When putting a breakpoint into the event handler for Window.onShown, the window is not yet visible. Unfortunately at this point, the macOS menu bar is not yet fully initialised, so all my changes to the menu bar would be overwritten later by JavaFX's default menu bar.
For now, I'm just using a delay of 1sec after the WindowEvent.WINDOW_SHOWN is sent, but that does not seem to be a good solution. So does anyone have a better idea on how to reliably determine when the window is actually visible or all initialisations have finished?
If you put a breakpoint in the onShown method the problem might just be that the window was created but you are blocking the visualization because of the debugger.
If this is not the case you could try to create a new Thread that only checks for the visibility of the window using the isShowing method of the class Window.
This should be faster than just waiting for one second after the onShown method was called.
I’ve encountered a problem I can’t solve.
I’m working on a project with MFC in Visual Studio. The problem is, sometimes GUI just stop visibly reacting, but technically it keeps doing the functions it was intended to do. It means, when I press a button, the function OnBnXXXPressed is executing, but the button doesn’t look like it was pressed, as if I’ve pressed on a picture of button, not the button itself. And it’s not just this button — every other element of GUI seems to keep working, but doesn’t show that it is working.
Also, in this state dialog windows don’t show up upon their call. If I call AfxMessageBox, the message box won’t show up, and the thread that called this function, will not be blocked; AfxMessageBox will basically be skipped.
I have absolutely no idea what can possibly cause that behavior. The question is: what should be happening in program for it to behave this way? Especially if it’s built with MFC?
The project consists of 50+ files, and every function responsible for GUI makes changes to the elements it is about. I do not know where the error is, and I ask you, to the very least, where should I look for it.
Thank you for attention!
The answer was originally provided in the comment section. My code indeed has a GDI resource leak that was provoking this behavior.
When a button is clicked, are you doing a bunch of processing, or do you return fast? If you don't return, maybe locking the UI thread. After a user presses on the button, how long is it taking before the OnClick for that finishes running?
If that's it, here's some more info: https://learn.microsoft.com/en-us/windows/desktop/Win7AppQual/preventing-hangs-in-windows-applications
The solution I've generally used for long-running logic on a UI click is to run it a background thread.
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:
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 have this odd problem with a third party script. On our site a popup window loads a demo of one of our applications when a link is clicked. The third party script is supposed to popup an additional window underneath at the same time or sometime thereafter.
(Yeah this sounds crazy but the popups must load in this way.)
Of course this works fine in FF3.
Problem is in IE6 only the third party script pops up, but not the demo popup. If I click the link again the demo popup works.
After the thirdparty script saves it's session cookie it's window doesnt popup anymore but then the Tools popup works. (if i reload the page and it saves the cookie info -- this is the expected behavior. the third party popup should only load on the first session)
Seems to me that at some point down the wire windows.open isnt getting called properly because of some timing issue or windows.open being redefined somewhere. I don't see any error messages.
To pinpoint the issue I thought I'd have to see whats going on with the windows on the click.
I guess I need some help in figuring out what information I should look for to try and debug this issue.
This'll tell you if you're dealing with the real window.open or a redefined one:
var isOpenNative = /\[native/.test(window.open+'');