Is your bug report about the Desktop Multivnc or the Mobile MultiVNC?
- Mobile (Android) on a Chromebook:
(Version 147.0.7727.105 (Official Build) beta (64-bit))
Which MultiVNC version are you using?
2.3.4
Which server are you connecting to?
- VNC server vendor: Both TigerVNC on Fedora 34 and TightVNC on Windows 11
- VNC server version: TightVNC 2.8.87.0 & TigerVNC-Server 1.16.2
- OS version: Windows 11 and Fedora 34 (both updated within the last 48 hours)
- OS language: English
Describe the bug
So once the mouse cursor leaves the remote window, the mouse within the window continues to move and get clicks. That's an issue, because when I go to the to the "hamburger" in the top right of the screen, the mouse will go the top right of the remote screen, which if there's a window full-sized, is the "X" to exit the window. Click on the hamburger... bye-bye app window on the remote machine!
I think the fix is fairly straight-forward, simply stop sending mouse movements and clicks once the mouse leaves the porthole view of the remote window.
To Reproduce
- Open the app.
- Open expand to full-screen.
- Open the remote connection.
- Open a test app (e.g. Notepad or a terminal).
- Full-screen the remote application.
- Go to the "Hamburger" ... notice the mouse moves to top-right corner of screen.
- Click on "Hamburger"... notice the application in the window closes.
Expected Behavior
Expected behavior is that when the mouse leaves the porthole view of the remote screen, the mouse ON the remote screen stops moving and clicks are not passed through. In other words, the remote desktop only gets focus when the mouse is inside that window.
Screenshots
Sorry, haven't got that working yet.
For the Desktop Version (please complete the following information):
- OS and version: See above. Don't think this matters for this particular issue
- Xorg version used:"
- Wayland version used:"
For the Mobile Version (please complete the following information):
- Android version:See above
- Installed from Play Store, F-Droid, Amazon Appstore: Play Store
Additional context
While trying to get screenshots (and failing), i noticed that it was ALSO passing keys to the remote machine while mouse was out of window focus. It was Pressing "alt-tab" to switch over to the browser to add notes to this ticket caused the Windows box I was connected to try test to also start switching applications. Looks like it just needs to have a focus flag added that will block passing anything to the client when the mouse is not in the porthole.
Is your bug report about the Desktop Multivnc or the Mobile MultiVNC?
(Version 147.0.7727.105 (Official Build) beta (64-bit))
Which MultiVNC version are you using?
2.3.4
Which server are you connecting to?
Describe the bug
So once the mouse cursor leaves the remote window, the mouse within the window continues to move and get clicks. That's an issue, because when I go to the to the "hamburger" in the top right of the screen, the mouse will go the top right of the remote screen, which if there's a window full-sized, is the "X" to exit the window. Click on the hamburger... bye-bye app window on the remote machine!
I think the fix is fairly straight-forward, simply stop sending mouse movements and clicks once the mouse leaves the porthole view of the remote window.
To Reproduce
Expected Behavior
Expected behavior is that when the mouse leaves the porthole view of the remote screen, the mouse ON the remote screen stops moving and clicks are not passed through. In other words, the remote desktop only gets focus when the mouse is inside that window.
Screenshots
Sorry, haven't got that working yet.
For the Desktop Version (please complete the following information):
For the Mobile Version (please complete the following information):
Additional context
While trying to get screenshots (and failing), i noticed that it was ALSO passing keys to the remote machine while mouse was out of window focus. It was Pressing "alt-tab" to switch over to the browser to add notes to this ticket caused the Windows box I was connected to try test to also start switching applications. Looks like it just needs to have a focus flag added that will block passing anything to the client when the mouse is not in the porthole.