Re: Shift key stuck issue while CAPS LOCK on XRDP/RDP (CTRL+c becomes => CTRL+C that in backend becomes =>CTRL + Shift +c)

[steph01]

Hi Nick,
just checking in about the issue below — not sure if you had the chance 
to look into it yet.

I kept digging and found a couple more details that might help:

 *

   It’s not actually sending *Shift*, but rather turning |CTRL + c|
   into |CTRL + C| (uppercase). I assume Guacamole is internally
   converting that into a Shift-modified combo.

 *

   The issue always starts if the RDP session is opened while Caps Lock
   is already ON on the client.

 *

   Toggling Caps Lock /inside/ the RDP session doesn’t fix anything.

 *

   But if I switch to another browser tab, toggle Caps Lock there, and
   then come back to the Guacamole tab, everything magically starts
   working again. So something about the browser tab focus seems to
   force a correct state sync.

Do you have any updates on this or any insight from your side?
Also — before I start experimenting randomly — do you know of any 
possible workaround I could try client-side or server-side to force 
Guacamole to resync the lock-key state on session start?

Thanks,
Steph

Il 18/11/25 12:43, steph01 ha scritto:

Hi Nick,

quick update on my issue.

After more tests, I found out the problem wasn’t specifically related 
to XRDP, but to *any RDP session started while **_Caps Lock_**is 
already enabled on the client machine*.

If I start the RDP session with Caps Lock ON, Guacamole ends up 
sending an extra Shift internally.
As a result:

 *

    |CTRL + C| becomes |CTRL + SHIFT + C|

 *

    |CTRL + S| becomes |CTRL + SHIFT + S|

 *

    and so on…

But if the RDP session is already running and I toggle Caps Lock 
/inside/ the session, then everything works perfectly. So the keyboard 
state only gets out of sync *at session start*.

I found this (old) issue that seems related: 
https://issues.apache.org/jira/browse/GUACAMOLE-518


Seems that guacamole doesn’t synchronize the initial state of lock 
keys (Caps/Num) when the session begins. If Caps Lock is active before 
connecting, the backend assumes it’s off and compensates by injecting 
Shift.


Any ideas for this?


Thanks in advance.

Steph.


Il 10/11/25 17:09, steph01 ha scritto:

Hi Nick,

I’m using *Guacamole 1.5.5*.

About contributing — yes, I’d like to! I’ve submitted a couple of 
small fixes in the past, nothing major yet.
To clarify: I haven’t completely rewritten the frontend — I’m using 
the *Guacamole JavaScript libraries* and integrating them into an 
existing *React* project. Though, by now, I’ve gotten fairly familiar 
with how the client side of Guacamole works.
Unfortunately, I’m not really familiar with the ongoing Angular rewrite.

Thanks for mentioning the Ctrl–Alt–Shift case — in my setup those 
shortcuts aren’t used, so it’s probably something else.

Do you think there could be a workaround for this kind of stuck key 
state?
I was thinking about something like *detaching and reattaching the 
keyboard session programmatically*, since reconnecting the whole 
session seems to reset everything correctly — though that feels a bit 
hacky.

Any ideas or safer approaches you’d suggest?

Thanks again!
— Steph


Il 10/11/25 15:55, Nick Couchman ha scritto:
On Mon, Nov 10, 2025 at 8:37 AM steph01 <m...@steph01.dev> wrote:

    **

    Hi everyone,

    I’m running both *guacamole-server* and *guacamole-client* on my
    own implementation of Guacamole — I’ve rewritten the frontend in
    *React*, following the logic and specs from the original Angular
    code.


What version of Guacamole have you based your React re-write on? 
(Also, have you considered contributing this code to the community? 
There's a rewrite in progress from AngularJS to Angular, but it's 
possible others would be interested in a React version of it...)

    I’m running into a strange issue that seems to happen *only on
    XRDP sessions to Linux machines* (I haven’t seen it on Windows).
    Basically, it looks like the *Shift key stays “stuck”* in the
    backend after some time.

    For example:

     *

        When I press *CTRL+C*, Guacamole sends *CTRL+SHIFT+C*
        instead (in NetBeans, this triggers “comment block” instead
        of copy).

     *

        *CTRL+S* becomes *CTRL+SHIFT+S* (“Save As”).

The only similar thing that I've seen, and I believe is limited to 
xrdp, is that, depending on the sequence in which I press the keys 
to activate the "hidden" Guacamole menu - Ctrl-Alt-Shift or 
Ctrl-Shift-Alt - one of the keys gets stuck. I don't think it's the 
Shift key, I think it's either Ctrl or Alt, but It sounds like it 
could be related to what you're seeing. Other than that, I'm not 
seeing the Shift key get stuck in the way you're reporting.

-Nick