xpra icon
Bug tracker and wiki

Opened 10 months ago

Last modified 2 weeks ago

#1377 new defect

gvim sometimes has a very small window

Reported by: Norman Rasmussen Owned by: rektide
Priority: major Milestone: 2.1
Component: server Version: 1.0.x
Keywords: Cc: rektide@…

Description (last modified by Antoine Martin)

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?

Attachments (1)

shrink-3.txt.gz (90.6 KB) - added by Norman Rasmussen 8 months ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 10 months ago by 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.

Changed 8 months ago by Norman Rasmussen

Attachment: shrink-3.txt.gz added

comment:2 Changed 8 months ago by 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.

comment:3 Changed 8 months ago by Antoine Martin

Description: modified (diff)
Milestone: 2.0
Owner: changed from Antoine Martin to Norman Rasmussen
Version: trunk1.0.x

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.

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 7 months ago by 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".

comment:5 Changed 7 months ago by 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?

Last edited 7 months ago by Antoine Martin (previous) (diff)

comment:6 Changed 7 months ago by 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.

comment:7 Changed 7 months ago by 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=

comment:8 Changed 4 months ago by 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.

comment:9 Changed 4 months ago by rektide

Cc: rektide@… added

comment:10 Changed 4 months ago by rektide

Milestone: 2.02.1

comment:11 Changed 4 months ago by Antoine Martin

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

comment:12 Changed 4 months ago by 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.

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:13 Changed 2 months ago by Antoine Martin

Owner: changed from Norman Rasmussen to rektide

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

comment:14 Changed 2 months ago by 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)

comment:15 Changed 5 weeks ago by Norman Rasmussen

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

comment:16 Changed 5 weeks ago by Antoine Martin

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

comment:17 Changed 5 weeks ago by 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?

comment:18 Changed 2 weeks ago by Antoine Martin

Do you use an unusual window manager or something?

Note: See TracTickets for help on using tickets.