starred/1Remote

Fork 0

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

[GH-ISSUE #1067] Re-examining solutions to RDP focus issues #839

New issue

Open

opened 2026-02-26 12:00:02 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 12:00:02 +03:00

Owner

Originally created by @itagagaki on GitHub (Feb 7, 2026).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/1067

Originally assigned to: @VShawn on GitHub.

Issue #1052 was resolved by #1057.
However, it caused a new issue #1066.
Furthermore, #1057 did not fully resolve #1052.

A more detailed description of how to reproduce issue #1052 can be found below.

Connect to an RDP host. The window opened at this time has focus, and keystrokes are directed to the remote.
Open Notepad or Terminal, or a similar application that accepts keyboard input on the remote desktop.
Forcus on that application.
Close the RDP session.
Reopen the RDP host. The window will open with focus and any keystrokes will be directed to the application on the remote desktop. Try typing something on the keyboard.
Click on another LOCAL client window to activate/focus it.
Try moving the mouse pointer inside the RDP host window. You will not see the mouse pointer there.
Click the tab of the RDP host. The focus will not return to the RDP.

Step 8 was resolved by #1057, but step 7 was not.

Therefore, we should investigate the root cause more thoroughly and develop countermeasures.

Originally created by @itagagaki on GitHub (Feb 7, 2026). Original GitHub issue: https://github.com/1Remote/1Remote/issues/1067 Originally assigned to: @VShawn on GitHub. Issue #1052 was resolved by #1057. However, it caused a new issue #1066. Furthermore, #1057 did not fully resolve #1052. A more detailed description of how to reproduce issue #1052 can be found below. 1. Connect to an RDP host. The window opened at this time has focus, and keystrokes are directed to the remote. 2. Open Notepad or Terminal, or a similar application that accepts keyboard input on the remote desktop. 3. Forcus on that application. 4. Close the RDP session. 5. Reopen the RDP host. The window will open with focus and any keystrokes will be directed to the application on the remote desktop. Try typing something on the keyboard. 6. Click on another **LOCAL** client window to activate/focus it. 7. Try moving the mouse pointer inside the RDP host window. You will not see the mouse pointer there. 8. Click the tab of the RDP host. The focus will not return to the RDP. Step 8 was resolved by #1057, but step 7 was not. Therefore, we should investigate the root cause more thoroughly and develop countermeasures.

kerem added the

bug

label

2026-02-26 12:00:02 +03:00

kerem commented

2026-02-26 12:00:03 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 7, 2026):

As i mentioned in #1066, I have reinstated the mouse left button down condition in push 4c68570. You said that this would lead to: The focus issue has been resolved by removing that condition. Therefore, if we reinstate it, the problem will recur.

However, I dont know somehow, I did not encounter the issue in Step 8 in the nightly version built from 4c68570. You can check my screen record

https://github.com/user-attachments/assets/707affd7-e321-4664-b407-714265cb9705

@VShawn commented on GitHub (Feb 7, 2026): As i mentioned in #1066, I have reinstated the `mouse left button down` condition in push 4c68570. You said that this would lead to: `The focus issue has been resolved by removing that condition. Therefore, if we reinstate it, the problem will recur.` However, I dont know somehow, I did not encounter the issue in Step 8 in the nightly version built from 4c68570. You can check my screen record https://github.com/user-attachments/assets/707affd7-e321-4664-b407-714265cb9705

kerem commented

2026-02-26 12:00:03 +03:00

Author

Owner

@itagagaki commented on GitHub (Feb 8, 2026):

Once the host window has been properly activated and focused, no further issues should be observed. Please follow the steps I provided in the exact order.

@itagagaki commented on GitHub (Feb 8, 2026): Once the host window has been properly activated and focused, no further issues should be observed. Please follow the steps I provided in the exact order.

kerem commented

2026-02-26 12:00:03 +03:00

Author

Owner

@itagagaki commented on GitHub (Feb 8, 2026):

