[Donion] [2.1.7] Ctrl/Command + A to select all no longer works on AZERTY keyboard.

[francekenji]

MacOS 12.7.6, on an AZERTY keyboard.
Command + A worked fine in 2.0.
This bug doesn't apply to QWERTY keyboard. I haven't tried on windows.

1.What did you do?
Opened a text field like the chat or focus search and pressed Command + A.

2.What happened?
Nothing.

3.What did you expect to happen instead? It might be obvious to you, but do it anyway!
Select all the text in the text field.

4.Does it happen always, once, or sometimes?
Always when on AZERTY.

[francekenji]

I've also found out that you can't type numbers on a number only text field on AZERTY keyboards.
I'm using a virtual keyboard on the attached video so it's easier to see.

[Wig0]

I'm having the same Ctrl+A problem on Windows, version 2.1.8. It was ok in 2.0.77.
Note that Ctrl + Q works fine.

Seems ok for the numbers tho, I can type "Shift + &" to press 1.

[francekenji]

Thank you for testing on Windows.

Seems ok for the numbers tho, I can type "Shift + &" to press 1.

Did you try in a number only text field ? For me, "Shift + &" works in chat but doesn't work in the "Time" mode of the editor, where only numbers are allowed.

[Wig0]

Thank you for testing on Windows.

Seems ok for the numbers tho, I can type "Shift + &" to press 1.

Did you try in a number only text field ? For me, "Shift + &" works in chat but doesn't work in the "Time" mode of the editor, where only numbers are allowed.

Oh you're right. I tested it on a constant combinator text field, and it was fine. It doesn't work in the "Time" mode of the editor, just like your video.

[Zulbukh]

Hello,

I'm facing the same issue on Windows, on 2.1.9, AZERTY keyboard, and I can't write numbers into the Grid Size/Grid Position number fields of the blueprint editor.
Also switching to QWERTY with alt shift doesn't change anything.

Also for some reason "6" is the only number that works (shift+- on azerty)

It behaves as if the text field is just not focused, I use a numpad-less keyboard so if I use Shift-& (which is 1 on azerty) it switches to quickbar 1, if I use capslock then & (once again =1) it selects the item in the 1 slot of the quickbar.

[L0laapk3]

I can confirm that the current behavior is bugged on windows.

I use a custom keyboard layout which uses DVORAK characters and AZERTY virtual keys.

To clarify on the different layers of abstractions windows provides:
* scan codes describes the physical location of keys, and should be used for things where the physical location matters such as WASD controls.
* characters (Microsoft calls these unicode codepoints) should be used for text (words) input into text fields.
* virtual keys exist for legacy reasons and should be used for any shortcuts, such as ctrl + A. ctrl + C, etc. This exists for historical reasons, users of other keyboard layouts are used to some shortcuts being on the location of character their native keyboard layout, while others are not.

My understanding of what has gone wrong with the 2.1 update is that factorio has switched away from the correct behavior of using virtual keys and to character codes for a certain class of inputs.

For AZERTY users, this just moves ctrl + A, but you can imagine the mayham this causes for a DVORAK user like me. To give an example, now ctrl C and ctrl V are all over the place.


The irony here is that in 2018, this was actually fixed and factorio started using the correct input method (fff #259). But it looks like here we are, regressing back to the wrong input method for a subset of the controls.

[Rseding91]

We updated to SDL3 and likely it is the cause of these issues. The input handling code has remain unchanged since that Friday facts talked about it.

[Rseding91]

I spent some time today and dug into this and figured out that it was *kind of* SDL3, but also a self inflicted issue. Code was changed by us as a result of updating to SDL3 and the change was incorrect. This is now fixed for the next release.

[Zulbukh]

thanks mr. developer ur the best