www.cendio.com
Bug 6153 - Our TigerVNC is out of sync with upstream
: Our TigerVNC is out of sync with upstream
Status: CLOSED FIXED
: ThinLinc
VNC
: trunk
: PC Unknown
: P2 Normal
: 4.8.0
Assigned To:
:
:
:
: 5415 5495 6079 6141 6165
  Show dependency treegraph
 
Reported: 2017-01-31 08:45 by
Modified: 2017-05-10 15:54 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From cendio 2017-01-31 08:45:26
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.
------- Comment #3 From cendio 2017-02-08 16:33:44 -------
All done now.
------- Comment #4 From cendio 2017-02-14 15:01:03 -------
All changes from this drop have now been tested.
------- Comment #5 From cendio 2017-02-23 13:01:57 -------
*** Bug 6171 has been marked as a duplicate of this bug. ***
------- Comment #6 From cendio 2017-02-23 13:04:29 -------
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.
------- Comment #8 From cendio 2017-02-23 13:52:37 -------
(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.
------- Comment #9 From cendio 2017-03-02 14:38:11 -------
(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.
------- Comment #10 From cendio 2017-04-25 14:07:53 -------
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.
------- Comment #11 From cendio 2017-04-26 13:58:10 -------
(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
------- Comment #14 From cendio 2017-05-02 10:29:24 -------
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.
------- Comment #15 From cendio 2017-05-10 15:54:04 -------
(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.