After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732588 - Window shrinks at tab title change
Window shrinks at tab title change
Product: gtk+
Classification: Platform
Component: .General
Other Linux
: Normal minor
: ---
Assigned To: gtk-bugs
Depends on:
Reported: 2014-07-01 22:05 UTC by Egmont Koblinger
Modified: 2018-04-15 00:15 UTC
See Also:
GNOME target: ---
GNOME version: ---

fix (2.46 KB, patch)
2014-07-23 19:53 UTC, Egmont Koblinger
committed Details | Review

Description Egmont Koblinger 2014-07-01 22:05:48 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

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.
Comment 1 Egmont Koblinger 2014-07-01 22:07:36 UTC
tab bar itself becomes *taller
Comment 2 Egmont Koblinger 2014-07-23 19:53:36 UTC
Created attachment 281504 [details] [review]

Here's a fix.

I don't like the terminal-tab-label -> terminal-window dependency but I'm afraid we need this.
Comment 3 Christian Persch 2014-08-16 17:21:46 UTC
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…
Comment 4 Egmont Koblinger 2014-08-16 17:28:58 UTC
> 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.)
Comment 5 Egmont Koblinger 2014-08-16 17:44:04 UTC
Comment 6 Egmont Koblinger 2014-11-24 22:29:44 UTC
Comment on attachment 281504 [details] [review]

Committed (with a bit more verbose FIXME comment).
Comment 7 Christian Persch 2014-11-25 07:38:54 UTC
IMO this is a problem in gtk's handling of the geometry. -> gtk+
Comment 8 Egmont Koblinger 2014-11-25 10:50:53 UTC
For reference: the workaround is committed as

The bug can be observed with g-t <= 3.14.x, or with git revert a2a89b2.
Comment 9 Matthias Clasen 2018-02-10 05:18:30 UTC
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.
Comment 10 Matthias Clasen 2018-04-15 00:15:44 UTC
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: