GNOME Bugzilla – Bug 782863
gtk+-3.22.15: resizing gnome-terminal window via top border makes it grow at the bottom
Last modified: 2021-06-10 21:16:00 UTC
(I have been having this problem for a couple of GNOME releases now) - open a gnome-terminal window - resize the window by clicking on the top border and moving it up and down semi-violently => sometimes the bottom border moves down. when this happens, the top border is no longer aligned with the mouse cursor Pretty crappy description of the problem, but baedert on #gtk+ confirmed almost immediately (though slightly different experiment using gtk3-widget-factory)
Created attachment 352222 [details] Screencast
I can reproduce with gnome-shell (which is the one you seem to be using in the screencast), but not with ubuntu zesty's unity7. With unity7, something of the terminal's background color does sometimes flash up for a fraction of a second under the bottom edge, but it's never permanent, and apart from this intermittent artifact the behavior is as desired. Probably a gnome-shell bug, or a weird constellation of issues in gnome-shell, gtk+ and gnome-terminal.
I would just like to add that, in case it wasn't clear, gnome-terminal is the only application that I have this problem with, so it's probably related to the geometry/window hints (discrete window size)
Some version upsteps later, I do not seem to have the problem anymore: gtk+-3.22.17 gnome-shell-3.24.3 gnome-terminal-3.24.2 If considered useful, I willing to do some upgrades/downgrades experiments to get more information.
Still reproducible when using gnome-terminal 3.26 and vte 0.50 / vte git master? There's been some fixes recently there.
I can still reproduce kind of the same issue on Artful + vte/g-t master. This time the bottom of the window keeps going upwards, rather than downwards as in the original report. This happens in GNOME Shell, both on X11 and Wayland. Still doesn't happen in Unity 7.
(With all these geometry problems we keep having, like this one, bug 751064, bug 788334, bug 756024 and probably a few more, I'm thinking that probably we should test on old-fashioned window managers: twm, fvwm, icewm, wmaker etc. and if it's fine there then just blame the WM.)
The same issue occurs in GNOME Shell with urxvt; although not with xterm, pterm, terminology, st.
vtegtk.cc contains the public methods vte_terminal_get_geometry_hints() and vte_terminal_set_geometry_hints_for_window() which are not used by gnome-terminal, nor the new test app. What's the reason for that?
Because they don't work right anymore, and really can't since you need to update the window geometry at all these places as seen in g-t and the test app... I'll deprecate them.
I'm playing with the new test app now. Note that it works correctly, apart from a slight inconsistency around the smallest allowed size: usually I can't shrink it to shorter than 4 lines, but occasionally I can go down to 3 (although according to the source code it should be 2). But at least the bottom edge doesn't wander. The test app "./src/app/vte-2.91 -v" prints: Updating geometry hints base 66x101 inc 9x18 min 210x137 Cached grid 80x24 char-size 9x18 chrome 14x2 csd 52x99 VteappWindow resize grid 80x24 pixel 734x434 and then "xprop WM_NORMAL_HINTS" reports back: program specified minimum size: 347 by 145 program specified resize increment: 9 by 18 program specified base size: 66 by 101 - The CSD size, and in turn the base size is terribly wrong. CSD's height is about 50 pixels, and width is 0. - As such, I have no idea how the window resizing experience (including the window size as reported back by GNOME Shell during resize) can be correct, but it's correct. How can it be? - Who/why/where increases the minimum size? It's probably GTK+. - With gnome-terminal, the minimum width also seems to be extended to a certain larger minimum, to accomodate for the menu bar and/or notebook bar widgets' required minimum. - As a result, in both the testapp and g-t, the minimum size is not a grid-aligned size. This causes weird behavior even in Unity when the minimum width is reached. My experiments so far couldn't confirm that this has anything to do with the bug we're talking about, but it's possible, let's keep in mind! (In case it's related, is there anything we could do to avoid GTK+ tampering with the minimum size, or at least make sure the minimum size is an aligned one?) So now let's see gnome-terminal, what does xprop say? No menu bar and no tab bar gives: program specified minimum size: 50 by 46 program specified resize increment: 9 by 18 program specified base size: 14 by 2 Adding the menu bar and/or tab bar maintains the difference of 44 between the base and minimum height, which is probably 2*18 for the minimum 2 rows, plus 8 for what??
(In reply to Christian Persch from comment #10) > I'll deprecate them. Thanks!
(In reply to Egmont Koblinger from comment #11) > - As such, I have no idea how the window resizing experience (including the > window size as reported back by GNOME Shell during resize) can be correct, > but it's correct. How can it be? > > - Who/why/where increases the minimum size? It's probably GTK+. AFAIK there's invisible space around all sides of the window added in CSD mode, containing the shadow (even if not drawn) and also for the resize events (notice the mouse cursor changes already when not yet on the actual visible border). > - With gnome-terminal, the minimum width also seems to be extended to a > certain larger minimum, to accomodate for the menu bar and/or notebook bar > widgets' required minimum. > > - As a result, in both the testapp and g-t, the minimum size is not a > grid-aligned size. This causes weird behavior even in Unity when the minimum > width is reached. My experiments so far couldn't confirm that this has > anything to do with the bug we're talking about, but it's possible, let's > keep in mind! (In case it's related, is there anything we could do to avoid > GTK+ tampering with the minimum size, or at least make sure the minimum size > is an aligned one?) Don't know :-(
(In reply to Christian Persch from comment #13) > AFAIK there's invisible space around all sides of the window added in CSD Makes sense, thanks for the explanation! I'll try to see if the non-aligned minimum size is related to the bug.
(In reply to Egmont Koblinger from comment #11) > program specified minimum size: 50 by 46 > program specified resize increment: 9 by 18 > program specified base size: 14 by 2 > > Adding the menu bar and/or tab bar maintains the difference of 44 between > the base and minimum height, which is probably 2*18 for the minimum 2 rows, > plus 8 for what?? Well, nope... Changing the font size leaves the difference at 44. So it's not a magic 8, but a magic 44 (for me) from somewhere. It's actually the scrollbar enforcing this minimum height. If I disable the scrollbar, this limitation is gone. (It could have occurred to me sooner; it's the same story as with the menu and tab bars I mentioned earlier.) If I either disable the scrollbar, or choose a font of 22px or 44px or bigger height so that the minimum size happens to be an aligned one, the bug we're investigating is still present. So non-aligned minimum size is irrelevant.
A few hours ago the bottom of the window kept going upwards. It's going downwards again. Plus, even if I resize the window horizontally (using either side) then it also grows sometimes. If I execute "cat" then the problem is gone. In Ubuntu's default setup, PS1 sets the window title. It does not source vte-2.91.sh (at least by default, for non-login shells) which would add setting the title to PROMPT_COMMAND (the much debated feature, but it's irrelevant now). Upon a resize, bash-4.4 does not re-execute PROMPT_COMMAND, nor $(...) stuff in PS1, but reprints PS1. Which means that the window title is set over and over again to the same value upon resize. (Probably that's also what bash-4.2 and earlier did. 4.3 had a bug that it didn't immediately react on resize, only on a subsequent keypress.) There's probably a race condition in gnome-shell, maybe the title is wiped out for a fraction of a second causing the height of the titlebar to shrink and then it immediately grows back to the desired height, or something along these lines. (I've just double checked that this temporary wipe out is not done by gnome-terminal) On one hand, this should be forwarded to gnome-shell so that they fix it. On the other hand, VTE could remember the previous title and only emit title-changed if it indeed changed.
Created attachment 362028 [details] [review] vte: change title only if really changes
The boolean logic in this patch is already quite complicated (at 1:30am), I don't want to further complicate it. It is still possible for gnome-terminal to receive a title-changed event whereas the title didn't change. But it only occurs if it's quickly toggled back and forth by escape sequences, and the intermediate value wasn't emitted yet. I guess it's okay. Or should the equality comparison be moved to vte.c emit_pending_signals()? Note to self: Don't write quick patches at 1:30am :D
Created attachment 362029 [details] [review] vte: change title (and uris) only if really changes, v2 I think I like this approach better. The code is more readable and more robust (we don't have to pay attention to two possible cases: slow and fast title changes (fast meaning that we haven't emitted the signal yet and another one arrives)).
These patches are not proper fixes (the bug is most likely in GNOME Shell). They just workaround the problem in a special constellation. With Ubuntu's default settings, changing the window size causes the title to be set again to the same value. Due to some race condition, in case of quick resizing, I believe that the title changed triggered by a window resize step happens at the same time as a subsequent window resize step, and this somehow confuses the window manager. Even with this workaround, the bug can be reproduced if the title really changes during resize, e.g. something like this is running: while true; do echo -ne "\e]0;$(date +%N)\a"; done Interestingly, with the terminal emulators I've menntioned above that do not suffer from this bug (xterm, pterm, terminology, st), I couldn't trigger the bug with this previous snippet either. I don't understand this, I expected the bug to show up. So probably VTE still does something differently than those apps. I'm not going to further investigate this.
Comment on attachment 362029 [details] [review] vte: change title (and uris) only if really changes, v2 Thanks :-)
Playing a little bit more, it looks like we've hit 4 different bugs (VTE missing an optimization is not a bug). I didn't notice earlier that the behavior (shrinkage/growth) was in fact quite different in X11 and Wayland; and didn't notice it was different in gnome-terminal and urxvt. So, in GNOME Shell, the bugs when resizing by the top edge are: (1) X11 only: When VTE changes the title (possibly to the same value) at the same time as a window resize is made, the window becomes 1 cell taller (the bottom jumps downwards). (2) Wayland only: If the minimum height isn't an aligned height, when hitting the minimum height the bottom of the window jumps upwards. (Same story horizontally: When resizing by the left edge, upon hitting the unaligned minimum width the right edge moves to the left.) (Doesn't occur with xterm, pterm etc., _perhaps_ due to them using some X11-compat layer whereas gnome-terminal goes native Wayland??) (3) Wayland only: When the mouse is released, the window jumps upwards so that its top is at the mouse position. (Same story horizontally: When resizing by the left edge and releasing the mouse, the entire window jumps a bit to the left.) (Doesn't occur with xterm etc., perhaps [see above].) (4) Both X11 and Wayland: Vertically resizing urxvt causes the window to noticeably move upwards in each and every resize step. (Could be a bug in urxvt, but I haven't seen this behavior in other WMs.) The current VTE patch is a limited workaround (full workaround for Ubuntu's default setup) for (1) only. I'm just reading up on Wikipedia what GNOME Shell is and isn't. Probably (1) is a bug in Mutter (should I have a "mutter" process running then? because I don't) and (2-3) are in the Wayland Compositor (how to figure out which compositor is being used? probably also Mutter?). Clueless about (4). Christian, do you know more about this architecture? Do you know where to assign these bugs? Or GNOME Shell is a safe bet for each and they'll reassign/forward as appropriate? Also, out of curiosity, which of the 4 bugs above can you reproduce on Fedora?
Just assign to gnome-shell and the maints will move as appropriate. Haven't ever seen these bugs on g-s on fedora (am currently on F25).
Comment on attachment 362029 [details] [review] vte: change title (and uris) only if really changes, v2 VTE workaround submitted.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7747.