Inconsistent info reported in InputEventKey

[krdluzni]

Tested versions

• Reproducible in: v4.2.2.stable.official [15073af], v4.3.dev6.official [89850d5]

System information

Godot v4.3.dev6 - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4090 (NVIDIA; 31.0.15.5123) - AMD Ryzen 9 7950X 16-Core Processor (32 Threads)

Issue description

When receiving an InputEventKey pressed for a modifier key input (eg. CTRL), the event responds to is_pressed() with true, but the member variable ctrl_pressed will contain false. This creates a situation where the data reported is inconsistent with itself.

I would expect a key event for a modifier being pressed to have that data consistent across the whole event (ie. ctrl_pressed should also report true, as should is_command_or_control_pressed()).

This issue applies to all modifier keys, CTRL is just being used as an example.

Steps to reproduce

1. Load the MRP and run the game.
2. Press control, and see that the log says key_event.is_pressed() is true while the value of key_event.ctrl_pressed remains false.

Optionally, also play with pressing and holding Shift either before or after starting to hold CTRL, and see that the result in key_event.ctrl_pressed is reported differently depending on which key was pressed first.

Minimal reproduction project (MRP)

ctrl_pressed.zip

[AThousandShips]

I'd say this is a matter of definition, I'd say a modifier key is only a modifier when it modifies another key, not when it's alone

This is by design, but that doesn't mean it's fixed, but this isn't due to an oversight but by choice, see for example:

godot/platform/windows/display_server_windows.cpp

Lines 4702 to 4706 in 7ebc866

	// Make sure we don't include modifiers for the modifier key itself.
	KeyEvent ke;
	ke.shift = (wParam != VK_SHIFT) ? shift_mem : false;
	ke.alt = (!(wParam == VK_MENU && (uMsg == WM_KEYDOWN || uMsg == WM_SYSKEYDOWN))) ? alt_mem : false;
	ke.control = (wParam != VK_CONTROL) ? control_mem : false;

This should however at minimum be documented more clearly

Edit: while I haven't confirmed it myself looking at some comments online this seems to be the same behaviour as in Qt, and possibly other interfaces

[krdluzni]

I can understand this argument, and if it's done intentionally and desired, I won't press the issue. It merely surprised me enough to merit a report.
I agree adjusting the documentation would help reduce the surprise.