Page MenuHome GnuPG
Create Task
Maniphest T7943

Kleopatra: OK button to set card cardholder/url needs two clicks
Closed, InvalidPublic
Actions

Description

To reproduce:

  1. Open Smartcard dialog
  2. Edit Cardholder or Public key URL
  3. Change the value
  4. Click OK -> first click is ignored (can be repeated if the value is changed again)

Notes:

  • Resetting it (changing the value to an empty string) is an exception and works on the first click
  • Might be a regression from https://dev.gnupg.org/T7881 (not sure)

Details

Version
gpg4win-5.0.0-beta413 @ win11

Related Objects

Event Timeline

timegrid created this task.Nov 21 2025, 1:41 PM
timegrid created this object with edit policy "Contributor (Project)".
timegrid added a comment.Nov 21 2025, 5:36 PM

Actually pinentry has the same behaviour, so this might be a general problem, if one form input field is changed.
It also applies to clicking on other form elements.

To reproduce:

  1. Create a new certificate with passphrase
  2. On pinentry
    1. Enter the passphrase in the first input field
    2. Click on the second input field (Repeat) -> needs 2 clicks
    3. Enter the repeated passphrase
    4. Click on the first input field -> needs 2 clicks
    5. Change the first first passphrase again
    6. Click on "show passphrase" button -> needs 2 clicks
    7. Change second input field
    8. Click OK -> needs 2 clicks
• ikloecker added a comment.Nov 24 2025, 9:59 AM

This isn't reproducible on Linux. (Tested with a Yubikey but that should really make no difference.) Maybe a regression of our Qt patches.

• TobiasFella added a subscriber: • TobiasFella.EditedNov 24 2025, 2:49 PM

I can reproduce on windows. It's not that the Button itself needs to be pressed twice, *something* in the dialog needs to be pressed before the button reacts. So this looks like it's something about focus

• ikloecker added a comment.EditedNov 24 2025, 4:09 PM

Or Window activity (which is related to focus). I'm wondering if one of my Qt patches is to blame.

• TobiasFella added a comment.EditedNov 24 2025, 4:49 PM

yes, it seems to be caused by one of the patches. I'm trying to figure out which one...

• werner added a project: token.Nov 24 2025, 6:03 PM
• TobiasFella triaged this task as Normal priority.Nov 25 2025, 11:32 AM
• TobiasFella claimed this task.Nov 25 2025, 12:42 PM
• TobiasFella mentioned this in Unknown Object (Maniphest Task).Dec 1 2025, 9:41 AM
• TobiasFella mentioned this in Unknown Object (Maniphest Task).Dec 8 2025, 9:32 AM
timegrid raised the priority of this task from Normal to High.Dec 12 2025, 11:22 AM
• TobiasFella mentioned this in Unknown Object (Maniphest Task).Jan 5 2026, 9:46 AM
• TobiasFella mentioned this in Unknown Object (Maniphest Task).Jan 12 2026, 9:41 AM
• TobiasFella mentioned this in Unknown Object (Maniphest Task).Jan 19 2026, 9:49 AM
• TobiasFella removed • TobiasFella as the assignee of this task.Thu, Jan 29, 3:42 PM
• TobiasFella removed a subscriber: • TobiasFella.
• ikloecker mentioned this in Unknown Object (Maniphest Task).Mon, Feb 23, 9:00 AM
• ikloecker claimed this task.Thu, Feb 26, 9:11 AM
• ikloecker moved this task from Backlog to WIP on the gpd5x board.
• ikloecker added a comment.Thu, Feb 26, 9:35 AM

I cannot reproduce this with the released Gpg4win 5.0.1 on Windows 10 (VM).

timegrid added a comment.Thu, Feb 26, 9:49 AM

I can still reproduce this with gpg4win-5.0.1 @ win11

• ebo closed this task as Resolved.Thu, Feb 26, 10:00 AM
• ebo edited projects, added gpd5x (gpd-5.0.0); removed gpd5x.

Me neither, neither on Win10 or 11. I tried the original description and https://dev.gnupg.org/T7943#208784

Must have been gone in the release for 5.0.0.

• ebo reopened this task as Open.Thu, Feb 26, 10:12 AM
• ebo edited projects, added gpd5x; removed gpd5x (gpd-5.0.0).

I was too fast with closing this, seems it is reproducible under special conditions. But not by me, here it works.

• ikloecker changed the task status from Open to Testing.Thu, Feb 26, 10:33 AM

It turns out that the problem occurs if one clicks with the mouse quickly (< 1 s) after typing a character.

With this "technique" I can reproduce the ignored mouse click with the input field and the drop down or Cancel button in procmon.

In other words, this seems to be a general problem. Maybe VirtualBox is causing this. This should be checked on a real Windows machine.

In any case, this ticket should be closed as not-our-bug. I set it to Testing so that it's tested on a real Windows machine.

timegrid added a comment.Thu, Feb 26, 10:55 AM

I'll also retest this with gpg4win-5.0.0-beta413. I think, this bug was different back then (no need to do it quickly). If it's gone there, too, it might have been a virtualbox or win bug. If it's still there, it might hint at qt/kde.

In any case the current behavior of < 1s is not that problematic.

timegrid added a comment.Thu, Feb 26, 12:10 PM

Ok, the behavior in gpg4win-5.0.0-beta413 @ win10 is the same (< 1s).
I can also reproduce the same behavior in other windows dialogs, e.g. in the explorer (changing the location address, clicking on the search input field).
So i'd also say, that this is a virtualbox or win issue and would just close this as invalid without further testing?

timegrid closed this task as Invalid.Thu, Feb 26, 1:27 PM
timegrid moved this task from WIP to Done on the gpd5x board.

Closing this as invalid.