Search Issue Tracker

Fixed

Fixed in 1.9.0

Votes

0

Found in [Package]

1.8.0-pre.2

Issue ID

ISXB-746

Regression

No

Once a Composite is triggered, the modifier button loses its pressed state without actually letting go of the key itself when using a multi-monitor display setup

Package: Input System

-

Reproduction steps:
1. Open the attached “IN-66148_ScreenControlBug.zip“ project
2. Open the “TestScreenControlScene” from the Project window > Assets > Agt.Gdk.Unity.Module > ScreenControl > Tests > Scenes
3. Press the “Add Open Scenes” button in the Build Settings window (File > Build Settings…)
4. Make sure the “Target Platform” is set to “Windows”
5. Press the “Build And Run” button and select the folder for the Player to be built in
6. Once the Player launches, press the f1 key while holding a shift key (keep holding the shift key for the next 2 steps)
7. Observe that the “Primary Screen” GameObject has been moved to the second monitor
8. Press the f1 key again while still holding the shift key from step 6

Expected result: The “Primary Screen” GameObject gets moved to the next available display
Actual result: The “Primary Screen” GameObject gets disabled

Reproducible with: 1.7.0 (2022.3.18f1), 1.8.0-pre.2 (2022.3.18f1, 2023.2.7f1, 2023.3.0b4)
Could not test with: 1.7.0 (2021.3.34f1) due to Package errors

Reproduced on: Windows 11 Pro (23H2)
Not reproduced on: macOS 14.2 (M1)

Notes:
- At least 2 monitors are required for reproduction
- The shift + F1 key combination has been configured to move the “Primary Screen” to the other display while F1 alone toggles it off and on

 

UPDATE:

From my investigation I discovered this issue isn't specific to Multi-Display.

Instead it's due to a subtle flaw within InputActionState.ProcessControlStateChange(), which incorrectly processes control state changes for Composite Bindings when InputManager.ResetDevice() is called while the Action (containing the Composite Binding) is being executed. In this scenario, switching the Displays trigger OnFocusLost() which thereby calls ResetDevice().

Furthermore, the bug only manifests itself when the 'overrideModifiersNeedToBePressedFirst' flag is set on a Composite Binding. Although the control gets into the bad state during this scenario, it only really becomes a problem when enforcing the "modifier must be pressed first" behavior within ModifierIsPressed().

WORKAROUND:

Open the InputAction Asset Editor window (for the MultiDisplay InputAction asset) and select the Composite Binding, e.g. "ShiftF1". In the Binding Properties tick the box for "Override Modifiers Need to be Pressed First".

This will skip the check for if the Modifier was pressed first and sidestep the bug. The Modifier check seems to be unnecessary for this project anyway, since F1 by itself is bound to a different Action.

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.