TurboVNC incorrectly calculates the mouse position after remote rescalling the desktop

[Oleg-N-Cher]

1. Opening a remote work session:

2. Do remote resizing:

After it:

Then when I move the application to the right, I get an incorrect menu operation (Help is pressed, but Attributes opens). It all looks like the maximum right mouse position is limited by the previous desktop resolution.

I'm not quite sure that this is exactly a bug in noVNC. Perhaps this is a TurboVNC server? Please help me figure it out.

OS: Windows 7 x64 Browser: SRWare Iron Browser version: 91.0.4650.0 Server (please complete the following information):

noVNC version: latest VNC server: TurboVNC 2.2.6 WebSocket proxy: websockify

This works well using TigerVNC and TightVNC, so my guess would be that it's related to TurboVNC.

[dcommander]

I can't reproduce the issue, so we need to narrow it down. Please do some testing and determine whether:

• the issue can be reproduced using another type of web browser
• the issue can be reproduced using another window manager
• the issue can be reproduced using the TurboVNC Viewer

[Oleg-N-Cher]

Please forgive me for not having time to deal with this problem thoughtfully.

We used such a terrible bunch of technologies described in this video: https://www.youtube.com/watch?v=a5bDdN082No And there this problem appeared.

I also opened this problem in the noVNC developer community, but they also could not reproduce this problem.

I'm afraid that's all I can report about this problem. You can close the issue.

[dcommander]

I am happy to fix the issue if I can reproduce it. I just need more data in order to reproduce it. If you can’t provide that data, then there is nothing more I can do.

[Oleg-N-Cher]

Hello again, dear dcommander,

You will forgive my persistence. I'm not even claiming that this is a bug in TurboVNC. But I really ask for your help to deal with this. After all, we are all interested in a good stable operation of the software, and our work is successful only if we create reports on problem situations in third-party software. I think that a programmer who works for the future understands this very well.

Therefore, I do not re-open this issue. I'll just give you more information so that you can reproduce the problem for yourself.

I attach an archive with a docker file that reproduces this problem: bug.tar.gz

By the way, the problem can probably be in the fluxbox window manager. I just don't have enough competence and a fine knowledge of the issue to find the cause exactly.

But I just put together this image (script build.sh), launched it (the script run.sh) and got this problem again:

[dcommander]

I will investigate when I have a chance.

[Oleg-N-Cher]

Thank you very much. In fact, there are very high chances that the problem is in TurboVNC, because with TightVNC and TigerVNC, this problem could not be reproduced.

[dcommander]

Reproduced using your container. Attempting to reproduce outside of Docker.

[dcommander]

I have verified that the issue also exists with the build of TigerVNC 1.10.1 supplied by Ubuntu 20.04.

sudo apt install tigervnc-standalone-server
echo fluxbox >~/.vnc/xstartup
chmod 700 ~/.vnc/xstartup
/usr/bin/vncserver -geometry 1024x768

The viewer actually doesn't matter. It is the act of resizing the remote desktop to a larger size than its initial size that triggers the error. I suspect you could also repro the error by resizing the desktop using xrandr. I have no idea whether the issue is in FluxBox or WINE, but it doesn't appear to be in TurboVNC.

[Oleg-N-Cher]

Moved the description of this problem to the FluxBox community:

https://sourceforge.net/p/fluxbox/bugs/1190/

[dcommander]

Sounds good. If there is a way to work around it in TurboVNC, I am happy to do so, but I don't have the resources to diagnose it since it doesn't appear to be a bug in our software. Sometimes issues like these are due to window managers relying on legacy X11 behavior, so perhaps disabling one or more of the X11 extensions will help.