Xpra: Ticket #1377: gvim sometimes has a very small window

Split from ticket:41#comment:34

I have seen a regression (between 0.15 and ~1.0somewhere) with gvim where the window tries to size 1 line (of text) high. I assume that there's an issue with the height feedback.

I've tested this with sharing enabled, but only 1 client connected.

Sometimes when I start gvim it will open slightly smaller than expected. If I try and resize the window, it very quickly becomes 1 text line high. It seems that something is fighting with vim to resize the window.

At r14449 it would fight with itself and the window would be small without user interaction, at r14490 it requires user interaction to keep getting smaller.

Other times it opens fine, and even if I resize it, there are no problems.

One correlation I've noticed is that when the gvim window is initially positioned at the top of the screen, it's broken; but when it defaults to the bottom it works correctly. If it opens in broken mode and I 'enable' tabs in vim with :tabnew (I assume causing the server window to resize), then it starts working as expected.

I have only been able to test at r14490 (trusty), but it does not look related to r14496 (because the OR related error does not appear).

Is there a way to increase logging while the server is running?

Wed, 07 Dec 2016 20:59:10 GMT - alas:

You should be able to increase logging while server is running with the control channel.

Basic syntax... xpra control [:DISPLAY] debug enable [debug flag].

The 'help' option will give a list of debugging options supported (as well as a number of other functions that you can control with the control channel).

