Earlier this year Debian Jessie was released, which updated from xfwm4 4.8.3 to 4.10.1. Eversince I was hit by a bug related to vnc4viewer: Running xfwm4 and vncviewer, I was no longer able to do multi-selections using CTRL+Click in an application within the vncviewer window. However CTRL+[cursor] works for e.g. word-by-word movement in a mousepad controlled via vncviewer. git-bisecting revealed commit d30cd2fb8a2303ed93dd4d0e5d73bfb337541f59 to be the culprit. Let me know, if you need more info. Thanks Daniel
To be more specific on what I actually meant by "able to do multi-selections": The expected behaviour of CTRL+click'ing e.g. files in thunar is to get a selection of multiple files (contiguous, in case of Shift+click'ing). The actual behaviour leaves only the lastly clicked item selected, undoing any previously made selection e.g. by keyboard (CTRL+a or CTRL+[cursor],CTRL+Space or Shift+[cursor] are working fine)
To be honest, it's unlikely I would reinstate that revert. - Does the sequence of X events as observed in vnc4viewer with xev differs with and without that commit? - Does the same occur with the "tree store" demo in gtk-demo?
Created attachment 6519 xev capture - good case
Created attachment 6520 xev capture - bad case
1) yes, they differ, see attachments; I recorded the events received when doing the sequence KeyDown(ctrl), ButtonDown(1), ButtonUp(1), KeyUp(ctrl) - xev-good.log shows the events for working multi-selection (i.e. Jessie's xfwm4 with d30cdf reverted) - xev-bad.log shows the events as perceived by xev when vncviewer is managed by Jessie's xfwm4 You can clearly see the events getting re-ordered in the "bad case" so that KeyUp gets perceived prior to ButtonUp. In fact, running vncviewer and having killed xfwm4, the xev log on the vncserver's side turns out exactly the same as xev-good.log 2) sure enough, same story
Just upgraded to Debian Stretch (xfwm4 4.12.4) and this is working fine now.
Scratch comment #6, I confused the setup. I just upgraded xfwm to 4.12.4 on the machine running the vnc*viewer* and the problem persists.
Just tried this again with xfwm 4.12.4 on the machine running the vnc client, only this time using tigervnc instead of tightvnc. With tigervnc everything works as expected. I guess this bug can be closed.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/201. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev