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 348601 - Spontaneous resize selecting tabs with 3 or more tabs open
Spontaneous resize selecting tabs with 3 or more tabs open
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
2.15.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
: 352326 353413 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-07-25 03:45 UTC by Jose M. daLuz
Modified: 2006-11-07 20:34 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Jose M. daLuz 2006-07-25 03:45:25 UTC
If I have a terminal open with 1 or 2 tabs, resize the terminal, then add a third tab gnome-terminal immediately increases in size. Usually, it lengthens first, often going beyond the bottom of the screen. If I continue to add tabs, it will eventually become much larger than the screen area, both horizontally and vertically. Clicking on tabs after this process has started will also increase the size of the terminal, usually in smaller increments.

I'm running on Gentoo with Xgl/compiz. I have heard from another user (on Ubuntu) with this problem that it does not occur under metacity, only with compiz, running the same version of gnome-terminal, 2.15.2.
Comment 1 Jose M. daLuz 2006-07-27 05:43:11 UTC
This behavior is unchanged in 2.15.3.
Comment 2 Fryderyk Dziarmagowski 2006-07-27 18:46:47 UTC
I can confirm it. moving between tabs or even closing it resizes whole window. Using metacity and standard xorg xserver here.
I think 'normal' severity it too light for this bug. It makes g-t almost unusable.
Comment 3 Fryderyk Dziarmagowski 2006-08-03 18:55:11 UTC
well. it's still present with 2.15.4. But I can't reproduce it every time i start g-t.
Comment 4 Jose M. daLuz 2006-08-03 19:09:26 UTC
(In reply to comment #3)
> well. it's still present with 2.15.4. But I can't reproduce it every time i
> start g-t.
> 
I can reproduce it reliably with 2.15.4. What's more, I usually have a terminal with at least two tabs open in every session, and sometimes on session start this terminal opens oversized and partially off screen.
Comment 5 Emmanuele Bassi (:ebassi) 2006-08-05 13:01:04 UTC
confirming with 2.15.4 on ubuntu. the behaviour appears only if tabs number > 2 and it reproducible.
Comment 6 Wouter Bolsterlee (uws) 2006-08-10 08:58:30 UTC
Confirming with gnome-terminal HEAD on a complete gnome HEAD environment (jhbuild)
Comment 7 Gabriel Wicke 2006-08-13 18:47:18 UTC
Confirming with 2.15.4 on Ubuntu Edgy (standard Xorg and Metacity) with two or more tabs.

It always resizes when switching back to the first tab in a set and when enabling/disabling the menu. For me only the width changes, with the amount equal to the width of the displayed tabs- so with many tabs open it resizes much less than with only two tabs open.
Comment 8 Olav Vitters 2006-08-28 21:59:53 UTC
*** Bug 352326 has been marked as a duplicate of this bug. ***
Comment 9 Daniel James 2006-08-28 23:44:24 UTC
I am no longer able to reproduce this after today's Ubuntu Edgy update no matter what I try. g-t 2.15.4 (I am also unable to reproduce this now following the instructions in Bug 352326. Just fyi..
Comment 10 Mariano Suárez-Alvarez 2006-09-03 10:06:11 UTC
I can reproduce this with HEAD as of now.

I have noticed the following: open a window, resize it to AxB. Now open a tab and close it untill the window spontaneously resizes. Look at the size of the terminals: they have increased by abs(A-80) and abs(B-24). Fun.

Moreover, when this resizing happens, vte_terminal_size_request fills in the correct request, but vte_terminal_size_allocate gets passed the wrong allocation. 
Comment 11 Mariano Suárez-Alvarez 2006-09-04 07:52:54 UTC
It should be noted that, if my patch on bug 354234 is applied, the magic numbers 80 and 24 in my comment 10 are replaced by the co and li entries in the vte-installed termcap.
Comment 12 Mariano Suárez-Alvarez 2006-09-04 18:38:26 UTC
*** Bug 353413 has been marked as a duplicate of this bug. ***
Comment 13 Fryderyk Dziarmagowski 2006-09-08 20:36:57 UTC
Unfortunetely 2.16.0 is still affected. Newest observations: it can be triggered even with gtk theme change or just cursor move (when "focus follow mouse" is used).
Comment 14 Antoine Pitrou 2006-09-09 16:29:13 UTC
I confirm this with 2.16.0 too (Mandriva Cooker). *Very very annoying* bug when it happens.
Comment 15 Eric Anderson 2006-09-21 22:05:58 UTC
This may be a dup of bug 338913. I know that Gentoo has applied the patch from bug 95316 to the currently unstable 2.16 GNOME release. Ubuntu Edgy may have included it in its 2.15.4 release as well.
Comment 16 Piotr Smyrak 2006-10-09 12:23:26 UTC
I can confirm that with gnome-terminal 2.16 running in Fluxbox on FreeBSD. I had to dump gt for mrxvt to be able to work. 
Comment 17 Eric Anderson 2006-10-09 14:25:25 UTC
I was able to reproduce the bug with a slightly old version of CVS HEAD. The problem went away when I applied patch 66207 from bug 95316.
Comment 18 Fryderyk Dziarmagowski 2006-11-07 18:25:47 UTC
this bug seems to be obsolte, what about closing it?
Comment 19 Behdad Esfahbod 2006-11-07 19:59:15 UTC
(In reply to comment #18)
> this bug seems to be obsolte, what about closing it?

I don't think it's obsolete.  No.
Comment 20 Fryderyk Dziarmagowski 2006-11-07 20:21:16 UTC
After applying patch 66207 problems magically went away. Fix is commited to HEAD and 2-16 branch. Keeping it open makes no sense for me. Anyway, it is just a friendly reminder to not leave cruft in bugzilla.
Comment 21 Behdad Esfahbod 2006-11-07 20:34:34 UTC
Ok, now that's a good reason to close it :).