starred/1Remote

Fork 0

mirror of https://github.com/1Remote/1Remote.git synced 2026-04-25 13:36:03 +03:00

[GH-ISSUE #1052] Client desktop operation steals the focus of the RDP #3746

New issue

Closed

opened 2026-03-13 12:51:45 +03:00 by kerem · 5 comments

kerem commented

2026-03-13 12:51:45 +03:00

Owner

Originally created by @itagagaki on GitHub (Jan 5, 2026).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/1052

Originally assigned to: @VShawn on GitHub.

Describe the bug
The following steps reproduce the issue.

To Reproduce

Connect to an RDP host. The window opened at this time has focus, and keystrokes are directed to the remote.
Click on another local client window to activate/focus it.
Click the tab of the RDP host. The focus will not return to the RDP.

Expected behavior
The RDP window must be in focus again.

Desktop (please complete the following information):

Windows 11 Pro 25H2
1Remote 1.2.1

Additional context
Once you have clicked on the RDP window, the above steps will always produce the expected behavior.

Originally created by @itagagaki on GitHub (Jan 5, 2026). Original GitHub issue: https://github.com/1Remote/1Remote/issues/1052 Originally assigned to: @VShawn on GitHub. **Describe the bug** The following steps reproduce the issue. **To Reproduce** 1. Connect to an RDP host. The window opened at this time has focus, and keystrokes are directed to the remote. 2. Click on another local client window to activate/focus it. 3. Click the tab of the RDP host. The focus will not return to the RDP. **Expected behavior** The RDP window must be in focus again. **Desktop (please complete the following information):** - Windows 11 Pro 25H2 - 1Remote 1.2.1 **Additional context** Once you have clicked on the RDP window, the above steps will always produce the expected behavior.

kerem

2026-03-13 12:51:45 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-13 12:52:01 +03:00

Author

Owner

@VShawn commented on GitHub (Jan 5, 2026):

I can't reproduce the bug, is it because I did it incorrectly?

https://github.com/user-attachments/assets/658bcc9e-d81e-4e10-a81b-3ea18dd7a294

BTW I made test on:

@VShawn commented on GitHub (Jan 5, 2026): I can't reproduce the bug, is it because I did it incorrectly? https://github.com/user-attachments/assets/658bcc9e-d81e-4e10-a81b-3ea18dd7a294 BTW I made test on: <img width="217" height="68" alt="Image" src="https://github.com/user-attachments/assets/e3c28f0b-3dd4-4b1e-bb75-9abd92bfd121" />

kerem commented

2026-03-13 12:52:06 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 5, 2026):

Hmm, I wonder if this is due to differences in the environment.
Now, let's see what's happening in my environment.

https://github.com/user-attachments/assets/9d13d775-5382-4a8d-9b7c-84fec812309c

Connect to "aero"
In "aero", the Windows Terminal (running PowerShell) already has the focus. Therefore, when I typed aaaaa, it was entered into PowerShell. You can also see the key events firing in "aero" by watching "keymill" window in the top-left corner of the remote desktop.
Click 1Remote's main window.
Click "aero" tab.
Here I'm typing aaaaa... again, but it's not being entered into the “aero” PowerShell. On the client side, ‘Keymill’ (bottom left) shows that the key event is being fired on the client, not “aero”.
After that, I tried to move the mouse pointer inside the remote host's window and noticed that it was not being drawn within it. You can see that I'm moving the mouse pointer up and down to check. It may be that not only key-input events but also mouse events are not firing.
Even so, clicking the remote restored the mouse pointer display. This also enabled me to use the keyboard.
Click 1Remote's main window again.
And I typed aaaaa again. Naturally, it was entered into a focused control of 1Remote.
Click "aero" tab again.
It's okay now. I could enter keys on the remote side.

Another point in this test is the notification area in the lower-left corner of the client's desktop.

These are the keyboard layout and IME icons.
It disappears in Step 1, returns to normal in Step 3, and remains unchanged in Step 4.
However, after Step 7, as seen in the behavior of Step 10, clicking the RDP host tab will cause them to disappear. This is the expected behavior, just as in Step 1.

