Improve caps lock toggle

[mboegem]

Included keydown event in order to handle caps lock key event in some browsers (both ON and OFF, instead of only OFF or not at all) > see: https://stackoverflow.com/questions/39016292/keydown-event-is-not-fired-for-capslock-in-mac

[jcompagner]

Why do you need this? We already have support for the capslock as a modifier for all the key presses (so you can warn then when they type something and the capslock is on, most of the time that is the problem, that it is already on, not that they pressed capslock exactly when in that field (then very likely it is meant this way)

[mboegem]

Currently when you toggle capslock, behaviour is not consistent; not cross-browser, but also not even within 1 browser as is explained in the stackoverflow link I included. So building a multi platform, multi browser solution, I can not have the user experience the same behaviour in the current implementation that handles only key up events (unless I will ignore the caps lock key event at all and only handle other key events)

Mac Chrome/Safari:

• turn caps lock on > nothing happens
• start typing in the field > callback is triggered
• turn caps lock off > callback is triggered

Mac FireFox:

• turn caps lock on > nothing happens
• start typing in the field > callback is triggered
• turn caps lock off > nothing happens

Windows (10) IE/Edge/Chrome/FireFox:

• turn caps lock on > callback is triggered
• start typing in the field > callback is triggered
• turn caps lock off > callback is triggered

[jcompagner]

But just catching the caplock or kind of any modifier key is not the idea shift,ctrl,meta,capslock are modifiers. So they are always there with another key Its not really meant to only look for those keys . Why do you need this? What is the real use scenario?

Normally you would just catch "D" and see that the shift or capslock was the modifier, then you can warn the user that capslock is on.. When are you really going to test that the key itself was capslock or shift or control?

[mboegem]

Normally you would just catch "D" and see that the shift or capslock was the modifier, then you can warn the user that capslock is on..

Correct, but I experienced that Windows is doing that different (already by default) and there is different behaviour on Mac when comparing browsers. This code change will make it the same across platform and browsers.

The real use case is that you can warn the user right away when pressing caps lock (by accident). And since this is already the case on Windows, I guess it's not such a strange idea.

[jcompagner]

problem is that many times the capslock is already pressed when entering the field NOW I TYPE THIS and pressed capslock on purpose.. thats mostly the idea if you are already in a field and THEN press capslock it is very likely that that is exactly what you want.. The problem is more that you enter a field and capslock is already on. And that is only detected when checking it as a modifier.. Thats something you need to do. You should not check on the capslock key your self.

[mboegem]

This code change won’t change anything to what you already described, other than have caps ON triggering the callback, following behavior that is already there on all Windows browsers and partly on Mac browsers. This change will make all Mac browsers respond in a similar way

If you’re saying the behavior should not include caps lock than current behavior is wrong and inconsistent.

Did you actually try and see what happens if you want to include a caps lock warning on let say a password field? And in different browsers? You must agree that it does look odd in some situations.

[jcompagner]

yes thats why we build the capslock modifer support! Different browser shouldn't matter you will always get the right modifier:

function onkeypresscallback(input, jsEvent, keyCode, altKey, ctrlKey, shiftKey, capsLockEnabled) { if (capsLockEnabled) { // warn user } }

that should work on any browser that supports: getModifierState() on event (which i think is pretty much every browser even including IE)

If you want to test something like that, so give a warning you should NOT do:

function onkeypresscallback(input, jsEvent, keyCode, altKey, ctrlKey, shiftKey, capsLockEnabled) { if (input == capslock) { // warn user } }

that doesn't make any sense, then you only warn the user when it really did press capslock when really in that field, and as i said before that is then very likely not by accident but on purpose. The trick is way more to detect a capslock when it was already in the ON state long before the user entered the field and started typing something into it.

I am not perse against this pull request, but i do think the reason is just bogus.

[jcompagner]

hmm come to think of it why would you directly know the capslock is pressed or not? that key event? because what does that mean? is it set to an on or off state?

Maybe the key event sends a capslock and then the modifier says what state it is in? Or is the modifier only set after the key event when it is really pressed? (the key event is done?)

So i still don't see what the use case is to really have the capslock as the key event itself We could also argue that sending any of the modifier keys to the server is not directly usefull.. So we could just filter out also the ctrl and shift ... So they are really only send as modifier of an other "normal" key.

[jcompagner]

So this is purely about that you get an event for the capslock, not that you really want to do anything for keyCode 20 So that when you press capslock when in the field the warning that you can have is displayed or made invisible right away over all browsers..

[mboegem]

Correct, thanks for merging!