Keyboard shortcuts are forced to QWERTY in password fields

[triallax]

Describe the bug
Keyboard shortcuts seem to be forced to QWERTY in password fields, regardless of the actual keyboard layout used (Workman in my case).

Steps To Reproduce

1. Switch to an alternative keyboard layout (e.g. Dvorak or Workman)
2. Copy anything at all to your clipboard
3. Open BOINC Manager
4. Open the Tools menu item, then press on "Add project..."
5. Choose any project, then press on "Next >"
6. In the password field, press Command+V according to the alternative layout; it won't work
7. Press Command+V with the QWERTY location of V; the text in the clipboard will get pasted

The correct behavior is displayed in the email address field.

Expected behavior
The shortcuts should work according to the currently selected keyboard layout, not QWERTY.

System Information

• OS: macOS 12.6
• BOINC Version: 7.20.2

[CharlieFenton]

The code uses wxTextCtrl fields with the wxTE_PASSWORD style flag set. On the Mac, wxWidgets uses Apple's Cocoa class NSSecureTextField for wxTextCtrl fields with the wxTE_PASSWORD style flag set.

Since BOINC is using the MacOS native control for the password entry, I don't see how the keyboard layout could cause a problem, provided the keyboard layout has been properly selected in the MacOS keyboard system references.

Also, if the keyboard layout caused the password entry to fail, then it would not work for many foreign language keyboards, and we have had no such reports.

[CharlieFenton]

@mhmdanas: I misunderstood your meaning. I thought you meant that the wrong text was pasted into the field. After trying it, I see that command-V does nothing at all with the different keyboard layout. However, if you press the command key and the key which would be V on a standard US keyboard (K on Dvorak), it does paste the text.

@RichardHaselgrove: can you test this on an MS Windows computer to see if it has the same problem?

[RichardHaselgrove]

Will do. Does anyone have any suggestions for a keyboard layout that might re-direct or replace Ctrl-V?

BTW, we have had consistent reports in Windows that the password field can't be filled in when attaching to a project, when the keyboard type is selected for a language that uses the Microsoft Pinyin keyboard handler. Could that be related?

[AenBleidd]

BTW, we have had consistent reports in Windows that the password field can't be filled in when attaching to a project, when the keyboard type is selected for a language that uses the Microsoft Pinyin keyboard handler. Could that be related?

Theoretically - yes.
But this is mostly an issue on wxWidgets side. Could be that this case on OSX is somehow related to wxWidgets issue as well.
I don't think we do smth special with shortcuts that could break general behavior on our side only.

[RichardHaselgrove]

OK, found a way to test at last. None of the Windows 10 tutorials matched my version, so I dropped back to Windows 7 and installed a Dvorak keyboard.

Testing with a BOINC v7.20.2 Manager dated 18 Jul 2022, I can confirm:

Pasting a password in the 'attach to project' dialog works if and only if you use the shortcuts for the current keyboard - Ctrl-V for Querty, Ctrl-> (on Querty hardware) for Dvorak. This is dynamic: you can change the current language while the page is open, and the shortcut setting changes too.

That seems to be the opposite of the reported Mac behaviour.

I'll try an Windows 11 machine, if I can find its keyboard installer.

[RichardHaselgrove]

Windows 11 is the same - shortcut matches selected language. Ctrl-V for Querty, Ctrl-> (on Querty hardware) for Dvorak layout.

[CharlieFenton]

Could be that this case on OSX is somehow related to wxWidgets issue as well.

Yes. I believe it is definitely a problem in the wxWidgets implementation for MacOS. I tested with the Select computer dialog, which specifically sets command-V as a keyboard shortcut (wxWidgets accelerator), and it still fails. I don't see any way for us to fix this on the BOINC side, but we could submit a bug report to wxWidgets.

[CharlieFenton]

I found the problem in wxWidgets. For "secure" text fields (used for password entry to echo dots rather than the password characters), lines 269-278 of wxWidgets/src/osx/cocoa/textctrl.mm has:

                // We are called with this strange "noop:" selector when an
                // attempt to paste the text into a password text control using
                // Cmd+V is made. Check if we're really in this case and, if
                // we're, do paste as otherwise nothing happens by default
                // which is annoying, it is pretty common and useful to paste
                // passwords, e.g. from a password manager.
                NSEvent* cevent = [[NSApplication sharedApplication] currentEvent];
                if ( [cevent type] == NSKeyDown &&
                        [cevent keyCode] == 9 /* V */ &&
                            ([cevent modifierFlags] & NSCommandKeyMask) == NSCommandKeyMask )
                {

The keycode indicates the position of the key on the keyboard, rather than the character it represents for the current keyboard layout. I suspect they did it this way to accommodate languages that use non-Roman character sets, since you can't test for the 'V' character in Cyrillic, Chinese, etc. My quick review indicates that all standard / conventional keyboard layouts for languages with Roman characters have the 'V' in the same place, except Turkish. Of the various keyboard layouts for English, only the Dvorak layout has the 'V' in a different place.

So I don't see any easy way they could fix this for the Dvorak keyboard without breaking it for many other languages.

[triallax]

Of the various keyboard layouts for English, only the Dvorak layout has the 'V' in a different place.

Workman does too; its V is in the same place as QWERTY B.

[CharlieFenton]

@mhmdanas I was only looking at the keyboard layouts offered by the Keyboard System Preferences on a standard MacOS 12.6 (Monterey) installation. Regardless, while I sympathize with your problem, I unfortunately see no way for BOINC to fix this without breaking our support for many times more users than the ones for whom it would help.

[CharlieFenton]

@mhmdanas I found a workaround for you, though this does not directly fix the keyboard issue. If you control-click (not command-click) on the password field you will get a contextual menu which allows you to paste into it from the clipboard. I confirmed that this works on Dvorak and I expect it will work regardless of keyboard layout.

[triallax]

I was only looking at the keyboard layouts offered by the Keyboard System Preferences on a standard MacOS 12.6 (Monterey) installation.

Makes sense.

Regardless, while I sympathize with your problem, I unfortunately see no way for BOINC to fix this without breaking our support for many times more users than the ones for whom it would help.

I don't care much frankly; it's not like I add a new project that often. While I would of course like to see this issue fixed while not breaking support for other Latin keyboard layouts, it doesn't bother me much personally.

I found a workaround for you, though this does not directly fix the keyboard issue. If you control-click (not command-click) on the password field you will get a contextual menu which allows you to paste into it from the clipboard. I confirmed that this works on Dvorak and I expect it will work regardless of keyboard layout.

Yeah, I figured that out myself too. Note that control-click on macOS is equivalent to right-click, so right-clicking on the password field will also show the contextual menu.

[AenBleidd]

Since it's not smth that could be easily fixed on our side (to be completely honest, I don't think it should be fixed on our side at all), I'm converting this issue to Discussion to help other people who might have this issue as well.