Activate global auto-type in a browser, and move to AutoTypeSearch - that works. If the search text isn't found, KeepPass opens. Find a key and auto-type from there. At that point the focus is on KeePass, not the browser. So the keystrokes are directed at the KeePass UI. It's VERY scary when several keys suddenly get selected and KeePass is asking to confirm deletion.
I've been struggling with this problem for a long time and finally got a chance to narrow it down to this plugin. Maybe KeePass has reset focus to the ATS search dialog which is now closed and then there is no target window, so it defaults to itself. That would be a KeePass issue. I'm a C# developer but not familiar with the internals of KeePass or ATS. So I'm hoping you can use this report to get to the heart of wherever the issue is. I'll be happy to run a debug version to help trace the problem.
For now I need to disable ATS because this scenario happens way too often but I will re-enable and work with you whenever you're ready. Thanks for the time you've taken to create and offer this FOSS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure I'm reproducing this properly, can you confirm some steps for me?
Press Global Auto-Type hotkey in browser, where no matching entry is available
AutoTypeSearch window appears
Type a few characters to find and highlight an entry, and press Enter
AutoTypeSearch window disappears
AutoType sequence is typed into the browser window
I'm not sure which part of this is not working for you, is it that for you between step 4 and step 5 the main KeePass window is being brought to the foreground, and keystrokes sent to that? If so, was the KeePass window visible at all before starting? Or if it was minimized, does it get restored? Which OS are you using?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry it's taken so long to find time to get back here. But I AM motivated to solve this problem. I have removed ATS but am still getting the problem with KeePass, so this is Not your issue. I will present this back to the KeePass dev(s) but I'm hoping you can help to define and verify the issue. I'm sure you'll have much better success reporting an issue than I.
So far the problem feels random, but I'm sure there is some sequence of events that's triggering it. I will pay close attention to keystrokes related to browser logins to see if I can come up with a reproducible condition.
Correct
Actually just the standard KeePass Find window has the same issue.
Correct but need to verify exactly what triggers this.
(KeePass Find window closes)
Not correct. As you noted, the sequence is keyed into the KeePass window itself, resulting in a confirmation to delete all of the KeePass entries that are currently displayed.
I believe the KeePass window needs to be initially open for this to occur. It does not restore itself when the Find dialog is opened.
This is Win8.1x64. I'm a developer so I have VS and pretty much every version of .NET and C runtime installed.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No triggers - and I just disabled the trigger feature. I'll try without source for a bit but will get the source for the current (now v2.40) release soon if required.
For now I'll keep the UI visible and continue exercising the global hotkeys to see if I can find a pattern. Thanks!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Activate global auto-type in a browser, and move to AutoTypeSearch - that works. If the search text isn't found, KeepPass opens. Find a key and auto-type from there. At that point the focus is on KeePass, not the browser. So the keystrokes are directed at the KeePass UI. It's VERY scary when several keys suddenly get selected and KeePass is asking to confirm deletion.
I've been struggling with this problem for a long time and finally got a chance to narrow it down to this plugin. Maybe KeePass has reset focus to the ATS search dialog which is now closed and then there is no target window, so it defaults to itself. That would be a KeePass issue. I'm a C# developer but not familiar with the internals of KeePass or ATS. So I'm hoping you can use this report to get to the heart of wherever the issue is. I'll be happy to run a debug version to help trace the problem.
For now I need to disable ATS because this scenario happens way too often but I will re-enable and work with you whenever you're ready. Thanks for the time you've taken to create and offer this FOSS.
I'm not sure I'm reproducing this properly, can you confirm some steps for me?
I'm not sure which part of this is not working for you, is it that for you between step 4 and step 5 the main KeePass window is being brought to the foreground, and keystrokes sent to that? If so, was the KeePass window visible at all before starting? Or if it was minimized, does it get restored? Which OS are you using?
Sorry it's taken so long to find time to get back here. But I AM motivated to solve this problem. I have removed ATS but am still getting the problem with KeePass, so this is Not your issue. I will present this back to the KeePass dev(s) but I'm hoping you can help to define and verify the issue. I'm sure you'll have much better success reporting an issue than I.
So far the problem feels random, but I'm sure there is some sequence of events that's triggering it. I will pay close attention to keystrokes related to browser logins to see if I can come up with a reproducible condition.
I believe the KeePass window needs to be initially open for this to occur. It does not restore itself when the Find dialog is opened.
This is Win8.1x64. I'm a developer so I have VS and pretty much every version of .NET and C runtime installed.
Thanks!
Hmm... are you using any triggers? You could try disabling the trigger system, see if that stops it.
As you have Visual Studio and .net installed, then you can run KeePass from source in the debugger: https://sourceforge.net/projects/keepass/files/KeePass%202.x/2.39.1/KeePass-2.39.1-Source.zip/download
A breakpoint in UIUtil.SetWindowState may proove enlightening.
No triggers - and I just disabled the trigger feature. I'll try without source for a bit but will get the source for the current (now v2.40) release soon if required.
For now I'll keep the UI visible and continue exercising the global hotkeys to see if I can find a pattern. Thanks!!
Haven't been able to trace this down yet. Issue posted to KeePass forum.