You can also launch d-feet from an in-session xterm to use the dbus interface, if you prefer (some details in #904).

I'd also be curious to know if you might have desktop-scaling kicking in in the cases where you're having sizing issues (depending on your desktop/display sizes, it can kick in with auto scaling values, discussed some in #1101, unless you're using the --desktop-scaling=1 or =off client side flag) - because I was seeing something that sounds similar when using desktop-scaling of odd values with my xterms (#1098).

In either case, hope that helps a bit.

Wed, 01 Feb 2017 00:52:03 GMT - Norman Rasmussen: attachment set

Wed, 01 Feb 2017 01:00:19 GMT - Norman Rasmussen:

Added a log from debugging with 1.0.2-r14909

If I 'enable debugging all' before opening gvim, then I can not reproduce the error. With debugging at it's default (disable), I can get gvim to open in the broken state (50% of the time - depending on if it opens at screen top (broken) or bottom (working)). The log is from right after gvim window opens:

16:46:17 I try to make it bigger, but xpra fights with me making it smaller 16:46:22 I then :tabnew and :q (to close the new tab) in gvim 16:46:28 I resize the window, this time is successful.

The fact that having debugging enabled causes gvim to open successfully makes me think it's a race condition.

Thu, 09 Feb 2017 07:57:27 GMT - Antoine Martin: owner, version, description changed; milestone set

Here's an extract from the log which shows the resizing loop:

resize_corral_window() new constrained size=1100x328
do_child_configure_request_event(<X11:ConfigureRequest \
    {'delivered_to': '0x1a0068b', 'send_event': 0, 'type': 23, 'detail': 0, 'height': 314, 'width': 1100, \
     'window': '0x200003', 'above': 0L, 'y': 0, 'x': 0, 'serial': '0x1684c', 'border_width': 0, 'value_mask': 12L, \
     'display': <gtk.gdk.DisplayX11 object at 0x7f177fd1fd70 (GdkDisplayX11 at 0x29c5020)> \
    }>) client=0x200003, corral=0x1a0068b, value_mask=Width|Height
updateprop(requested-size, (1100, 314)) previous value=(1100, 332)
updateprop(geometry, (1, 53, 1100, 310)) previous value=(1, 53, 1100, 328)
XpraServer._window_resized_signaled(WindowModel(0x200003),(<GParamBoxed 'geometry'>,)) geometry=(1, 53, 1100, 310), desktop manager geometry=[1, 53, 1100, 328]
do_child_configure_request_event updated requested geometry from (1, 53, 1100, 328) to  (1, 53, 1100, 310)
WindowModel.do_xpra_configure_event(<X11:ConfigureNotify \
    {'delivered_to': '0x200003', 'send_event': 0, 'height': 310, 'width': 1100, 'window': '0x200003', 'above': 0L, \
     'y': 53, 'x': 1, 'serial': '0x1684f', 'border_width': 0, 'type': 22, \
     'display': <gtk.gdk.DisplayX11 object at 0x7f177fd1fd70 (GdkDisplayX11 at 0x29c5020)> \
    }>) corral=0x1a0068b, client=0x200003, managed=True
resize_corral_window() new constrained size=1100x310
resize_corral_window() move and resize from (1, 53, 1100, 328) to (1, 53, 1100, 310)
updateprop(geometry, (1, 53, 1100, 310)) unchanged

So it looks to me like gvim might be requesting sizes that don't agree with the size constraints that it has requested, then we round the height down and resize the window to that value, in response gvim resizes down... and the loop continues.

Please post the output of xpra info | grep -i size-constraints when the gvim window is shown and having this problem.

I have tried to reproduce the problem but no matter how I launch gvim, it always resizes properly. The size-constraints that I see are:

base-size=(20, 4)
increment=(8, 17)
minimum-size=(116, 38)

Your values are likely to be different since the resizing in the log sample rounds to 18 or more vertically.

If we find that applications are requesting invalid sizes that cannot be satisfied whilst honouring the size-hints, we could just disable the size hints with a warning.

Fri, 10 Mar 2017 13:58:31 GMT - Antoine Martin:

2.0 development is closed and I cannot reproduce this in a trusty vm. Unless you can provide more information as per comment:3, I will have to close this as "needinfo".

Sat, 11 Mar 2017 00:51:40 GMT - Norman Rasmussen:

new window with resizing issue:

window.1.size-constraints.base-size=(20, 4)
window.1.size-constraints.increment=(9, 18)
window.1.size-constraints.minimum-size=(128, 40)

after I have :tabnew'ed

window.1.size-constraints.base-size=(20, 90)
window.1.size-constraints.increment=(9, 18)
window.1.size-constraints.minimum-size=(128, 126)

after closing the tab:

window.1.size-constraints.base-size=(20, 62)
window.1.size-constraints.increment=(9, 18)
window.1.size-constraints.minimum-size=(128, 98)

fresh window that didn't have the issue:

window.9.size-constraints.base-size=(20, 62)
window.9.size-constraints.increment=(9, 18)
window.9.size-constraints.minimum-size=(128, 98)

if I open a new tab:

window.9.size-constraints.base-size=(20, 90)
window.9.size-constraints.increment=(9, 18)
window.9.size-constraints.minimum-size=(128, 126)

I looked for other interesting diffs, but didn't find anything that looked obvious (obviously geometry and mapped location changes).

Could this be due to a mismatch between the client and server window decorations?

Sat, 11 Mar 2017 01:03:50 GMT - Norman Rasmussen:

btw, I also tried "/usr/bin/gvim -u NONE -U NONE" to make sure I was bypassing all shell aliases, and vimrc files, and it doesn't seem to make a difference to the resizing behavior.

Sat, 11 Mar 2017 04:09:08 GMT - Antoine Martin:

The values look fine. There are no decorations server side for regular windows.

The dimensions and constraints are always for the inner dimensions of the window.

To see the dimensions of the window frame client side, use:

xpra info | grep frame=

Fri, 19 May 2017 16:36:35 GMT - rektide:

I'm seeing this issue too. Gvim will lose like 3-5 line-heights a second, shrinking until it's a single line of text & the toolbars only.

Fri, 19 May 2017 16:40:35 GMT - rektide: cc set

Fri, 19 May 2017 16:40:46 GMT - rektide: milestone changed

Fri, 19 May 2017 16:44:17 GMT - Antoine Martin:

@rektide: I have been unable to reproduce this bug, if you have reliable steps, please post them.

Sat, 20 May 2017 02:46:34 GMT - rektide:

I'm running Debian/testing with the awesome wm on the client (and nothing on the xpra session). Awesome can be flakey sometimes, but switching to a "float" (non-tiling) layout for the virtual-desktop usually makes most situations calm down (as awesome, I believe, no longer makes any attempt to manage geometry outside a manually issued resize). In this case though, gvim still continues to retract.

I feel like I may need to ask #vim for debugging steps to find out what is making it want to shrink- hopefully gvim itself has some indicators why it is doing what it is doing. It seems like there's some good logs others have done for xpra? I'm happy to contribute whatever I can to debug, but it seems like that looking at xpra debug logs didn't reveal anything last time? I can re-do that though if it could help.

Thanks for the mention Antoine. This is literally my no 1 use case- to be able to bring up programming environments easily from whatever terminal I'm on- and I'd love to make xpra happen.

Would the xpra proxy have any chance of affecting this situation? I think in some cases (but I don't think all, but I'm not sure) I was going through a system-wide xpra proxy that Debian was running.

Sun, 16 Jul 2017 14:11:06 GMT - Antoine Martin: owner changed

This really does look like a gvim bug to me. Maybe r16371 will help? It will honour the application's resize request, even when that request does not satisfy the size-hints that the application had set. (I expect that some client-side window managers may still enforce the size hints and cause the resizing loop, via the client this time)

For xpra, the logs that show the relevant bits require the "-d geometry" command line switch.

I very much doubt that the proxy can interfere with this, as it doesn't modify the geometry packets. If you can reproduce this bug (I cannot), then please include the log together with the "size-constraints" info (as per comment:5).

Mon, 17 Jul 2017 19:13:33 GMT - Norman Rasmussen:

(fyi: I am out-of-office for the next 6 weeks, so I won't be able to verify that r16371 helps till late august)

Tue, 22 Aug 2017 19:10:40 GMT - Norman Rasmussen:

I tried with v1.0.7-r16697 (latest version available for Trusty), but it looks like that doesn't have the fix.

Wed, 23 Aug 2017 05:16:08 GMT - Antoine Martin:

That fix is only in 2.1 and later, and it isn't enabled by default either. You should be able to apply it by hand to the v1.x branch.

Wed, 23 Aug 2017 21:35:22 GMT - Norman Rasmussen:

I applied r16371 manually, and it looks like it helps a fair bit. When the gvim window opens at the bottom of the screen, then I can see that the bottom 15px of the window are grey. If I resize the window, then I can get it into a state where the contents of the window are drawn too low, and the alignment between pointer events on the client and server seem to be offset. The menus at the top of the window also appear to be drawn twice (18px between each copy). (As before if I :newtab in gvim to force the tabstrip to appear, then everything goes back to normal).

I do have a bottom window list panel (27px high I think), if that maybe affects this? I'm thinking it only breaks when the initial window geometry is +0-0?

Fri, 08 Sep 2017 10:37:15 GMT - Antoine Martin:

Do you use an unusual window manager or something?

Wed, 25 Oct 2017 17:33:45 GMT - Antoine Martin:

Please try the latest 2.2 beta, which have fixes related to offsets and window placement. Unless I can reproduce this bug, I will have to close as "needinfo".

Wed, 25 Oct 2017 20:29:30 GMT - Norman Rasmussen:

I only have Ubuntu Trusty 14.04 to test with at the moment, so the latest version I can try is 1.0.9-r17247-1.

I use cinnamon with a panel at the bottom of the screen (with the window list applet)

I will be upgrading to Debian testing in the next few months, so I should be able to try whatever is beta then.

Sun, 22 Apr 2018 06:34:17 GMT - Antoine Martin: status changed; resolution set

Sat, 23 Jan 2021 05:22:34 GMT - migration script:

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