resizing a maximized window yield strange results

[totaam]

Issue migrated from trac ticket # 107

component: platforms | priority: major | resolution: fixed

2012-04-12 17:51:33: ahuillet created the issue

---

Hello,

when trying to resize a maximized window, the actual window on win32 doesn't change, but it seems that the application window is resized.

See attached screenshot.

[totaam]

2012-04-12 17:51:49: ahuillet uploaded file Image1.jpg (350.3 KiB)

[totaam]

2012-04-12 17:52:16: ahuillet changed component from android to platforms

[totaam]

2012-05-04 11:04:41: antoine changed status from new to assigned

[totaam]

2012-05-04 11:04:41: antoine changed owner from antoine to ahuillet

[totaam]

2012-05-04 11:04:41: antoine commented

---

Looks like gtk thinks that we are resizing the window, but win32 does not allow it?
Do you have any debug log from the client and server doing this? Does this happen with any app or just this one?

[totaam]

2012-05-04 11:16:05: ahuillet commented

---

Debug log? What do you need exactly?

[totaam]

2012-05-04 11:17:08: antoine commented

---

Anything related to window dimensions? Any clue in there? (and is it specific to one app, or many, etc..)

[totaam]

2012-06-08 08:53:52: ahuillet commented

---

You can reproduce the issue easily.

Start a Xpra server and start Paraview (it needs OpenGL to run, so "vglrun paraview" is usually needed).
Connect to the server with the windows client.

Maximize the window. Try to resize it. See what happens.

[totaam]

2012-06-10 07:47:14: antoine changed status from assigned to accepted

[totaam]

2012-06-10 07:47:14: antoine changed owner from ahuillet to antoine

[totaam]

2012-06-10 07:47:14: antoine commented

---

100% reproducible, no need for vglrun or win32, works with xdummy.

Looks like the client and server disagree on whether the window is resizable, so we end up resizing the server window but not the client window... which leaves junk pixels in between.

[totaam]

2012-06-10 07:47:14: antoine

[totaam]

2012-06-10 07:48:32: antoine changed title from win32: Resizing a maximized window yield strange results to resizing a maximized window yield strange results

[totaam]

2012-06-10 10:27:37: ahuillet commented

---

I assume you mean the opposite: we're resizing the client window but not the server's?

[totaam]

2012-06-10 10:58:02: antoine commented

---

No, just like I said above. More details below.

(this with lxde/openbox - maybe other window managers do things differently)
I can resize the window horizontally OR vertically, and everything resizes correctly (on the fly too). It only goes wrong when I resize both dimensions in one go.

I believe that's because the resizing is done by the application itself and not the window manager: there are no "do_configure_event"s firing. The widget in the window's bottom-right corner does not belong to the client's window manager.
Whatever the application is doing, it should be telling us (the server) that it is resizing itself, why are we not seeing that?

[totaam]

2012-06-10 11:01:12: antoine commented

---

In fact, everything works fine if you manage to use your client's window manager to do the resizing and not the application's widget. For openbox, that means grabbing the thin outer edge of the window. You can see the change to the window's widget because the cursor also changes (the app uses a "double arrow", my local window manager uses a "corner with arrow pointing to it").

[totaam]

2012-06-10 11:35:51: antoine commented

---

I can see the resize events in x_event_filter:

ConfigureNotify 22 event received: (0, 0, 1769, 1004)
ConfigureNotify 22 event received: (0, 0, 1699, 925)
ConfigureNotify 22 event received: (0, 0, 1683, 910)
ConfigureNotify 22 event received: (0, 0, 1679, 907)
ConfigureNotify 22 event received: (0, 0, 1674, 903)
ConfigureNotify 22 event received: (0, 0, 1626, 861)

But this never reaches anywhere in xpra's window event handlers!?

On the subject of move/resize, I found this in the ewmh spec:

	Window Managers should treat a _NET_MOVERESIZE_WINDOW message exactly 
	like a ConfigureRequest (in particular, adhering to the ICCCM rules
	about synthetic ConfigureNotify events), except that they should use
	the gravity specified in the message. 

	Rationale: Using a _NET_MOVERESIZE_WINDOW message with StaticGravity
	allows Pagers to exactly position and resize a window including its 
	decorations without knowing the size of the decorations.

Which we do not handle at present... needs adding.

[totaam]

2012-06-10 12:50:56: antoine commented

---

Looks like the app is sending the resize (ConfigureNotify event) to the wrong window.

So the "right" fix is to fix the app, I am now looking at finding a workaround by catching resize events sent to the "composite helper" and forwarding those to the correct window. That's a bit of a hack though, and might cause further problems with apps that do not misbehave... And so far, all I've managed to do is to prevent the client window from resizing the composite window it does not own (which is probably better behaviour than what we have now)

[totaam]

2012-06-10 17:59:10: antoine commented

---

# The purpose of the 'corral' is to keep the client window managed -- we
# select for SubstructureRedirect on it, so that the client cannot resize
# etc. without going through the WM.

Well..

composite_configure_event(..) event.geometry: (0, 0, 1473, 687)
composite_configure_event(..) corral_window: (2, 23, 2039, 1164, 24)
composite_configure_event(..) client_window: (0, 0, 1473, 687, 24)

Maybe we need ResizeRedirect too?

Anyway, I was completely wrong about the size handling: we just don't handle client (as in X11 client) side window resizing at all, which is the problem.
See r912 for a simple test app which shows the problem much more simply than paraview.

The solution is not simple: if we pass the new window dimensions (and position whilst we are at it) to the client, we risk creating loops.

[totaam]

2012-06-22 10:01:46: antoine uploaded file xpra-windowresize.patch (20.3 KiB)

work in progress patch, definitely not ready for merging, but should work

[totaam]

2012-06-22 10:09:02: antoine commented

---

The patch above fixes the issue, but may well introduce new ones... Like loops where the client and the server keep resizing the windows to match their own sizing constraints... Will need thorough testing (and test apps) on all platforms, and the wimpiggy bits are probably misnamed (need cleaning up)

[totaam]

2012-07-12 10:54:20: antoine commented

---

cleaner version of the patch merged in r1089

I haven't encountered any loops yet... but if there are some, we should be able to do something about it:

• either ignore configure events firing from our own resize() call (assuming that they will fire straight away so we can clear the flag/embargo with a simple idle_add call - after checking that the size is not too far out, and if it is.. ??)
• or.. accept whatever the client ends up configuring?

[totaam]

2012-07-20 06:07:29: antoine changed status from accepted to closed

[totaam]

2012-07-20 06:07:29: antoine changed resolution from ** to fixed

[totaam]

2014-12-30 11:33:26: totaam commented

---

Note: see #765 for _NET_MOVERESIZE_WINDOW