GNOME Bugzilla – Bug 528304
New tabs shrink terminal
Last modified: 2013-10-09 12:01:51 UTC
[ From http://bugs.debian.org/472672 ] A Debian user reported this rather interesting bug: "1. Open terminal window -> 80x24 terminal 2. Open Tab -> Whole window shrinks in height in spite of the fact that the tab bar is no added, so the terminal size is now 79x21 3. Close Tab -> terminal keeps 79x21, whole windows shrinks, because tab bar disappears 4. Open Tab -> terminal is now 78x18, whole window shrinks 5. Close Tab -> terminal keeps 78x18, tab bar disap. 6. Open Tab -> keeps 78x18, tab bar added and so on Terminal size doesn't go down under 78x18. The closing tab things works as expected (keeps terminal size and remove tab bar)." This apperently only happens on an amd64 system, when Metacity has the compositing feature turned on. Details such as a the gnome-terminal configuration and .bashrc/.bash_profile are available at the URL above.
*** Bug 535837 has been marked as a duplicate of this bug. ***
*** Bug 552286 has been marked as a duplicate of this bug. ***
Can you try if the same happens with another compositing window manager (e.g. compiz), or if this is specific to metacity ?
Yes, I can confirm that the exact same problem appears with compiz fusion. I can't see gnome-terminal's window measurements under compiz (I guess resize event is intercepted before the app gets it), but the dimensions shrink in the same way as under metacity when it's compositing manager.
Are you all using debian? There's a suspicious patch in debian's g-t, http://patch-tracking.debian.net/patch/series/view/gnome-terminal/2.22.3-2/04_resized_on_tabs_switch.patch .
I should have mentioned it when I added to the report, but I'm seeing this using Mandriva cooker (currently in the final beta phase ["RC" isn't quite really "RC"] before 2009.0).
Additional info: (I first reported in bug 535837): I use Fedora, the bug is also present under metacity and compiz.
Can you please all try a pristine build from gnome sources, ie. without any vendor patches?
(In reply to comment #8) > Can you please all try a pristine build from gnome sources, ie. without any > vendor patches? I'm sorry, I don't think I'm going to have enough time for that in the near future. I was going to file a downstream bug with Mandriva, then found one already open: https://qa.mandriva.com/show_bug.cgi?id=27702 From the looks of comments on that bug, this seems to have been going on a for a while. I'll add a comment there. Maybe they can help with info about their patches?
as you can see http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/gnome-terminal/current/SOURCES/ , the patches in Mandriva package don't change anything in gnome-terminal behaviour.
I'm unable to reproduce this here, using metacity, either with or without compositing, on ubuntu intrepid x86.
Hoory! I can confirm that as of gnome-terminal 2.24.0, I don't see this problem anymore. (My previous comments were with 2.23-series versions, though like Fred said, without any patches that would explain the behavior.) Tested under both compiz and metacity with compositing (metacity without compositing never exhibited the problem, and still doesn't). This is using Mandriva Linux 2009.0, which is the upstream version plus "various bug fixes from SVN" (according to the package changelog). Here's the patch: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/gnome-terminal/current/SOURCES/gnome-terminal-2.24.0-svnfixes.patch?revision=290546&view=markup Looks to me like the patch is for bug 453193, but I thought I'd mention it anyway. Christian: not sure what did it between the previous pre-release versions and 2.24.0. I should mention that I was using the proprietary nVidia driver in all cases. Perhaps there was a bug in it that affected geometry (since the bug only appeared when using a compositing manager), and now it's fixed. Sven, Nicofo: my guess is that if you try the latest version of GNOME, the problems will be gone. Or simply wait and install the final version of your distribution when it comes out. ...or don't wait, and switch to Mandriva, first with GNOME 2.24. ;-)
Oops, sorry Sven. Missed that you were reporting for a Debian user. In that case, maybe pass the information on to the Debian bug report/reporter...
Ah ha! Found a new test case where this bug still appears: 1) launch gnome-terminal 2) maximize window 3) open new tab 4) restore window I start with --geometry=100x30 ; after the above sequence, my window is 99x27 characters (as shown by the hint when the resize starts, but without moving the mouse). This is with gnome-terminal 2.24.0. Note that interestingly, the bug appears using the above procedure both with and without a compositing window manager. Before, I saw this behavior when the window was in the "normal" non-maximized state but only with a compositor.
That's not the same bug as comment 0 refers to. (I can repro this though, but I'm not sure it's really a bug.)
Hmm, well that was the behavior that I was seeing with a "normal" (non-maximized) window in bug 552286 (marked as dup) and my comment 4 to this bug. The only difference is, I no longer see the behavior in comment 4 (per comment 12). But the "add tab = window shrinks" behavior is entirely consistent with what I was seeing before, down to the same geometry change when shrinking (see bug 552286 and comment 12 here). If that's not a bug, not sure what it is. ;-)
*** Bug 560481 has been marked as a duplicate of this bug. ***
(In reply to comment #17) > *** Bug 560481 has been marked as a duplicate of this bug. *** I don't know exactly how works this bugzilla, but I think bug 560481 is not a duplicate : it's quite specific because of compiz-specific and three-or-more tabs having different font-size...
(In reply to comment #12) > Sven, Nicofo: my guess is that if you try the latest version of GNOME, the > problems will be gone. Or simply wait and install the final version of your > distribution when it comes out. > > ...or don't wait, and switch to Mandriva, first with GNOME 2.24. ;-) > Well, it's not the case: I have now Fedora 10, which ships with gnome-terminal-2.24.3-1.fc10.i386 ==> the bug is still present: nothing has been improved...
(In reply to comment #19) > Well, it's not the case: I have now Fedora 10, which ships with > gnome-terminal-2.24.3-1.fc10.i386 ==> the bug is still present: nothing has > been improved... I'm not using compiz currently, but when I last tested it was fine. Maybe you could test under Metacity with and without compositing to confirm for Christian whether the bug appears in other cases, as I did under Mandriva? And I should (re)mention: I'm still seeing the bug when I open a new tab while the window is maximized. When restored, its geometry has changed as a result of the new tab action done while maximized. (See comment #14.)
(In reply to comment #20) > I'm not using compiz currently, but when I last tested it was fine. Maybe you > could test under Metacity with and without compositing to confirm for Christian > whether the bug appears in other cases, as I did under Mandriva? Yes, sorry, I have forgotten to add that for me the bug is still present under - metacity (so without compiz) - KDE (kwin with desktop effects) - KDE (kwin without desktop effects) I use the gnome-terminal given by Fedora 10 after a fresh install.
I'm still seeing this bug with 2.28 as packaged by Debian (Under compiz)
@rollercow: Please try if this also happens when using metacity (with compositing disabled) as window manager.
Metacity - compositing disabled it behaves correctly, with compositing enabled it misbehaves as per this bug
I can confirm this for both metacity 2.30.1 with compositing and GNOME Shell 2.29.1.
Oh and that's gnome-terminal 2.30.1, too.
This is possibly fixed on git master.
I see a similar, though not the same behavior in gnome-terminal 3.4.1.1 (Ubuntu Precise). When you open a new tab, the window height increases by two lines. When you close the tab, the window size decreases by one line. So for each open/close tab cycle, the window gets higher by one line.