Bug 400 implemented synchronisation of CapsLock and NumLock (and ScrollLock) in the native client and in the server. However it did not do any changes to Web Access. The problem is that the browsers do not expose any way of controlling the local lock state. They also do not expose the current state when needed, so we cannot implement the client-to-server sync the same way as the native viewer. As such, we are currently relying on the fallback behaviour in the server, which gives a synchronised state even without the client's help in most cases. The most notable case where it doesn't work is when the state is changed on the server but not the client (e.g. a "Toggle CapsLock" function in an application). However it will soon sync back to the clients state when it detects a mismatch. If the APIs improve then we might be able to fix this, but for now this will have to be a tracking entry.
Tested the following after the vendor drop of noVNC (bug 8484): We used xev to see keyboard events. 4.17.0: 1. Press caps lock inside session 2. Unfocus the browser 3. Press caps lock again 4. Focus the session 5. Press 'ö' 6. Caps is now out of sync, observed that "Shift_L" was used to capitalize. Pressing 'a' now sent a Caps_Lock press/release, and we are back in sync. 4.18.0post: 1. Press caps lock inside session 2. Unfocus the browser 3. Press caps lock again 4. Focus the session 5. Press 'ö' (or any key) 6. We get a Caps_Lock press/release, and we are back in sync.
With the noVNC vendor drop, this bug is one step closer to being solved. We need to decide there are more things we can/should do, or if we should settle with the current state and close this bug?
Assigning to '---' for discussion.
We decided not to close this bug, as the issue that a remote session can't control a local Caps/NumLock persists.
I created bug 8498 for the inconsistent lock sync in web access, which has now been fixed after the noVNC vendor drop.
