Search Issue Tracker
Won't Fix
Votes
1
Found in
2017.4
2018.4
2019.2
2019.2.13f1
2019.3
2020.1
Issue ID
1204882
Regression
No
Input.GetKey for Left Shift returns true when Right Shift is held down and Left Shift is pressed (and vice versa)
Steps to reproduce:
1. Open the attached project (case_1204882_ShiftInput.zip)
2. Enter Play mode
3. Press and hold down Right Shift and observe the output in the Console
4. Press Left Shift once and observe that GetKey is continuously triggered for Left Shift and no GetKeyUp event was logged to the Console
5. Release Right Shift
Expected result: GetKey() and GetKeyUp() are only triggered for the corresponding key
Actual result: GetKey() for the Shift key that was pressed once returns true while the other key is held down and GetKeyUp() events are fired at the same time as the held key is released
Reproduced in: 2017.4.35f1, 2018.4.14f1, 2019.2.16f1, 2019.3.0f3, 2020.1.0a16
Note: this seems to happen ONLY with Shift and no other modifier keys
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- A submenu disappears on MacOS when the MenuItem method argument "isVariableFunction" is set to "false" and priority argument is set to "-1"
- The Sprite Library Editor window has an incorrect order of Sprites when the Sprites are reordered and the order saved
- Tilemap Tiles do not get lit up unless the Light Range is greater than the distance between the position of the Tile before the transformation and the Light Source when the Tile is transformed with Tilemap.SetTransformMatrix method
- The Editor and "Reloading Domain" windows are frozen when entering Play Mode
- Crash when attempting to create a custom FMOD DSP unit
Resolution Note (2021.1.X):
This is an issue with Win32 that's been around forever.
Win32 keyboard messages (WM_KEYDOWN, WM_KEYUP, etc.) treat Left and Right Shift as the *same key* and don't dispatch WM_KEY* events when one of them is held down. That is, holding down left Shift and pressing right shift doesn't trigger WM_KEY* events because Windows doesn't recognize this as a state change. Unfortunately, Unity's classic input system is based on the Win32 Key messages and so inherits this behavior.
This issue has been fixed with the "new" Input System; https://docs.unity3d.com/Manual/com.unity.inputsystem.html, however it won't be fixed with the legacy Input APIs; it requires substantial changes to re-work input handling.
It's strongly recommended to use the new Input System instead of the legacy Input Manager.