Page MenuHome GnuPG

The overlay used by GpgOL does hinder usage of other apps
Open, NormalPublic

Description

GpgOL uses the "overlayer" tool from gpg4win-tools.
It is utilized when a mail is send which has to be encrypted. In that case the overlayer comes up and stays above the mail window while the pinentry window is open.

The pinentry window will appear above the overlay, but no other window can be raised above it. And it is not possible to make the Outlook window smaller while the overlay is active.
This is a problem when people use a password manager for the password which has to be entered in the pinentry. They won't be able to get to their password if the mail and the password manager windows have overlapping positions. Which can happen easily as the default mail compose window size is often almost the whole screen.

Additionally, the overlay is not only on the desktop of the one where Outlook is, but also on the others…

Please check what we can do regarding this. Ideas:

  • make the overlay smaller so that the mail window can be resized (in theory, the overlay should check periodically if the window was resized and adapt its size, too)
  • keep the overlay to the relevant desktop (though not all Windows installations have the desktop switcher tool)

Event Timeline

An easy solution seems to be to just tell the overlay to not be always on top. It still blocks the outlook window, but other windows can then be shown on top of it.

The behavior isn't entirely amazing - the pinentry will still be on top of the other window, but it can at least be minimized away - but it should be much better than it is currently.

You can test with gpg4win-5.0.0--overlay.exe in my shared folder

Well it kind of works but it is a bit ugly and the encoding in the "Encrypt" message is broken:

But the biggest issue: if you click on the mail composer window in the task bar, you can get the mail window out from under the overlay…

I suspect there's also a bug somewhere between qt and windows involved here: The overlay is supposed to be modal to the composer window, so it shouldn't be possible to move the overlay behind the compositor. This is probably the reason why the overlay is forced to stay on top in the first place...

Statements like in https://bugreports.qt.io/browse/QTBUG-55669 don't make me hopeful about fixing it, though...