Community
Possible bug 7.0.0.1 - Mouse position when clicking
Links used in this discussion
Trent,
User (Posts: 59)
Mar 16, 2021 9:39:07 am EDT
Support level: Free or trial
I have noticed a change in the mouse behavior between 6.x and 7.x that has me concerned enough to consider it a possible bug. I am running Viewer 7.0.0.1 and Installed Host 7.0.0.1 with Windows 10 on both ends.
The issue is when the RU viewer is NOT the active window and you return to it and click somewhere on the remote computer's screen, the CLICK is registered, but the new position of the mouse is NOT registered, causing the click to happen wherever the mouse was last used on the screen. This can be problematic as you may click on something that you did not intend to click on.
I believe intended behavior (and prior behavior in 6.x) would be to update the mouse position on the remote screen BEFORE sending the click command to ensure proper mouse cursor location for the click.
Steps to reproduce:
1. Connect to a remote session.
2. Confirm that mouse clicks are operating as intended within the viewer to the remote screen.
3. Move the mouse out of the RU viewer making sure that where your mouse leaves the screen, it is on an icon that you can identify. In my tests, I had the desktop showing and moved my mouse off the screen to the left so that the "Recycle Bin" was the last thing it was on.
4. Click a window other than the RU viewer to make it inactive.
5. Return to the RU viewer remote session and RIGHT click on an empty area of the desktop. You SHOULD get the right click menu options at the point where you clicked. Where the menu actually pops up will be where your mouse left the screen (recycle bin icon in my case).
I created this video to illustrate:
https://www.screencast.com/t/8uvIBCyFp1
Let me know if I can answer any questions or provide clarification. Would love to see this fixed in the upcoming 7.0.0.2 patch!
Thanks for all that you do!
The issue is when the RU viewer is NOT the active window and you return to it and click somewhere on the remote computer's screen, the CLICK is registered, but the new position of the mouse is NOT registered, causing the click to happen wherever the mouse was last used on the screen. This can be problematic as you may click on something that you did not intend to click on.
I believe intended behavior (and prior behavior in 6.x) would be to update the mouse position on the remote screen BEFORE sending the click command to ensure proper mouse cursor location for the click.
Steps to reproduce:
1. Connect to a remote session.
2. Confirm that mouse clicks are operating as intended within the viewer to the remote screen.
3. Move the mouse out of the RU viewer making sure that where your mouse leaves the screen, it is on an icon that you can identify. In my tests, I had the desktop showing and moved my mouse off the screen to the left so that the "Recycle Bin" was the last thing it was on.
4. Click a window other than the RU viewer to make it inactive.
5. Return to the RU viewer remote session and RIGHT click on an empty area of the desktop. You SHOULD get the right click menu options at the point where you clicked. Where the menu actually pops up will be where your mouse left the screen (recycle bin icon in my case).
I created this video to illustrate:
https://www.screencast.com/t/8uvIBCyFp1
Let me know if I can answer any questions or provide clarification. Would love to see this fixed in the upcoming 7.0.0.2 patch!
Thanks for all that you do!
Boris Rudoy,
User (Posts: 33)
Mar 16, 2021 10:32:10 am EDT
Support level: Free or trial
I confirm, have same behavior too. RU version 7.0.0.1 host and viewer, Win 10 at host side, Win 7 64bit at viewer side.
Pepa Kokes,
User (Posts: 32)
Mar 16, 2021 2:49:38 pm EDT
Support level: Free or trial
I had the exact same problem even with version 6.10.10.
Trent,
User (Posts: 59)
Mar 16, 2021 4:58:07 pm EDT
Support level: Free or trial
Interesting. I definitely did not experience this in 6.10.
Pauline,
Support (Posts: 2869)
Mar 16, 2021 5:18:37 pm EDT
Hello everyone,
Thank you for bringing this to our attention.
I will forward the issue along with the video provided by Trent to our developers for a review and we will additionally try to reproduce it in our environment to see if we can fix it in the next update. I'll get back to you with a reply from our developers shortly.
I'll keep everyone updated on the issue in this thread.
Thank you for bringing this to our attention.
I will forward the issue along with the video provided by Trent to our developers for a review and we will additionally try to reproduce it in our environment to see if we can fix it in the next update. I'll get back to you with a reply from our developers shortly.
I'll keep everyone updated on the issue in this thread.
Pauline,
Support (Posts: 2869)
Mar 19, 2021 5:49:01 pm EDT
Hello everyone,
Thank you for your patience.
I've checked on this issue with our developers. This is a confirmed bug and it will be fixed in the upcoming version 7.0.0.2 along with a few other bugs/issues.
Please let us know if you have more questions.
Thank you for your patience.
I've checked on this issue with our developers. This is a confirmed bug and it will be fixed in the upcoming version 7.0.0.2 along with a few other bugs/issues.
Please let us know if you have more questions.
Trent,
User (Posts: 59)
Mar 19, 2021 6:10:20 pm EDT
Support level: Free or trial
Excellent news. Many thanks to you and the devs, Polina!
Trent,
User (Posts: 59)
Mar 23, 2021 8:44:06 am EDT
Support level: Free or trial
Polina, any update on the release date of 7.0.0.2? I would be willing to give a test build of it a shot if you would like!
Conrad Sallian,
Support (Posts: 3049)
Mar 23, 2021 9:10:33 am EDT
Hello Trent,
The 7002 release is scheduled for tomorrow (Wednesday).
The 7002 release is scheduled for tomorrow (Wednesday).
Trent,
User (Posts: 59)
Mar 23, 2021 9:11:12 am EDT
Support level: Free or trial
Super! Thanks, Conrad!
* Website time zone: America/New_York (UTC -5)