Xpra: Ticket #259: xpra mishandling multiple desktops

xpra seems to get a little confused when used on a system with multiple desktops and xpra managed windows on more than one desktop. (I have seen this behaviour on all 0.8.* builds. When I went back to 0.7.8, the problems did not appear.)

For example:

It seems that xpra isn't aware of desktop changes until something causes a change in window state.



Thu, 14 Feb 2013 14:24:25 GMT - Doug Doole:

I spent some more time playing with older versions of the client to narrow down when the problem appeared.

0.7.8 handled multiple desktops fine 0.8.0 shows the bad behaviour


Thu, 14 Feb 2013 16:09:03 GMT - Antoine Martin:

Thanks, that narrows it down quite a bit.

I'll try to reproduce this asap.


Fri, 15 Feb 2013 08:40:46 GMT - Antoine Martin:

First, the reason why 0.7.x and earlier behave differently is because 0.7.x did not try to preserve workspace mappings for each window, this is a new feature in 0.8.x, see: #170 for the feature request and associated changesets. The code works by waiting for the window to be mapped/shown, then sending it a request to move to the desired desktop/workspace.

This workspace setting/changing is only ever done if we know what workspace the window should be on, that is if the window has been configured/mapped on a client before. Now, it is possible for the window to be "configured" on the client (which will then record which workspace it is configured on) before it is mapped (which will then try to honour the workspace mapping) - but why would the workspace be different between those two events?

I really do not understand what is going on here.. Maybe you can help:

I assume that when you mean "start XXX on desktop YYYY" you don't mean to say "attach xpra to an existing session..."?


Fri, 15 Feb 2013 09:02:21 GMT - Antoine Martin:

Hah, silly me, can you try r2737 to see if it helps?

Also, when I tested with cinnamon/gnome3, we don't get map events as expected when the windows are moved, so we don't notice that they have moved.. I'll need to think of something for this case. (maybe PropertyNotify can help here?)


Mon, 18 Feb 2013 18:58:22 GMT - Doug Doole:

One detail I forgot to mention is that I am running KDE at the client.

I've tried a number of apps - xterm, xclock, and they all misbehave. I have moved to 0.8.5 and the problem is still there.

When I'm referring to "start XXX on desktop YYY", it is all within a single xpra session. I start two terminals, one on each desktop, and then issue commands from the terminals to start the applications that create the windows.

I'll apply your changes from r2736 and r2737 to the 0.8.5 code and provide the log later.


Mon, 18 Feb 2013 19:42:59 GMT - Doug Doole: attachment set


Mon, 18 Feb 2013 19:44:23 GMT - Doug Doole:

