On which OS resp. with which window manager does this problem occur?

This occurs on Windows. But if a raise is really missing, it might also occur with other window managers.

I'm also seeing this, but that's probably due to me using "focus follows mouse" and the pinentry being a different application. When the pinentry goes away the window manager gives focus to the window below the mouse which very often isn't Kleopatra when I have been testing keyboard navigation.

I'm wondering if this happens when users have made some other application window active. In this case, I'm pretty sure there is no way on Windows to bring the result dialog to the front. An alternative might be to use a notification to inform the user that the operation is completed, either always or only if we notice that the result dialog isn't active.

I have seen this when doing the following:

• Start Kleopatra and minimize its window
• Start decrypt&verify operation for an encrypted archive in Windows Explorer with GpgEX

Observation:

• Nothing seems to happen. In fact, the result window opened behind the Windows Explorer window.

Note: I wasn't asked for a password (because it was still cached). But even if I'm asked for the password (pinentry opens on top of Windows Explorer) the result window still opened behind Windows Explorer.

This also happens if one activates the Kleopatra main window, then activates the Windows Explorer and then starts a decrypt&verify operation.

Funny enough, it does not happen if one activates the result window, discards it and starts another decrypt&verify operation. In this case the result window has always opened in the foreground in all tries.

Just in case it matters: I'm using the mouse for everything.

I'll backport this because this issue is a really bad usability problem for people using the Windows Explorer integration to decrypt files. And the regression risk is minimal.

Backported for VSD 3.3.x / Gpg4win 4.4.1