Tight VNC (and presumably all VNC servers) fail to support "tab" relocation, i.e. drag-and-drop tabs in various browsers (seamonkey, chrome, etc.) or even gnome-panel. This makes it impossible to sort tabs according to ones preferences or move tabs to different windows (in browsers). Using gnome-panel to move windows between workspaces does work as do most other common gnome/window functions. Reproducible: Always Steps to Reproduce: 1. Start vncserver (tightvncserver, really Xvnc under the covers) 2. Start gnome-session associated with server (via xstartup) 3. Start vncviewer (tightvncviewer) on remote machine and connect to server. Actual Results: Once one has this working the gnome-session starts fine in the viewer. One gets the typical panels associated with a specific UID. But attempts to move program tabs (e.g. gnome-terminal's, seamonkey, etc.) on the bottom gnome-panel or attempts to move tabs within a browser, e.g. seamonkey) fail. Expected Results: It should be possible to relocate panel program summary windows or browser tabs.
Created attachment 257620 [details] emerge --info emerge --info output
Created attachment 257621 [details] Compressed log of server session Gzipped log of server session. May contain results of multiple connections from the viewer to the server.
Various viewer switches, e.g. -x11cursor, -nocursorshape, -nojpeg seem to have no effect. The log records seem to indicate one is using the least compress protocol: 20/12/10 10:54:37 Using raw encoding for client 192.168.1.5 20/12/10 10:54:37 Using compression level 6 for client 192.168.1.5 20/12/10 10:54:37 Enabling X-style cursor updates for client 192.168.1.5 20/12/10 10:54:37 Enabling cursor position updates for client 192.168.1.5 20/12/10 10:54:37 Enabling LastRect protocol extension for client 192.168.1.5 One thing that is apparent is that the "down-arrow" which appears above the gnome-panel or the browser tab list to indicate where the tab will be dropped does not appear when attempting a tab relocation. So it appears that the application is not receiving information about where the cursor has been positioned. It may be worth noting that the server/viewer does not seem to support the RANDR extension though it is not clear to me if this is involved. I have seen web notes that some people have extended the server/viewer combination to support RANDR.
This should go upstream...we don't modify software.
There are 3 problems with Raúl's comments. 1) There is no indication of precisely *where* "upstream" is. Who maintains tightvnc? And shouldn't the Gentoo developers be pushing the bugs up there? 2) There seems to be no attempt at Q/C at the gentoo level. It seems to be buyer-beware software. One would presume that before tightvnc was added to the valid distribution list that *somebody* tested it (the bugs I have filed recently would be considered "show-stoppers" IMO). So at some point there was some combination of tightvnc *and* gnome that worked. What were those? I realize that I am using "beta" releases, e.g. net-misc/tightvnc-1.3.10-r1 and ~gnome-2.32 but if there is a "supported" release level Gentoo bug screens should test whether the bugs exist at those levels. 3) The "tab" relocation feature is one which has only recently been added to browsers and the gnome-panel -- does it depend on some feature in X which is unsupported by VNC software -- and if so what is it? 4) Most of the packages I've seen do have "patches" to the base software -- so Gentoo *does* modify software. I would like to see this reopened until someone VERIFIES the problem (i.e. its existence/behavior is confirmed). Then this bug report gives a common discussion point for other individuals who may encounter it. The status is clearly not RESOLVED.
Interesting. Chromium 8.0.552.224 *will* allow tab shifting under VNC. However, SeaMonkey-2.0.11 will not allow it. That would suggest that it have something to do with how the browsers handle this operation (which in SeaMonkey, Firefox and gnome-panel) appears to involve the superimposed "arrow" that indicates the location where the tab will be relocated.
(In reply to comment #5) 1) upstream is at http://www.tightvnc.com/ . I don't have the time to send any bugs, so you'll have to do it because no one else wants to maintain tightvnc. 2) Well, tightvnc does whats supposed to do, which is to provide a remote desktop. The bugs you mentioned i'm pretty sure have been there since the first version of tightvnc. So according to you tightvnc should never been added to the tree because some stuff doesn't work. 3) Probably, i don't know what it is, but i wouldn't expect it working on tightvnc, since the X code base used on tightvnc is from the Xfree86 days. Besides upstream hasn't cared for linux support for some years already 4) The patches added to the tree are patches that are available upstream or patches that the gentoo developer that adds them accepts all the blame. I don't know how to fix the issues you're reporting, so i don't patch it. I prefer upstream to fix their software. I tried tightvnc and i was able to reproduce the issue. net-misc/tigervnc works fine though.
Closing this again...
