GNOME Bugzilla – Bug 732588
Window shrinks at tab title change
Last modified: 2018-04-15 00:15:44 UTC
From bug 685507 comment 37 and onwards: Open at least 2 tabs, then execute this for i in {1..10}; do echo -ne '\e]0;䈀\a' sleep 0.1 echo -ne '\e]0;x\a' sleep 0.1 done The window shrinks crazily. When placing a character whose ascent/descent is higher than some default, the tab bar itself becomes smaller. This in turn, in order to obey the new grid rules, causes the window to shrink. I guess we need to re-compute the style/size/grid/wmhint/idontknowwhat on tab title change.
tab bar itself becomes *taller
Created attachment 281504 [details] [review] fix Here's a fix. I don't like the terminal-tab-label -> terminal-window dependency but I'm afraid we need this.
The steps from comment 0 don't repro here. Also I don't understand how this could happen. Title changes so that the tab label becomes larger, fine. This will lead to a new size request/allocation cycle for the window, which should take the (unchanged) grid size still from the terminal. In case the window cannot expand because it's already fully using the vertical space, the terminal will get a smaller by 1 row. No cyclical shrinking should be possible…
> The steps from comment 0 don't repro here. Try with a different theme that has a smaller tab bar. (I'm using Ambiance, Ubuntu's default.) > Also I don't understand how this could happen. [...] Well, it does happen. (I agree with you that it couldn't/shouldn't happen, but it does.) The code that updates the window size to reflect the old vte size + new chrome size is not executed. So the WM size stays the same, forcing vte to shrink, which it does, and then it kicks back asking the WM for the new (smaller) size and geom hints. At least that's what I think happens. The window size is nowhere near full screen. (For almost full height windows the shrinking you described would be reasonable.)
http://youtu.be/KOPWs6hGZ6Q
Comment on attachment 281504 [details] [review] fix Committed (with a bit more verbose FIXME comment).
IMO this is a problem in gtk's handling of the geometry. -> gtk+
For reference: the workaround is committed as https://git.gnome.org/browse/gnome-terminal/commit/?id=a2a89b2 The bug can be observed with g-t <= 3.14.x, or with git revert a2a89b2.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new