#1496 AutoType fails if "Enter Master Key" dialog is confirmed with "<enter>" key

[tbone78]

With a locked workspace or not yet opened database, the "Enter Master Key" dialog comes up after pressing the AutoType hotkey. After entering the master key, you need to use the mouse to click "Ok" in that dialog to make the AutoType work. If you confirm the dialog with "<enter>", which would be much more convenient, the current focus in the input field, where the AutoType information shall go, is switched to the next field (which is password in most cases) and the login is going to fail.

This happens for me on two machines, both use KeePass v2.32, Win7-64, multiple monitors.
Don't know if this issue is related to my system configuration, so this might be relevant to everyone.

Step by step:
- Webpage or any other form prompts you to login
- Username field has focus
- KeePass AutoType hotkey is pressed
- Enter Master Key dialog appears (because workspace locked, db not opened)
- Master key is entered and dialog confirmed with <enter>
- Focus on form has switched from Username to Password
- KeePass starts inserting credentials
- Username is auto-typed into password field
- Login failed!

The switching focus from username to password field, before the AutoType starts, does not happen if you confirm the Enter Master Key dialog with mouse on "Ok".

[wellread1]

initiate-auto-type-unlock-db-execute-keystroke-sequence is a common sequence of events in the KeePass world. I have not observed the behavior you are describing during this sequence of events, nor has it been previously reported. It seems unlikely that it is a KeePass bug. I suspect some idiosyncrasy in your setup, or a particular web page is responsible.

• Could it be a sticky Enter key? or is the repeat delay on the keyboard set unusually short: Control panel>Keyboard>Speed>Repeat delay? or could it be due to an unconscious double tap?
• Do you have some software installed that monitors or processes keyboard input?
• Does the problem occur on all sites all the time, e.g. does it also occur on http://keepass.info/help/kb/testform.html or just a particular site or small number of sites some of the time? Some web pages are sensitive to focus changes (switching to KeePass and back) and the auto-type keystroke sequence has to be adjusted to accommodate that.
• Does the dual monitor affect auto-type behavior? Check by unplugging/disconnecting one monitor.
• Do any triggers execute on database unlock/open? If so what do they do?
• Are you using default KeePass settings? If not what settings are different? esp settings that might alter KeePass behavior after database unlock/open e.g.
  • "Enter master key on secure desktop" in Tools>Options>Security(tab)>Options(section)?
  • "Lock workspace after...." in Tools>Options>Security(tab)?
  • "Minimize main window after opening a database" in Tools>Options>Interface(tab)>Main Window(section)?

[tbone78]

I checked all your questions, they kind of helped to move further, thanks! o) I found out, that it's the KeyUp-Event for the <Enter> key that leaks through when using <Enter> from the "Enter Master Key" dialog.

Pressing <Enter> with the "Cancel" button in focus yields the same result btw., so that maybe nice to know when testing some things (no need to unlock/lock the db each time).

I created a minimal test page, which shows you the incoming keyup-events, which (from my point of view) should not get there. But I must admit, I actually have problems deciding who is to blame (windows, the regarding browser or keepass). http://marcusbonin.de/keepasstest.htm

I was wrong in my statement, that it happens always and for every form there is.
It seems to be related to web forms only, which listen to "keyup" events with javascript (to switch input fields) and it does not occur with all browsers out there. It does not occur with IE v11, current Vivaldi (Chrome-engine) or Chromium (Chrome-engine as well) e.g., but the problem is reproducable with Opera v12 and Firefox.

The thing is, if KeePass misses to handle/swallow the keyup event, which occurs after the dialog has been closed by <Enter>, then this could be a KeePass issue indeed. It's hard for me to investigate further, since I'm not a system level developer.

[wellread1]

Can you provide an example of a production web page (preferably a well known site) that exhibits the bad behavior? I can only confirm the behavior on your example page.

The bad behavior is exhibited by your example page http://marcusbonin.de/keepasstest.htm using Firefox 45.0 in safe mode, or with a new default profile, or using my working Firefox profile, on Windows 10 x64 Home, with KeePass 2.32 using default settings. The first three KeePass options in the 'Auto-Type Sending' section have no impact.

Auto-Type on db unlock works fine on other web pages e.g. http://keepass.info/help/kb/testform.html.

Also, auto-type on db-unlock works fine on your example web page using Firefox 45.0 with a default profile and my heavily customized working version of KeePass 2.32 e.g. it runs both a plugin (KeeAutoExec), and a database synchronization trigger at db unlock.

A workaround keystroke sequence for any affected web page would be problematic because the appropriate keystroke sequence would be dependent on the locked/unlocked state of the database.

[Dominik Reichl]

Thanks for reporting this issue.

However, I do not consider this to be a KeePass bug. On all modern operating systems, controls supporting keys like Enter or Esc for performing some action typically react on such keys in key down events, not key up events. It happens all the time that a control receives a key up event without a corresponding key down event.

For example, open your test page in a browser and run Notepad. In Notepad, open the 'File' menu, navigate to the 'Exit' menu item (using arrow keys) and press the Enter key. Notepad then closes, the browser gets the focus and your test page receives an Enter key up event when releasing the key, and reacts on it (which is unexpected).

The correct way to resolve this situation is to change the target application (web site) to react on key down events, not key up events.

Although I could imagine that KeePass could wait until keys like Enter are released, I don't think this would be the right approach and it would likely introduce other problems. As I'm not aware of any major application or web site violating the key down/up convention, I'm not planning to implement such a workaround.

Best regards,
Dominik