@itagagaki commented on GitHub (Jan 5, 2026): Hmm, I wonder if this is due to differences in the environment. Now, let's see what's happening in my environment. https://github.com/user-attachments/assets/9d13d775-5382-4a8d-9b7c-84fec812309c 1. Connect to "aero" 2. In "aero", the Windows Terminal (running PowerShell) already has the focus. Therefore, when I typed aaaaa, it was entered into PowerShell. You can also see the key events firing in "aero" by watching "keymill" window in the top-left corner of the remote desktop. 3. Click 1Remote's main window. 4. Click "aero" tab. 5. Here I'm typing aaaaa... again, but it's not being entered into the “aero” PowerShell. On the client side, ‘Keymill’ (bottom left) shows that the key event is being fired on the client, not “aero”. 6. After that, I tried to move the mouse pointer inside the remote host's window and noticed that it was not being drawn within it. You can see that I'm moving the mouse pointer up and down to check. It may be that not only key-input events but also mouse events are not firing. 7. Even so, clicking the remote restored the mouse pointer display. This also enabled me to use the keyboard. 8. Click 1Remote's main window again. 9. And I typed aaaaa again. Naturally, it was entered into a focused control of 1Remote. 10. Click "aero" tab again. 11. It's okay now. I could enter keys on the remote side. Another point in this test is the notification area in the lower-left corner of the client's desktop. <img width="53" height="29" alt="Image" src="https://github.com/user-attachments/assets/eaf1992e-108b-4d6c-adab-cf9389995433" /> These are the keyboard layout and IME icons. It disappears in Step 1, returns to normal in Step 3, and remains unchanged in Step 4. However, after Step 7, as seen in the behavior of Step 10, clicking the RDP host tab will cause them to disappear. This is the expected behavior, just as in Step 1.

kerem commented

2026-03-13 12:52:12 +03:00

Author

Owner

@michalpavlikpb commented on GitHub (Jan 5, 2026):

Hi, i have simillar problems.
I would like to test new alpha but i cant find link to download (Win) 1.3. Can you provide som link to test please ? Thank you

@michalpavlikpb commented on GitHub (Jan 5, 2026): Hi, i have simillar problems. I would like to test new alpha but i cant find link to download (Win) 1.3. Can you provide som link to test please ? Thank you

kerem commented

2026-03-13 12:52:17 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 6, 2026):

How to get a build under development:

Go to Actions.
Select the "Build/Publish on push" workflow.
Choose whichever successful one you want.
You can get the Artifacts at the bottom of the page.

@itagagaki commented on GitHub (Jan 6, 2026): How to get a build under development: 1. Go to Actions. 2. Select the "Build/Publish on push" workflow. 3. Choose whichever successful one you want. 4. You can get the Artifacts at the bottom of the page.

kerem commented

2026-03-13 12:52:22 +03:00

Author

Owner

@itagagaki commented on GitHub (Jan 7, 2026):

I think the focus of the window should be changed here in the case of this issue.

github.com/1Remote/1Remote@4c31f4efa1/Ui/View/Host/TabWindowView.xaml_timer.cs (L75-L111)

However, I think the problem is that this process is being skipped because the ProtocolHostType for RDP is not set to 'Integrate'.
Furthermore, since AxMsRdpClient09Host.GetHostHWnd() does not return a window handle, it is impossible to focus, activate, bring to the front, or enable it.

github.com/1Remote/1Remote@4c31f4efa1/Ui/View/Host/ProtocolHosts/AxMsRdpClient09Host.xaml.cs (L782-L790)

@itagagaki commented on GitHub (Jan 7, 2026): I think the focus of the window should be changed here in the case of this issue. https://github.com/1Remote/1Remote/blob/4c31f4efa1542e08b93abdd3a610a793753e7cd2/Ui/View/Host/TabWindowView.xaml_timer.cs#L75-L111 However, I think the problem is that this process is being skipped because the `ProtocolHostType` for RDP is not set to '`Integrate`'. Furthermore, since `AxMsRdpClient09Host.GetHostHWnd()` does not return a window handle, it is impossible to focus, activate, bring to the front, or enable it. https://github.com/1Remote/1Remote/blob/4c31f4efa1542e08b93abdd3a610a793753e7cd2/Ui/View/Host/ProtocolHosts/AxMsRdpClient09Host.xaml.cs#L782-L790

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/1Remote#3746

No description provided.

Rows
Columns