Windows are minimized when the virtual desktop is changed

[totaam]

Issue migrated from trac ticket # 787

component: client | priority: major | resolution: fixed

2015-01-17 04:07:20: jiang.qian created the issue

---

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

[totaam]

2015-01-17 04:26:18: totaam changed owner from antoine to jiang.qian

[totaam]

2015-01-17 04:26:18: totaam changed title from Windows show up erratically on virtual desktops to Windows are minimized when the virtual desktop is changed

[totaam]

2015-01-17 04:26:18: totaam commented

---

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:

• that this affects any application (preferably an xterm which is easy to test with) and not just the browsers
• what desktop environment you are using (I am not seeing this behaviour here), it could well be another Ubuntu-only thing

---

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

• the xvfb option belongs in the /etc/xpra/xpra.conf
• same for xpra dpi, though that one could conceivably be a per-user preference stored in ~/.xpra/xpra.conf
• rencode and lz4 are already the defaults, so no need to specify them
• wavpack may well be the default too (it depends)

[totaam]

2015-01-17 05:05:04: antoine uploaded file Ubuntu-14.04-4workspaces.png (517.2 KiB)

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

[totaam]

2015-01-17 05:07:57: antoine edited the issue description

[totaam]

2015-01-17 05:07:57: antoine commented

---

As can be seen on this screenshot: [[Image(Ubuntu-14.04-4workspaces.png)]]

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):

• xpra info when at least one of the window is minimized
• -d workspace output (both client and server)

[totaam]

2015-01-17 05:14:34: jiang.qian commented

---

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?

3. 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.

4. 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.

[totaam]

2015-01-17 05:15:45: jiang.qian uploaded file xpra-session-information.txt.zip (599.2 KiB)

[totaam]

2015-01-17 05:20:39: jiang.qian commented

---

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.

[totaam]

2015-01-17 05:23:05: jiang.qian commented

---

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

[totaam]

2015-01-17 05:39:14: totaam changed status from new to assigned

[totaam]

2015-01-17 05:39:14: totaam changed owner from jiang.qian to totaam

[totaam]

2015-01-17 05:39:14: totaam commented

---

so I am using desktop environment called ubuntu flashback [[BR]] 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. [[BR]]

the score is merely 920fps, compared with 1120fps [[BR]] That's a completely meaningless metric. It could actually mean the exact opposite of what you think. [[BR]] 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? [[BR]] 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.

[totaam]

2015-01-17 06:24:36: totaam changed status from assigned to new

[totaam]

2015-01-17 06:24:36: totaam changed owner from totaam to jiang.qian

[totaam]

2015-01-17 06:24:36: totaam commented

---

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 8487 which will be part of 0.14.18. (also needed r8489 + 8490 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!

[totaam]

2015-01-19 07:33:13: totaam changed status from new to closed

[totaam]

2015-01-19 07:33:13: totaam changed resolution from * to fixed*

[totaam]

2015-01-19 07:33:13: totaam commented

---

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

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

[totaam]

2015-01-19 20:34:45: jiang.qian commented

---

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.