RedBearAK
commented
1 month ago @bigplayer-ai
As far as I know there is no fix that can stop Windows from locking the screen when it receives Win+L, and on an Apple keyboard the Command key is the same key code as the Meta/Super/Win key on PC keyboards. So if Jump Desktop is passing through the equivalent of Win+L when you press Cmd+L on the Mac, the Windows machine will always lock the screen. It's not "logging out" but just locking the screen. All of your open apps should be in the same state when you unlock the screen.
Actually there is a "fix" but it involves a registry hack that completely disables the ability of the Windows machine to ever lock the screen. So you'd have to be OK with never being able to lock the screen again (unless you reversed the registry hack). You can search the web for how to do that, if you really want to. I don't recommend it.
When you're on the Windows keyboard and press the virtualized equivalent of Cmd+L, you're actually pressing the physical Alt+L keys, so you don't trigger the screen locking. But you should find that if you use the virtualized equivalent of Option+L on the physical Win+L keys of the PC keyboard, the screen will still lock despite your attempt to fix the issue in the kinto.ahk file:
#IfWinNotActive ahk_group remotes
; Remap Command (Win) + L to Control + L
#l::Send ^l
; wordwise supportWindows intercepts that specific shortcut at a lower level, and AutoHotkey can't stop Windows from seeing it. I believe I tried something similar when I was implementing the Option-key special character logic, and it didn't work. It's almost like a BIOS hardware function key, deeply embedded in the Windows kernel. For security reasons, no doubt.
The only thing that remap should be capable of doing is changing the Win+L that comes from the modmapped physical Ctrl+L keys back into being Ctrl+L, but Windows only cares about the original physical Win+L keys for this screen locking function. So I don't think it's really accomplishing anything.
That's my understanding of the matter, but I haven't looked into it in a couple of years. I may be misremembering something, or something may have changed (unlikely).
I would advise assigning an alternate shortcut to get to the location bar, and just learning to avoid using Cmd+L for that on the Mac side of the connection.
bigplayer-ai
Describe the bug When using Kinto on Windows 11 machine, Remote control from macOS to control a Windows 11 machine via Jump Desktop RDP, pressing Command + L logs me out of Windows instead of performing the expected action of focusing the address bar/go to location (similar to Ctrl + L in Windows). This behavior occurs in applications like File Explorer and Microsoft Edge.
Expected behavior Pressing Command + L should remap to the Windows equivalent of Ctrl + L, which focuses the address bar in browsers or File Explorer, instead of triggering a log-out.
OS: macOS (local) connecting to Windows 11 Pro N (remote)
Branch: master
Logs and status if relevant
N/A – occurs in a remote and local desktop scenario (both)
Screenshots
This is a keyboard shortcut-related issue:
Additional context
The issue happens specifically when using Jump Desktop RDP from macOS to a Windows 11 machine with Kinto running and Jump Desktop's key conversion disabled. The Command + L shortcut incorrectly logs out the session instead of focusing the address bar on windows 11 machine
This bug is still relevant only when using Jump Desktop from macOS connecting to Windows... How can I fix this issue, you got any idea? using Apple keyboard
On local windows machine without any remote or anything the workaround I mentioned worked correctly... using Windows Keyboard.
https://github.com/microsoft/PowerToys/issues/3908