https://github.com/user-attachments/assets/c040a3e5-cfec-469b-bd1d-552081470efb

@itagagaki commented on GitHub (Feb 8, 2026): https://github.com/user-attachments/assets/c040a3e5-cfec-469b-bd1d-552081470efb

kerem commented

2026-02-26 12:00:03 +03:00

Author

Owner

@VShawn commented on GitHub (Feb 8, 2026):

I reproduced the bug. It's quite a strange.

https://github.com/user-attachments/assets/4944acc5-ef8f-48da-8277-1960f88170e4

@VShawn commented on GitHub (Feb 8, 2026): I reproduced the bug. It's quite a strange. https://github.com/user-attachments/assets/4944acc5-ef8f-48da-8277-1960f88170e4

kerem commented

2026-02-26 12:00:03 +03:00

Author

Owner

@itagagaki commented on GitHub (Feb 22, 2026):

The anomaly occurred in Step 6.
Step 7 confirms this.

Clicking the client area of the RDP window sends a WM_SETCONTEXT message, which triggers a call to AxMsRdpClient9NotSafeForScriptingEx::WndProc().

However, when the RDP window is opened from the host list in Step 5, AxMsRdpClient9NotSafeForScriptingEx::WndProc() does not receive the WM_SETCONTEXT message. This may explain why the behaviour appears inconsistent.

@itagagaki commented on GitHub (Feb 22, 2026): The anomaly occurred in Step 6. Step 7 confirms this. Clicking the client area of the RDP window sends a `WM_SETCONTEXT` message, which triggers a call to `AxMsRdpClient9NotSafeForScriptingEx::WndProc()`. However, when the RDP window is opened from the host list in Step 5, `AxMsRdpClient9NotSafeForScriptingEx::WndProc()` does not receive the `WM_SETCONTEXT` message. This may explain why the behaviour appears inconsistent.

kerem commented

2026-02-26 12:00:03 +03:00

Author

Owner

@itagagaki commented on GitHub (Feb 22, 2026):

Hmm...
Here, it always returns and never goes down...

github.com/1Remote/1Remote@a7f47a7429/Ui/View/Host/TabWindowView.xaml_timer.cs (L242-L245)

TabWindowSetFocusToLocalDesktopOnMouseLeaveRdpWindow remains at its default value of false.
There is no UI to change this setting.
This is one major issue.

However, that doesn't seem to be the only issue.
Removing this if-return statement changes the behavior, but not as expected.
In any case, the implementation of RunForRdpV2 seems to be the main issue.
@VShawn Do you have any thoughts on this?

@itagagaki commented on GitHub (Feb 22, 2026): Hmm... Here, it always returns and never goes down... https://github.com/1Remote/1Remote/blob/a7f47a7429570a974b8ad2d3a1d46047207e1dc6/Ui/View/Host/TabWindowView.xaml_timer.cs#L242-L245 `TabWindowSetFocusToLocalDesktopOnMouseLeaveRdpWindow` remains at its default value of false. There is no UI to change this setting. This is one major issue. However, that doesn't seem to be the only issue. Removing this if-return statement changes the behavior, but not as expected. In any case, the implementation of `RunForRdpV2` seems to be the main issue. @VShawn Do you have any thoughts on this?

kerem referenced this issue

2026-02-26 12:00:23 +03:00

[PR #840] [MERGED] Allow shift-arrow key on the list of remote items in (S)FTP (Fix #839) #903

kerem referenced this issue

2026-02-28 12:05:45 +03:00

[GH-ISSUE #839] Allow shift-arrow key on FTP #1642

kerem referenced this issue

2026-02-28 12:07:01 +03:00

[PR #840] [MERGED] Allow shift-arrow key on the list of remote items in (S)FTP (Fix #839) #1864

kerem referenced this issue

2026-03-01 17:21:49 +03:00

[GH-ISSUE #839] Allow shift-arrow key on FTP #2602