Xpra: Ticket #107: resizing a maximized window yield strange results


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.

Thu, 12 Apr 2012 16:51:48 GMT - ahuillet: attachment set

Thu, 12 Apr 2012 16:52:15 GMT - ahuillet: component changed

Fri, 04 May 2012 10:04:40 GMT - Antoine Martin: owner, status changed

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?

Fri, 04 May 2012 10:16:04 GMT - ahuillet:

Debug log? What do you need exactly?

Fri, 04 May 2012 10:17:07 GMT - Antoine Martin:

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

Fri, 08 Jun 2012 07:53:51 GMT - ahuillet:

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.

Sun, 10 Jun 2012 06:47:14 GMT - Antoine Martin: owner, status changed

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.

Sun, 10 Jun 2012 06:48:31 GMT - Antoine Martin: summary changed

Sun, 10 Jun 2012 09:27:36 GMT - ahuillet:

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

Sun, 10 Jun 2012 09:58:01 GMT - Antoine Martin:

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?

Sun, 10 Jun 2012 10:01:11 GMT - Antoine Martin:

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").

Sun, 10 Jun 2012 10:35:51 GMT - Antoine Martin:

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.

Sun, 10 Jun 2012 11:50:56 GMT - Antoine Martin:

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)

Sun, 10 Jun 2012 16:59:09 GMT - Antoine Martin:

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


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.

Fri, 22 Jun 2012 09:01:45 GMT - Antoine Martin: attachment set

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

Fri, 22 Jun 2012 09:09:02 GMT - Antoine Martin:

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)

Thu, 12 Jul 2012 09:54:19 GMT - Antoine Martin:

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:

Fri, 20 Jul 2012 05:07:29 GMT - Antoine Martin: status changed; resolution set

Tue, 30 Dec 2014 11:33:25 GMT - Antoine Martin:

Note: see #765 for _NET_MOVERESIZE_WINDOW

Sat, 23 Jan 2021 04:45:44 GMT - migration script:

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