The file xpra.debug contains the requested output as I followed (roughly) the steps in my initial report. (r2737 didn't fix the problem.)


Mon, 18 Feb 2013 19:46:54 GMT - Doug Doole:

As an aside, after my last repro, I had a bunch of windows on desktops 2 and 3. When I dropped my xpra connection and reconnected, all the windows appeared on desktop 2.


Mon, 18 Feb 2013 22:45:57 GMT - onlyjob: cc set


Wed, 20 Feb 2013 19:49:44 GMT - Doug Doole:

As an aside, it looks like r2737 causes problems with pop-up windows (e.g. right click menus) when used with multiple monitors. When a pop-up menu appears, it always appears on monitor 1, even if the base window is on monitor 2.

The problem does not appear with pull-down menus.

When I reverted to base 0.8.5, the problem went away.


Thu, 21 Feb 2013 05:36:24 GMT - Antoine Martin:

Hah, I didn't test on multi-monitor setups, but the r2737 change should not make things worse - so it sounds to me like we have a case where we detect the current monitor and send the information back to the server, then when we actually map the window we find the value is set and try to honour it (why it is different at this point is beyond me) - doing so is what causes the problems - maybe we need to detect the current monitor as well as workspace so that is preserved too.

Another way of saying it: r2737 is still good, what is bad is that we somehow find that the window is not shown on the display (x11 display, not "monitor") we expect it to be on (but from what you are saying, it is), so we then try to move it where we think it should be (and that's probably what causes it to move to the wrong monitor).

Actions:


Sun, 24 Feb 2013 16:30:35 GMT - Antoine Martin:

Fixed some bugs and added code to preserve the screen the window is on in r2779, r2780 and r2782

Does this help?

If not, can you tell us more about your setup? Is it just a plain xinerama display? Or some is it handled by the graphics card driver? Can you post:

xdpyinfo

I don't have a dual monitor setup to test on atm...


Mon, 25 Feb 2013 22:56:33 GMT - onlyjob:

I think I've been hit by this bug today in Xpra-0.8.5. I was working from my usual PC on Desktop1 for some time. Then I attached to my session from another PC where (I think) I was working on Desktop2. After returning to first PC and attaching session I couldn't find any windows on active Desktop1 -- only tray icons appeared. Clicking tray icons did not help and only after some time I realised that everything opened in hidden Desktop2. I didn't have a chance to try fixes from comment11 but I hope this feedback add some information about this bug. After dragging windows to Desktop1 when I click File-->New, new document window still opens in Desktop2, not on Desktop1 where application is. It's all started only after attaching from another PC. Both PC's are running KDE and this bug was not present in versions prior to 0.8.0.


Tue, 26 Feb 2013 01:00:29 GMT - onlyjob:

Tried 0.8.5 + r2779, r2780 and r2782 but the problem is not fixed. Here is what's happening:

  1. From terminal emulator running on Desktop-1, xpra attach open all windows on current Desktop-1 (expected).
  1. Disconnect, drag terminal emulator to Desktop-2, switch to Desktop-2, xpra attach -- all windows opened on current Desktop-2 (expected).
  1. Disconnect, drag terminal emulator back to Desktop-1, switch to Desktop-1, xpra attach -- all windows opened on Desktop-2 (unexpected, current is Desktop-1).

Tue, 26 Feb 2013 05:45:45 GMT - Antoine Martin:

There is a misunderstanding here: the code is supposed to preserve the workspace the windows were on. So when you say:

Disconnect, drag terminal emulator to Desktop-2, switch to Desktop-2, xpra attach -- all windows opened on current Desktop-2 (expected).

That is wrong. The windows should have appeared on Desktop-1, where they were before. This is fixed in r2799 (was a sort of a "off by one" error: we never restored windows to their original desktop if it was the first one, aka "0" since this is "base 0" - confusing isn't it!)

Disconnect, drag terminal emulator to Desktop-2, switch to Desktop-2, xpra attach -- all windows opened on current Desktop-2 (expected).

This time, it is correct: the windows are restored on the desktop they were last seen on. (and this is still the case with latest trunk)

Please confirm and I will close this ticket and apply to the 0.8.x branch.


Tue, 26 Feb 2013 07:28:16 GMT - onlyjob:

I will check r2799 indeed but if I understood your explanation, Desktop preservation is wrong and soon enough it will be reported as bug if not by myself then by somebody else. It is so obvious I feel awkward explaining it. When application is started it should open on current desktop. Otherwise it is a misfeature or usability bug. I didn't check freedesktop standards but I'm sure it is against best practice and likely against usability guidelines too. I know no application that would start on inactive desktop whatsoever.

Specifically regarding Xpra, such behaviour as "desktop preservation" is very confusing and counter-productive when session is attached from different computers with different Desktop configuration. Sticking apps to a particular desktop and restore 'em there is wrong, especially as it is implemented now when I can't even move apps to another desktop because they still think they run on desktop where Xpra put them and open all their dialogs not on active desktop where main application windows are but on invisible desktop!

Moreover I have different number of desktops configured on my PCs and using them to attach to single Xpra session is a terrible mess now.

I'll try r2799 ASAP but if desired behaviour matching my description then please reconsider or at least make this "feature" configurable and preferably disabled by default. Thank you.


Tue, 26 Feb 2013 08:02:38 GMT - onlyjob:

Tried 0.8.5+r2779+r2780+r2782+r2799. I'm very disappointed. It is looks like Xpra tries to put applications to the very desktop where they've been. However as I mentioned already it is wrong and it doesn't even work well:

It is causing havoc on task bar where application buttons appear but if clicked, desktop is switching and taskbar button disappears from one desktop and appears on another. Itis very inconvenient to move apps to the desirable desktop after attaching but even this doesn't work as expected -- when I move one app. to another desktop it doesn't stick there but moves back to original desktop (to other applications) on next attach. When I moved kmail to another Desktop and clicked "New email" twice, two windows were opened on different desktops! Horrible, unnecessary mess... :( Sorry, I miss "good old days" of 0.7.8... :(


Tue, 26 Feb 2013 08:05:48 GMT - Antoine Martin:

One man's feature request is another's "bug". Some clarifications:

When application is started it should open on current desktop.

That is always the case. Nothing has changed here. It is only when you disconnect and then re-connect that the windows will be re-mapped to the workspace they were on previously - and only if connecting from the same client machine.

.. misfeature ... usability bug .. against usability guidelines ... start on inactive desktop

See above, that is not the case. If it was, that would be a bug.

... confusing ... counter-productive .. from different computers with different Desktop configuration

As I said above, this only applies when connecting from the same computer.

Sticking apps to a particular desktop and restore 'em there is wrong

That is a matter of opinion.

I can't even move apps to another desktop because they still think they run on desktop where Xpra put them and open all their dialogs not on active desktop where main application windows are but on invisible desktop!

First I have heard of this. Why isn't there a bug report? It's very hard to fix things we don't know about.

Moreover I have different number of desktops configured on my PCs and using them to attach to single Xpra session is a terrible mess now.

Each client PC should have its own workspace mapping. Maybe you aren't using all the fixes I posted?


I'm very disappointed

Well, I am very unhappy about the tone of your messages. That makes two.

it is wrong and it doesn't even work well:

See above.

It is causing havoc on task bar where application buttons appear but if clicked, desktop is switching and taskbar button disappears from one desktop and appears on another.

Another issue I was not aware of, which is not detailed enough for me to do anything about.

Horrible, unnecessary mess.

Expletives deleted.

I miss "good old days" of 0.7.8

Feel free to maintain that because I won't.

Feel free to file a bug to add a --no-preserve-workspace.


Tue, 26 Feb 2013 08:25:59 GMT - onlyjob:

I added r2737 to set of patches applied to 0.8.5 (in case I missed something important). Nothing changed.

Another problem that I've noticed is in Firefox: when moved to another desktop it disappeared from it when one of its plugins shown dialog on invisible (inactive) desktop which probably dragged main window there. I hope you would agree that windows randomly jumping between desktops is a bug and a nasty one.

It is true that one man's feature may be another man's bug. However in this case we have a whole bunch of regression bugs that I'm not sure if I have enough time to properly report and troubleshoot, considering how much time it took me to go through testing of all 0.8.x release up to 0.8.5...

I think it would be better to disable "sticky desktop" mis-feature and perhaps add such experimental functionality as disabled by default, so it probably should be "--preserve-workspace". I hope this mess could be addressed here without multiple bug reports. Thank you.


Tue, 26 Feb 2013 08:30:49 GMT - onlyjob:

Apologies for the tone of my messages. I know you're doing your best. It's just so frustrating to stumble upon that many issues at once when it's late and other priorities demand the little precious time...


Tue, 26 Feb 2013 08:43:42 GMT - Antoine Martin:

Please don't cherry pick patches from trunk on top of an older version, the patches need to be applied to both client and server and the only sane way of testing this is to run trunk.

when moved to another desktop it disappeared.. agree is a bug and a nasty one

I don't understand how to reproduce, so I won't agree to anything. New, never seen before windows will always be shown on the current desktop, that was the case before, and still is the case.

whole bunch of regression bugs

Again, I don't know what those bugs are, or if they are regressions.

mis-feature... I hope this mess ... experimental functionality

Totally unhelpful choice of language.

..without multiple bug reports

Since I don't have clear steps to reproduce any of those supposed bugs on current trunk, things are unlikely to move very fast.


Tue, 26 Feb 2013 08:48:32 GMT - onlyjob:

I'm trying trunk r2802 now... It is too early to report success but it appears to be better when I upgraded both client and server. I can't reproduce kmail windows opening on invisible desktop which is good. However in my case applications are stick to Desktop-2 and re-appear on Desktop-2 after re-attach even if I move the to Desktop-1 before disconnection.

I'll report more details later.


Tue, 26 Feb 2013 08:51:42 GMT - Antoine Martin:

Important: applications need to be mapped to a desktop before we know they are there.

Simply moving them to a desktop using window manager controls is generally not enough, one has to visit that desktop at least once for the local window manager to map the window there (show it to you). Until then, as far as any application is concerned (including xpra), the window is just not shown anywhere, so the workspace mapping will remain what it was when the window was last shown anywhere. This may well be what you are reporting there.


Tue, 26 Feb 2013 09:09:54 GMT - onlyjob:

Interesting. Somehow it is more than just visit desktop needed. Thanks to your hint I finally managed to move application to another desktop so it will stay there on next attach, but only if I moved application window within desktop after dragging moving to another desktop. Simply switch to another desktop or even work with application for some time is not enough for it to stay on this desktop on next session attach unless its window was moved.


Tue, 26 Feb 2013 09:22:33 GMT - Antoine Martin:

Hah, ok, that's a DE thing, my DE unmaps windows when they get moved then maps them back when I see them again on a new desktop, compositing window managers may not do that (maps them once, then changes the property only without sending a configure event, moving them always fires a configure event so we spot the desktop change then).

Can you post the client's output with -d all of just when you move the window to another desktop. (probably not much there at all - if anything) And maybe also add, when you switch to that desktop. (try avoidking mouse movements or key presses to reduce the log output)

Here is mine when I move it (just some focus change as I click on the title bar):

_focus_change((<ClientWindow object at 0x1ebd500 (xpra+client_window+ClientWindow at 0x1f5e010)>, <GParamBoolean 'has-toplevel-focus'>))
update_focus(4,True) _focused=None
_focus_change((<ClientWindow object at 0x1ebd500 (xpra+client_window+ClientWindow at 0x1f5e010)>, <GParamBoolean 'has-toplevel-focus'>))
update_focus(4,False) _focused=4

And this shows up when I switch to the desktop the window is now shown on:

Got map event: <gtk.gdk.Event at 0x1ebe0f8: GDK_MAP>
xget_u32_property(<gtk.gdk.Window object at 0x1ebdc30 (GdkWindow at 0x1c78120)>, _NET_WM_DESKTOP)=1
get_workspace() found value=1 from <gtk.gdk.Window object at 0x1ebdc30 (GdkWindow at 0x1c78120)> / _NET_WM_DESKTOP
_focus_change(())
update_focus(4,False) _focused=None
setting new cursor: xterm=<enum GDK_XTERM of type GdkCursorType>
_focus_change((<ClientWindow object at 0x1ebd500 (xpra+client_window+ClientWindow at 0x1f5e010)>, <GParamBoolean 'has-toplevel-focus'>))
update_focus(4,True) _focused=None

Tue, 26 Feb 2013 16:03:02 GMT - Antoine Martin:

r2813 takes care of detecting when the window is moved to another desktop without being mapped/unmapped - should take care of compositing window managers. (r2814 in 0.8.x branch)


Tue, 26 Feb 2013 16:24:26 GMT - Doug Doole:

Unfortunately, this "job" thing has me completely swamped right now. I likely won't be able to try the patch for a couple days.


Wed, 27 Feb 2013 03:24:31 GMT - onlyjob:

Sorry for delay, I see that r2813 was already released in 0.8.7 which I started to test.

Antoine, from your explanation it looks like "unmapped" windows moved to another desktop may be a single cause of all the troubles that I had with applications that "not really" moved to another desktop but only appears as such. Notably I had

With Xpra-0.8.7 windows can be reliably moved between desktops and they are remembering their position on session re-attach. Well done.

Thank you very much for fixing this problem and once again apologies for rant.


Wed, 27 Feb 2013 04:06:26 GMT - Antoine Martin: status changed; resolution set

I believe this is fixed - feel free to re-open if not.


Wed, 27 Feb 2013 14:03:19 GMT - Doug Doole: status changed; resolution deleted

This is still broken for me.

This is seriously impacting the usability of xpra for me. Could we add an option to disable workspace tracking until we sort this out? (Previously I was inconvenienced once a day, when I first connected. Now I'm having trouble every time I change desktops.)


Wed, 27 Feb 2013 14:05:48 GMT - Antoine Martin: status changed; owner set

Sure, I'll see what I can do, but first can you answer the questions in comment:11 about your setup so I can try to reproduce (and then I'm confident this can be fixed one way or another). ie: xinerama or not, driver, etc..


Wed, 27 Feb 2013 14:09:10 GMT - Doug Doole: attachment set


Wed, 27 Feb 2013 14:14:15 GMT - Doug Doole:

Oops, I missed that request. Sorry about that.

xpyinfo has been attached.

I'm running dual monitors using nVidia's TwinView technology, not Xinerama. I'm not super versed in the differences, but my understanding is that Twinview handles the multiple displays in the driver, and - for the most part - X just sees a single big display. (I say "for the most part" because X is still aware that there are multiple screens because, for example, KDE can set a separate background image on each monitor.)


Wed, 27 Feb 2013 14:18:06 GMT - Antoine Martin:

Hah, that's very odd, I would have thought that TwinView would make it easier not harder, since the whole display is one area/one driver. Can you post your server log message which is going to be similar to this one:

max client resolution is 2560x1600 (from [[2560, 1600]]), current server resolution is 2560x1600

Until I can figure out what is going on here, I may be able to detect multi-monitor/screens setups and disable the preserve feature automatically (at least until I figure out what is going on)


Wed, 27 Feb 2013 14:25:22 GMT - Antoine Martin:

Just a thought, this may not be a "workspace" thing but a "screen" thing, in which case this may be what you need:

--- src/xpra/client_window.py	(revision 2827)
+++ src/xpra/client_window.py	(working copy)
@@ -227,7 +227,8 @@
         if screen_num and screen_num>=0 and screen_num<display.get_n_screens():
             screen = display.get_screen(screen_num)
             if screen:
-                self.set_screen(screen)
+                #self.set_screen(screen)
+                log.info("***** not setting new window to screen %s", screen_num)
         self.set_app_paintable(True)
         self.add_events(WINDOW_EVENT_MASK)

Wed, 27 Feb 2013 14:40:02 GMT - Antoine Martin:

Also worth checking: you did upgrade your server with "xpra upgrade" since the last release? (you can check the version running with "xpra info") Also, I forgot to ask, what is the client OS/version?

The reason why I ask is that popup windows are generally "Override-redirect" windows, and those would not be affected by the workspace code at all, only the "screen" preserve code, and the screen preserve code should never fire (at least on up-to-date versions) since the window is new and therefore does not have any preferences recorded yet (and in the case of OR windows, it never will).


Wed, 27 Feb 2013 14:56:23 GMT - onlyjob:

0.8.7 saved me but only after I upgraded both client and server (followed by xpra upgrade) so Antoine is correct, it's better to make sure that everything is up-to-date. :) Updating only client from version 0.8.5 didn't fix all issues for me, but upgrading server as well made the difference.


Wed, 27 Feb 2013 15:01:06 GMT - Doug Doole:

Here's the server log text:

max client resolution is 3600x1200 (from [[3600, 1200]]), current server resolution is 1680x1050
new resolution matching 3600x1200 : screen now set to 3840x2048

(Last night I was running at home with just the laptop display, hence the smaller current server resolution.)

I'm still running the 0.8.4 client - can't risk a server upgrade for a few more hours. (It's generally no problem, but I really can't afford to have my current runs get interrupted.) I'll upgrade the server later today and test again.


Wed, 27 Feb 2013 17:29:07 GMT - Doug Doole: status changed; resolution set

OK. Once I upgraded the server everything looks good.

My apologies for the confusion. From our earlier conversation I thought all the fixes were client side so I didn't worry about the server upgrade.

We can close this again.


Thu, 28 Feb 2013 06:08:32 GMT - Antoine Martin:

Great, thanks for testing.

FYI: I've just added your resolution to the default XDummy xorg.conf we ship: see r2840. Assuming that you do use XDummy and not Xvfb (I still don't know what distro/version you use), this should make things work better with your setup (no menus scrolling off the screen, etc). You can apply it to your current xorg.conf or just wait for the next release.


Thu, 28 Feb 2013 14:51:37 GMT - Doug Doole:

Thanks.

I am using XDummy. I'm running Ubuntu 12.04 64-bit at the server and Kubuntu 12.04 32-bit at the client.


Sat, 23 Jan 2021 04:49:51 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/259