changing font size in gnome-terminal changes terminal dimensions

I haven't investigated, but I assume you have; why do you think this is a window manager problem?

If the window has the dimensions of 80 columns by 25 rows, I change the font size down and up a couple steps ending back at the original size and now my window has dimensions of 68x22, which component is likely to be the source of the problem. I assumed window manager, but I do not know how things are structured and where responsibility lies. If it belongs to a different component, please reassign.

Probably not the WM, but I suppose it's not impossible; I'll try to look into it this evening and report back.

Not a WM problem. gnome-terminal does this deliberately through terminal_window_set_size_force_grid().

I know _NOTHING_ about window manager calls, but why is this only affecting compiz/unity. On the same box, I can start a gnome-terminal under icewm and increase or decrease font size all day long without an issue. Are you saying that gnome-terminal is calling terminal_window_set_size_force_grid() with wrong parameters or something and is just so happens that icewm interprets that correctly?

After testing with XFCE and ICEWM, I am convinced that this problem is unlikely to be gnome-terminal and almost certainly the window manager. I looked at the mapped files via /proc/<pid>/smaps for all three flavors of window managers and the only differences were related to font and sounds/notifications. Please don't condemn this bug report to death by assigning to the GNOME Terminal non-existant group.

I assure you, I don't want to let this bug vanish. I didn't realise when I reassigned it that it behaves differently under IceWM. I'll do some more testing tonight if I can (sorry, time is squeezed at the moment because I'm rehearsing for a concert next week). I'll let you know what I find and reassign as appropriate.

I've just tested this under IceWM and I can confirm that changing the font size in gnome-terminal still resizes the window. Reporter, are you still getting this behaviour?

Yes, but I believe there is a misunderstanding. I am not saying there is a problem with the window getting larger on the screen, I am saying that changing font size changes the number of rows and columns of characters in the newly resized windows. If I start with an 80x25 sized window, then decrease and increase the font size a couple times, the new window will have fewer rows and columns. Do not focus on the number of pixels, but rather number of rows and columns. That information is no longer very easy to determine because the window size is no longer displayed when resizing (useful information I wish had been retained).

I have tried this on every possible login session I can find and the only one that fails is the default Ubuntu
session. If I log in using the Ubuntu 2D session, it works there. This absolutely can not be a gnome-terminal
bug.

The dimensions of the terminal in characters should be preserved, the size of the window in pixels should increase or decrease proportional to the font size as font size is changed. This worked perfectly in gnome2, it is spastic in 12.10 unity.

Thanks for the attention to the problem.

I'm seeing this problem when using tabs in the gnome terminal window as well, the window resizes itself to preserve the terminal height in rows while accomodating the tab UI in the X window. When you close tabs the tab UI disappears and the window resizes again. This behavior sometimes works & sometimes leaves the terminal with more or fewer rows than it had originally.

Just tested in XFCE, gnome-terminal resizes correctly there.

Attempting to clarify again.

To reproduce the problem:

1.)
$ echo $LINES $COLUMNS
24 80
$

2.) increase font size
<ctrl><shift>+
<ctrl><shift>+

3.)
$ echo $LINES $COLUMNS
20 62
$

4.) decrease font size
<ctrl>-
<ctrl>-

5.)
$ echo $LINES $COLUMNS
27 92
$

The terminal size in lines and columns should remain the same, while the x window changes size to accommodate.

I'm happy to report this is fixed in 13.04. Thank you!

I can unfortunately still reproduce that problem, exactly like described...
Unfortunately I cannot set back the status to triaged, someone else should do that, please.

Thankfully, I stopped using Unity because of this bug. A year later and it is still being essentially ignored.

I'm experiencing this bug too...