Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapped Shortcuts Do Not Match Keys Pressed #2176

Closed
connah0047 opened this issue May 17, 2019 · 10 comments

Comments

Projects
None yet
3 participants
@connah0047
Copy link

commented May 17, 2019

  • Version: May 9, 2019
  • Windows 7 Professional, SP1, x64
  • When customizing shortcuts, some keys pressed do not correspond to the keys mapped

Steps to Reproduce:

  1. Start x32dbg
  2. Click on Options -> Shortcuts
  3. Scroll down to the instruction "Debug -> Step Into" and click once on it
  4. Click the "Clear" button to clear the default shortcut of "F7"
  5. Click in the "Shortcut" box and press the "F7" key on the keyboard in an attempt to set the shortcut back to "F7"
  6. Observe that "Shift+F6" appears in both the "Shortcut" box and under the "Shortcut" column instead of the expected "F7". There is no readily apparent way to reset it back to default values or to configure "F7" for use as a shortcut now. "F7" is not the only problem key as shown immediately below.

Other keys that reproduce this problem and the errant shortcuts they map to:
F3 maps as Shift+F2
F4 maps as Shift+F2
F8 maps as Shift+F6
F11 maps as Shift+F10
F12 maps as Shift+F10
Scroll Lock maps as Shift+NumLock
Insert maps as Shift+Enter
Page Up maps as Shift+Down
Page Down maps as Shift+Down
Delete maps as Shift+Enter
Up Arrow maps as Shift+End
Left Arrow maps as Shift+End

In an attempt to resolve this issue myself, I have tried:

  1. Searching the bug tracker for similar issues
  2. Clearing ALL existing shortcuts before trying to map a problem shortcut
  3. Downloading and running a freshly installed copy without making any changes or customizations apart from trying to map a shortcut key

PLEASE NOTE: This is my first bug report and I have done my very best to make sure it adheres to specifications and that there was not a pre-existing bug describing my problem. If I have overlooked something, please forgive me and point me in the right direction. Thank you!

@kdma

This comment has been minimized.

Copy link
Contributor

commented May 18, 2019

I am no mantainer but looks like this is the problem

if((keyInt & Qt::Key_Backtab) == Qt::Key_Backtab)
keyInt = (keyInt & ~Qt::Key_Backtab) | Qt::SHIFT | Qt::Key_Tab;

For example with F7

Qt::Key_Backtab | 0x01000002
Qt::Key_F7 |      0x01000036

Since F7 "contains" Backtab (which I never heard of) it replaces that part with shift tab and it goes haywire. I am not sure what is the rationale for that substitution.

@connah0047

This comment has been minimized.

Copy link
Author

commented May 18, 2019

I have a feeling I'm about to ask a really dumb question, but what is a "Backtab"? I've never heard of that before. Moreover, I don't see anything in the ShortcutEdit.cpp code that would allow F5 and F6 to work, but not F4 or F7, for example. I keep having this sneaking suspicion that I'm doing something wrong because this seems way too obvious of a bug for it to have been around all this time and me just happen to be the first person to find and report it.

Are you able to reproduce this problem on your end? I'd just like to know if others are having this trouble too. Thanks again for your time!

@kdma

This comment has been minimized.

Copy link
Contributor

commented May 18, 2019

About the backtab no idea, I never heard of it and yes the problem is reproducible.
Regarding the keys that reproduce the bug just look the keycode for the keys here:
https://doc.qt.io/qt-5/qt.html#Key-enum
Calculate the bitwise AND like in the previous code snippet and see that for those key that start with 0x1 and end with 0b1X the result will be always the keycode for the Backtab and that means that the if body gets evaluated.

@connah0047

This comment has been minimized.

Copy link
Author

commented May 18, 2019

Perfect, thank you! I had missed that initially! I think you absolutely found the bug. Hopefully the developers will have a look into this soon. Seems like it would be an easy fix. (Says me, the keyboard warrior.) :)

@kdma

This comment has been minimized.

Copy link
Contributor

commented May 18, 2019

Just wait for any of the maintainers to chime in about the rationale of the backtab substitution and make your first pull request :).

@mrexodia

This comment has been minimized.

Copy link
Member

commented May 18, 2019

@mrexodia

This comment has been minimized.

Copy link
Member

commented Jun 15, 2019

Was this actually fixed?

kdma added a commit to kdma/x64dbg that referenced this issue Jun 15, 2019

mrexodia added a commit that referenced this issue Jun 16, 2019

@connah0047

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

@mrexodia

This comment has been minimized.

Copy link
Member

commented Jun 17, 2019

It's been fixed in #2189, thanks to @kdma!

@connah0047

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

@mrexodia mrexodia closed this Jun 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.