Our vendor drop of TigerVNC is from 2016-07-11. We have multiple bugs that calls for a new vendor drop; this is the meta bug for them.
All done now.
All changes from this drop have now been tested.
*** Bug 6171 has been marked as a duplicate of this bug. ***
When resizing it might be possible for the mouse cursor to end up outside of the new frame buffer. The heap overflow protection will then kick in when it tries to update the server side rendering of the cursor.
(In reply to comment #6) > When resizing it might be possible for the mouse cursor to end up outside of > the new frame buffer. The heap overflow protection will then kick in when it > tries to update the server side rendering of the cursor. Fixed now. Tester should verify that server-side cursors still work. Currently in ThinLinc, it is only used when running the HTML5 client on a platform with a touch screen or on IE/Edge. Tester should also verify that resizing sessions to make them smaller work in combination with server-side cursors AND at reconnection. When testing resize at reconnection, server-side cursors are not required since the server won't know right away if local cursors are supported or not. See the issue we saw in bug 6171. The problem only happened if the cursor was at a position at disconnect which would at the new size be outside the frame buffer. The reconnection issue could be reproduced in the HTML5 client on IE, Edge and Safari.
(In reply to comment #8) > (In reply to comment #6) > > When resizing it might be possible for the mouse cursor to end up outside of > > the new frame buffer. The heap overflow protection will then kick in when it > > tries to update the server side rendering of the cursor. > > Fixed now. > > Tester should verify that server-side cursors still work. Currently in > ThinLinc, it is only used when running the HTML5 client on a platform with a > touch screen or on IE/Edge. > Tested on Android tablet, couldn't find any problems with the mouse. > Tester should also verify that resizing sessions to make them smaller work in > combination with server-side cursors AND at reconnection. When testing resize > at reconnection, server-side cursors are not required since the server won't > know right away if local cursors are supported or not. See the issue we saw in > bug 6171. The problem only happened if the cursor was at a position at > disconnect which would at the new size be outside the frame buffer. The > reconnection issue could be reproduced in the HTML5 client on IE, Edge and > Safari. Tested using both android client and safari and couldn't reproduce the problem, however I found an unrelated bug 6184. Closing this bug.
On macOS, mouse and keyboard events are not propagated when VNC viewer is on non-primary screen. See Issue22939. What is even more strange is that efter moving the window, with the profile selector open, the selected profile is changed. After some investigation, I noticed that vncviewer seems to switch to an old image of the session, which does not correspond to reality.
(In reply to comment #10) > On macOS, mouse and keyboard events are not propagated when VNC viewer is on > non-primary screen. See Issue22939. What is even more strange is that efter > moving the window, with the profile selector open, the selected profile is > changed. After some investigation, I noticed that vncviewer seems to switch to > an old image of the session, which does not correspond to reality. This regression was introduced by the work done on bug 5415, in particular, this upstream commit: https://github.com/TigerVNC/tigervnc/commit/41a0c151c554a37fbffece8ef36848ed47fd17d3 One theory is that some stuff needs to be re-allocated when the window is moved to another screen. Some links: https://developer.apple.com/library/content/technotes/tn2313/_index.html https://github.com/mpv-player/mpv/issues/594
Customer(In reply to comment #10) > On macOS, mouse and keyboard events are not propagated when VNC viewer is on > non-primary screen. See Issue22939. What is even more strange is that efter > moving the window, with the profile selector open, the selected profile is > changed. After some investigation, I noticed that vncviewer seems to switch to > an old image of the session, which does not correspond to reality. Customer says the issue is fixed with build 5440.
(In reply to comment #14) > Customer(In reply to comment #10) > > On macOS, mouse and keyboard events are not propagated when VNC viewer is on > > non-primary screen. See Issue22939. What is even more strange is that efter > > moving the window, with the profile selector open, the selected profile is > > changed. After some investigation, I noticed that vncviewer seems to switch to > > an old image of the session, which does not correspond to reality. > > Customer says the issue is fixed with build 5440. I've also tested build 5447 on our macOS 10.12, works fine.
