VNCServerST: Add a timeout to pointer button ownership #1718
Conversation
|
That sounds like an annoying issue, thank you for looking into this. From your description, I assume this is seen with "shared" connections. A colleague and I were able to reproduce the issue with input being locked if a viewer loses connection. Steps we used to reproduce:
We also tested the regular case when two viewers are connected and one user is dragging a window. On master, the second user cannot interfere while the first user is dragging. |
There was a problem hiding this comment.
We built and tested the regular case with your changes. Unfortunately, it seems something is off. When a user is dragging the window in viewer A, viewer B can immediately interfere with the mouse.
We get the impression that the timeout isn't working as intended. Generally, it seems reasonable to keep blocking user B unless we detect a period of inactivity from user A.
common/rfb/VNCServerST.cxx
Outdated
| if (buttonMask) { | ||
| pointerClient = client; | ||
| pointerClientTime = now; | ||
| } |
There was a problem hiding this comment.
I think there's an "else pointerClient = NULL;" missing here
My use case was with x0vncserver, maybe it sets up things differently? Anyway, that missing "else" makes is harder to interfere, so that's not related to what you're seeing |
common/rfb/VNCServerST.cxx
Outdated
| return; | ||
| // to provide a bit more sane user experience. But limit the time to prevent | ||
| // locking out all others when e.g. the network is down. | ||
| if (pointerClient != NULL) { |
There was a problem hiding this comment.
This "if" will never trigger, as nothing will ever assign anything else than NULL to pointerclient...
When one clients holds down a button on the pointer device (probably dragging something), other clients' attempts at pointer operations are denied. This yields a sane user experience, but with limits. When one clients starts dragging, and then his network connection fails, other clients are denied access to the pointer until the VNC server finally discovers that the connection is dead and closes it. This can take about 15 minutes. Add a timeout to this policy: If we don't hear from the client for 3 seconds, other clients are allowed to control the pointer once more. This solves the problem that one failing network could make the server completely deaf to other clients for a long time. Signed-off-by: Mike Looijmans <[email protected]>
MikeLooijmans
force-pushed
the
server-mousebuttonowner-timeout
branch
from
ad1d39c
to
71c83b4
Compare
|
Yep, my attempt to avoid a time(0) syscall when not needed backfired... Better to keep the code path simple. |
There was a problem hiding this comment.
Thank you for the quick update, looks good now!
Rebuilt with the updated commit and tested both the regular use case as well as when one of the clients lost network. Tested the same way as described earlier.
Lastly, we also tested when viewer A stopped moving the mouse but still had the mouse button down. Viewer B could not interfere until more than 3 seconds had passed since viewer A stopped moving.
When one clients holds down a button on the pointer device (probably dragging something), other clients' attempts at pointer operations are denied. This yields a sane user experience, but with limits.
When one clients starts dragging, and then his network connection fails, other clients are denied access to the pointer until the VNC server finally discovers that the connection is dead and closes it. This can take about 15 minutes.
Add a timeout to this policy: If we don't hear from the client for 3 seconds, other clients are allowed to control the pointer once more.
This solves the problem that one failing network could make the server completely deaf to other clients for a long time.