MCL-1483Number in passwords with azerty keaboards under linux are not always recognized
Depending on the way I enter numbers in the password field, the launcher accepts or refuses my password :
Shift + touches above the letters (Shift being required since it's an AZERTY, and Caps Locks under Linux capitalizes characters instead of entering numbers) : works fine.
Num. Locks + pavement : works fine.
Shift + pavement (no num. locks, of course) : refused.
It may sound like a very minor issue, but I only found out how it worked by trying everything out of desperation.
Hope the information was understandable. Thanks for your work 
Environment
Xubuntu 11.10
OpenJDK Java 6 Runtime
Keaboard : PC générique 105 touches (intl) - Disposition : Français (variante)
Created Issue:
Number in passwords with azerty keaboards under linux are not always recognized
Depending on the way I enter numbers in the password field, the launcher accepts or refuses my password :
Maj + touches above the letters (maj being required since it's an AZERTY, and Caps Locks under Linux capitalizes characters instead of entering numbers) : works fine.
Num. Locks + pavement : works fine.
Maj + pavement (no num. locks, of course) : refused.It may sound like a very minor issue, but I only found out how it worked by trying everything out of desperation.
Hope the information was understandable. Thanks for your workEnvironment
Xubuntu 11.10
OpenJDK Java 6 Runtime
Keaboard : PC générique 105 touches (intl) - Disposition : Français (variante)
Depending on the way I enter numbers in the password field, the launcher accepts or refuses my password :
Maj+ touches above the letters (majbeing required since it's an AZERTY, and Caps Locks under Linux capitalizes characters instead of entering numbers) : works fine.
Num. Locks + pavement : works fine.
Maj + pavement (no num. locks, of course) : refused.It may sound like a very minor issue, but I only found out how it worked by trying everything out of desperation.
Hope the information was understandable. Thanks for your workDepending on the way I enter numbers in the password field, the launcher accepts or refuses my password :
Shift + touches above the letters (Shift being required since it's an AZERTY, and Caps Locks under Linux capitalizes characters instead of entering numbers) : works fine.
Num. Locks + pavement : works fine.
Maj + pavement (no num. locks, of course) : refused.It may sound like a very minor issue, but I only found out how it worked by trying everything out of desperation.
Hope the information was understandable. Thanks for your work
Depending on the way I enter numbers in the password field, the launcher accepts or refuses my password :
Shift + touches above the letters (Shift being required since it's an AZERTY, and Caps Locks under Linux capitalizes characters instead of entering numbers) : works fine.
Num. Locks + pavement : works fine.
Maj+ pavement (no num. locks, of course) : refused.It may sound like a very minor issue, but I only found out how it worked by trying everything out of desperation.
Hope the information was understandable. Thanks for your workDepending on the way I enter numbers in the password field, the launcher accepts or refuses my password :
Shift + touches above the letters (Shift being required since it's an AZERTY, and Caps Locks under Linux capitalizes characters instead of entering numbers) : works fine.
Num. Locks + pavement : works fine.
Shift + pavement (no num. locks, of course) : refused.It may sound like a very minor issue, but I only found out how it worked by trying everything out of desperation.
Hope the information was understandable. Thanks for your work
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
What is "pavement" ?
He means the numeric keypad – in French, this is referred to as "Pavé numérique". "Pavé" is literally "Pavement".
On the AZERTY layout, the function of the number keys above the keyboard are swapped – they produce symbols when pushed alone, and require holding shift for them to produce numbers.
I'm not sure what the standard behavior of the keypad is on an AZERTY layout, but the reporter is claiming that it's a problem that it's not producing numbers when the num lock is off, but they are holding the shift key. That's correct behavior for a QWERTY layout, and may be the same for AZERTY as well, making this report invalid. However, someone knowledgeable on the AZERTY layout would have to verify that (or someone could test it in some other application to see what the normal behavior is).
Sorry about the little translation mistake.
So yeah, the launcher doesn't produce numbers when I use shift + keypad. However, I'm pretty sure it should : I always type my numbers this way, and all the program I usually use - be it firefox, LibreOffice, dekstop environments, consoles (even tty1, tty2 and so on) - recognize those inputs as numbers.
However, I found out that this problem doesn't seem specific to the password widget : the mail/username widget is also concerned, and every widget in the launcher (for instance, "Add Profile" in the profile editor,...) Generally speaking, the keypad, be it used with the shift key or the num. lock, is useless when playing minecraft, so I guess Mojang people are not really into these kind of details : a game isn't supposed to be playes on a lame laptop without a mouse
For the sake of a more accurate report, I checked it with another layout, "Anglais (USA)" (Anglais means English) according to my Xubuntu (it's an entry that allows me to play minecraft using numbers above the keyboard. I set it through the Parameters Manager GUI in the main menu). My problem doesn't seem to come from the layout either, actually.
Moreover, not all numbers are affected in the same way (determined by testing other widgets) :
Is that a normal behaviour for a qwerty layout ? Because my "Anglais (USA)" layout, which doesn't produce numbers with the launcher, does produce numbers in firefox (for instance).
Does not happen with a (German) QWERTZ layout.
if NumLock is locked, the unshifted keys on the number pad give the numbers and if shifted the cursor keys.
No, NumLock is not locked (which is why I press shift). But when I lock NumLock, press shift and use the keypad, I do get the same results you do (shifted cursos keys).
So it is definitely not a layout problem : I tried using several german layouts (all QWERTZ), I got the same strange behaviour. I guess it may come from the OS (unless you tried it under Xubuntu) or from the hardware (still, it would be pretty impressive if all programs I use were not to be affected by such a peculiarity, except minecraft launcher). If that's the case, I guess we can't do much about it.
Since no one was able to reproduce the bug, anyway, it doesn't seem like anything worth fixing...
On a US QWERTY layout, for comparison:
Numlock off: keypad produces cursor keys (8, 4, 6, 2), home (7), end (1), Page Up (9), Page Down (3), Insert (0), all of which are all marked on the keyboard.
Numlock on: numbers
Numlock on, shifted: same as numlock off, unshifted.
Numlock off, shifted: behaves like the standalone cursor and home, end, etc. keys – moves the cursor, but also highlights text.
The last one probably is the reason for the experienced issue. Is there a way to highlight text using the keyboard with an AZERTY layout? Is it the same, holding shift and using the cursor keys, or is it a different modifier?
What you're seeing with the Anglais layout appears to be it trying to produce both functions at the same time: shift+4 results in it highlighting the previous character, then replacing it with a '4', shift+7 highlights all previous characters (home function) and replaces them with a '7', and shift+0 is pasting because shift+insert is paste. This is probably a problem in LWJGL, with it not properly understanding other keyboard layouts. There have been a number of other complaints on the tracker here about similar issues.
Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.8 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
Sorry, this would be an issue in java/swing and out of our control. We don't have access to low level information like this.