Xpra: Ticket #787: Windows are minimized when the virtual desktop is changed

I just upgraded from version 0.14.13 to 0.14.17, so I don't know which exactly version introduced the bug.

The bug is strange and hard to describe, but it makes version 0.14.17 unusable for me.

I have 4 virtual desktops on client. I start the xpra on one of the virtual desktop (e.g. desktop 3). I open two windows in xpra instances(e.g. one firefox and one chrome), and move them to separate desktops (e.g. desktop 2 and 4) by keyboard shortcuts. When I focus on the desktop 2 window (firefox) and then go to desktop 4, the desktop 4 window (chrome) is minimized (not shown on desktop but on window list). When I make it reappear on desktop 4, and go to desktop 2, the window there (firefox), which was maximized moments ago, becomes minimized.

It seems that some kind of problem making only one window being shown on one desktop at a time. Or something.

Since I use xpra as my daily main production system, I have do downgrade to the 0.14.13 (I'm writing this message via a xpra instance). I do not have the debugging info saved, but here's my system configuration.

Both server and client run ubuntu 14.04, server 64 bit and client 32 bit. Server command:

xpra \
    --xvfb='Xorg -dpi 110 -noreset -nolisten tcp +extension GLX +extension RANDR +extension RENDER -logfile ${HOME}/.xpra/Xvfb-10.log  -config ${HOME}/.xpra/xorg.conf' \
    --dpi=110 start :100 --bind-tcp=0.0.0.0:10000

client command:

xpra --packet-encoder=rencode --speaker-code=wavpack \
    --compressor=lz4 --dpi=110 attach tcp:workstation:10000


Sat, 17 Jan 2015 04:26:17 GMT - Antoine Martin: owner, summary changed

I have edited the bug title to explain what I think you are describing better: it doesn't sound erratic to me, it sounds like the windows are minimized when the virtual desktop is not shown.

Can you please confirm:


As I mentioned before, I hope you're not typing those commands every time:


Sat, 17 Jan 2015 05:05:03 GMT - Antoine Martin: attachment set

shows Ubuntu 14.04 with 4 workspaces and 2 xpra windows, active on different workspaces


Sat, 17 Jan 2015 05:07:57 GMT - Antoine Martin: description changed

As can be seen on this screenshot: shows Ubuntu 14.04 with 4 workspaces and 2 xpra windows, active on different workspaces

I am unable to reproduce the problem you describe: the windows don't minimize when I switch away from (or back to) their workspaces.

Other information which could be useful (on top of the info requested in comment:1):


Sat, 17 Jan 2015 05:14:33 GMT - Jiang:

Yes, that seems to be what's happening. Whenever a virtual desktop is not focused on, all the windows there are minimized.

I tried it again and see that:

  1. It affects xterm just as it does to browsers.
  2. I am using ubuntu. (my justification is that I simply knows apt system well, and yum not so well. I changed from redhat to ubuntu after redhat 9, and when fedora and yum was not yet there. Back then, rpm dependencies gave me endless griefs. And ubuntu has long term support and are reasonably update, compared with debian) But I dislike unity, so I am using desktop environment called ubuntu flashback, which use metacity as window manager and behaves more or less like gnome2, though it in fact is gnome3, I believe.

I'm not sure if it is a ubuntu issue. What desktop environment do you use?

  1. I am sure the problem is with the client. I tried 0.14.17 on server and 0.14.13 on client, the problem disappear.
  1. I know glxgears is not a benchmark, but when I use 0.14.17 on the server, whatever I use on client (0.14.13 or 0.14.17), when I run glxgears on display :100 and show it via xpra on client, the score is merely 920fps, compared with 1120fps when the server is running 0.14.13. So that may count as another reason to run 0.14.13

In any case, I don't understand how glxgears works. It is a lot faster when I run via xpra than when I run use forward x or virtualgl. When I'm running it over xpra, is the 3D rendering done by the server or the client GPU?

I also attached the full debug log as a file.


Sat, 17 Jan 2015 05:15:45 GMT - Jiang: attachment set


Sat, 17 Jan 2015 05:20:39 GMT - Jiang:

I'm sorry that you cannot reproduce the bug on Ubuntu. You seems to be using unity desktop on the client. As I said, I am using gnome-flashback session. which uses gnome-panel and metacity window manager. https://wiki.gnome.org/Projects/GnomeFlashback

I assume gnome2 desktops, which also use metacity and gnome-panel, which is used in things like linux mint Mate edition or old school redhat enterprise, would show the same behaviour.


Sat, 17 Jan 2015 05:23:05 GMT - Jiang:

By the way, since you've already had an ubuntu on virtual machine, you can try out gnome-flashback session by installing it: apt-get install gnome-session-flashback

and then log out, and in login screen, choose session gnome-flashback (metacity) rather than unity. I hope this helps


Sat, 17 Jan 2015 05:39:14 GMT - Antoine Martin: owner, status changed

so I am using desktop environment called ubuntu flashback


Please mention those things early, it will save us all a lot of time, as this is a "non-standard" / "non-default" setup - it is an essential piece of information.

the score is merely 920fps, compared with 1120fps


That's a completely meaningless metric. It could actually mean the exact opposite of what you think.

In any case, I don't understand how glxgears works. It is a lot faster when I run via xpra than when I run use forward x or virtualgl. When I'm running it over xpra, is the 3D rendering done by the server or the client GPU?


Server. But what matters is how many frames (or pixels) actually make it to the client, not how many frames are rendered on the virtual display.


With gnome flashback, I can reproduce the bug - taking the ticket back.


Sat, 17 Jan 2015 06:24:36 GMT - Antoine Martin: owner, status changed

Explanation: newer desktop environments (compositing window managers) always keep the windows mapped, even when moved to another workspace, so that they can show a live overview of the window contents. (side note: we do have logic in xpra to slow down the refresh rate of windows which are mapped on another desktop - since spending too much cpu+bandwidth on those is often a complete waste) Older desktop environments (like gnome flashback) unmap the window instead, and the recent window state fixes caused it to be iconified too (because we wrongly ignored the iconified flag..).

I believe this is fixed in r8486, backport in r8487 which will be part of 0.14.18. (also needed r8489 + r8490 backport to avoid breaking compatibility with older clients which are missing the iconify part of the unmap-window packet)

There are beta 0.14.18 packages with this fix for Ubuntu 12.04, 14.04 and 14.10 in the beta area. Does this work for you?

Thanks!


Mon, 19 Jan 2015 07:33:13 GMT - Antoine Martin: status changed; resolution set

Not heard back and released 0.14.18 with this fix, so closing.

Feel free to re-open if I've missed anything.


Mon, 19 Jan 2015 20:34:44 GMT - Jiang:

I'm sorry, I missed the new release, as I downgraded to 0.14.13 and disabled the upgrading temporarily. I upgraded it and it is indeed fixed. Thank you for your prompt action. Indeed, now I don't seem to have any issues as far as I can see, so that I will re-enable the upgrade and stay abreast with the latest release.

It seems that the mailing list website is down again, which is why I missed the upgrade. When it is back up, I will just join the mailing list myself, so that I'd get an email when new upgrade is available.


Sat, 23 Jan 2021 05:05:57 GMT - migration script:

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