! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
[PATCH/BISECTED] multiselection using ctrl+click not possible within vncviewe...


Description Daniel Reichelt 2015-09-21 12:31:37 CEST
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.

Comment 1 Daniel Reichelt 2015-09-22 03:02:49 CEST
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)
Comment 2 Olivier Fourdan editbugs 2015-11-06 09:04:08 CET
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?
Comment 3 Daniel Reichelt 2015-11-06 23:57:39 CET
Created attachment 6519 
xev capture - good case
Comment 4 Daniel Reichelt 2015-11-06 23:57:56 CET
Created attachment 6520 
xev capture - bad case
Comment 5 Daniel Reichelt 2015-11-06 23:58:10 CET
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
Comment 6 Daniel Reichelt 2017-07-02 15:02:18 CEST
Just upgraded to Debian Stretch (xfwm4 4.12.4) and this is working fine now.
Comment 7 Daniel Reichelt 2017-07-07 18:10:43 CEST
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.
Comment 8 Daniel Reichelt 2017-07-27 22:43:35 CEST
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.
Comment 9 Git Bot editbugs 2020-05-29 12:08:41 CEST
-- 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

Bug #12221

Reported by:
Daniel Reichelt
Reported on: 2015-09-21
Last modified on: 2020-05-29


Olivier Fourdan
CC List:
0 users




xev capture - good case (911 bytes, text/x-log)
2015-11-06 23:57 CET , Daniel Reichelt
no flags
xev capture - bad case (915 bytes, text/x-log)
2015-11-06 23:57 CET , Daniel Reichelt
no flags

Additional information