xpra thinks the window is not visible, so maximizing and other things won't work

[totaam]

Issue migrated from trac ticket # 48

component: android | priority: major | resolution: fixed

2011-11-25 17:53:16: totaam created the issue

---

This bug was originally recorded as #35 and although the symptoms are somewhat similar, this particular issue manifests itself differently: no need for scrolling pages, simply maximizing the window sitting at the front is enough to show this in the server log:

resize_window to 1590x1019, desktop manager set it to 1590x1019, visible=False

Which is obviously wrong as the window IS visible.

This looks exactly like winswitch bug 163: "Maximizing does not work correctly".

Please record your local window manager and anything which may be relevant to this bug. Are you using ssh to connect to the server? Are you using ssh -X from the server to somewhere else? Can you reproduce it without? etc
Does this happen with vi or just any window?

[totaam]

2011-11-25 17:57:02: totaam changed status from new to accepted

[totaam]

2011-11-25 17:57:02: totaam changed owner from antoine to totaam

[totaam]

2011-11-25 17:57:02: totaam commented

---

Details from winswitch #163, the problem can be seen using:

Distributor ID: Ubuntu
Description: Ubuntu 11.04
Release: 11.04
Codename: natty
Gnome 2.32.1 

Natty using Gnome instead of Unity, Compiz enabled.

[totaam]

2011-11-25 18:09:03: ddoole commented

---

Also seen using KDE under Ubuntu 11.04. I tried disabling desktop effects, and that didn't seem to make a difference.

[totaam]

2011-11-27 14:05:34: totaam commented

---

Good news is that this is 100% reproducible within a VM.
I just hope this is not another Ubuntu "feature", but I have yet to reproduce this on any other desktop environment...

Here's what other clients do when you maximize an xpra window that is already visible:

configure_window: <WindowModel object at 0x1a708c0 (wimpiggy+window+WindowModel at 0x17a4b00)>
Uh-oh, our size doesn't fit window sizing constraints: 2560x1551 vs 2553x1536
configure_window: <WindowModel object at 0x1a708c0 (wimpiggy+window+WindowModel at 0x17a4b00)>
visible(<WindowModel object at 0x1a708c0 (wimpiggy+window+WindowModel at 0x17a4b00)>)=True
resize_window to 2560x1551, desktop manager set it to 2560x1551, visible=True
visible(<WindowModel object at 0x1a708c0 (wimpiggy+window+WindowModel at 0x17a4b00)>)=True
raise_window(<WindowModel object at 0x1a708c0 (wimpiggy+window+WindowModel at 0x17a4b00)>)
visible(<WindowModel object at 0x1a708c0 (wimpiggy+window+WindowModel at 0x17a4b00)>)=True
(...)

Ubuntu does this:

visible(<WindowModel object at 0x2320280 (wimpiggy+window+WindowModel at 0x235a220)>)=False
hide_window: <WindowModel object at 0x2320280 (wimpiggy+window+WindowModel at 0x235a220)>
unmap_window requested by client
configure_window: <WindowModel object at 0x2320280 (wimpiggy+window+WindowModel at 0x235a220)>
configure_window: <WindowModel object at 0x2320280 (wimpiggy+window+WindowModel at 0x235a220)>
visible(<WindowModel object at 0x2320280 (wimpiggy+window+WindowModel at 0x235a220)>)=True
resize_window to 951x592, desktop manager set it to 951x592, visible=True
wtf, pixmap is None?
raise_window(<WindowModel object at 0x2320280 (wimpiggy+window+WindowModel at 0x235a220)>)

It is unmapping the window before resizing it... which breaks everything.
At this point, the visible flag is no longer relevant.
Now I need to figure out why the window is unmapped, and prevent it, somehow.

[totaam]

2011-11-27 16:39:54: totaam changed status from accepted to closed

[totaam]

2011-11-27 16:39:54: totaam changed resolution from ** to fixed

[totaam]

2011-11-27 16:39:54: totaam commented

---

fixed in r313
I would have preferred to find a fix client side since this is where the weird "unmap-event" is coming from as this would avoid potentially affecting clients that do not behave oddly, but this can only be fixed afterwards and therefore server side. Seems safe enough.

[totaam]

2011-11-30 16:38:21: ddoole commented

---

I confirmed that things work well on r313 on my system. Thanks for the fix.