Red Hat Bugzilla – Bug 670173
Terminal opens as 80x24, then auto-resizes to 33x24
Last modified: 2012-12-17 17:51:53 EST
Description of problem:
I'm running XFCE, and opened a Terminal via clicking on the background (perhaps it hadn't finished initializing?). The Terminal opened as 80x24, then shrunk to 33x24 (?). I opened another Terminal via ctrl-N in the first one, same result. Now that XFCE is fully functional, the same happens each time I open a Terminal via clicking on the background.
Opening a Terminal from the panel works normally.
Version-Release number of selected component (if applicable):
Has happened once.
Steps to Reproduce:
1. Open a Terminal by right click on the background, --> Open Terminal here
80x24 ~~-> 33x24
80x24, and stay that way
Odd. Anything related in ~/.xsession-errors?
Also, I have noticed a rouge gnome-settings-daemon sometimes starts up. Do you have one running?
If you kill it, does behavior go back to normal?
I do not have gnome-settings-daemon running and have the same issue with the shrinking terminal in XFCE. Same versions as the OP.
Nothing interesting in .xsession-erros.
(In reply to comment #2)
> I do not have gnome-settings-daemon running and have the same issue with the
> shrinking terminal in XFCE. Same versions as the OP.
> Nothing interesting in .xsession-erros.
BTW, if I open new tabs in a Terminal window (opened via clicking on the background), it starts shrinking, just like bug 669692 (gnome-terminal).
Oops, just double-checked. What I'm really running is gnome-terminal-2.33.4-2.fc15.x86_64, Terminal itself does behave. My XFCE4 configuration had gnome-terminal as default term. Sorry for the confusion.
Moving over there. ;)
I don't know if comment 2 is really Terminal or gnome-terminal?
Yeah. If it's Xfce's Terminal, I'll be happy to look more...
Sorry, Comment 2 is gnome-terminal, my bad.
Forgot I changed it.
Now gnome-terminal-2.33.5-2.fc15.x86_64, xfce4-session-4.8.0-2.fc15.x86_64,
Opening a gnome-terminal resizes to 29x24, clicking on its lower border to check its size makes it go to 29x2. Quite entertaining ;-)
No messages in the Terminal from where I started it.
(In reply to comment #9)
> Opening a gnome-terminal resizes to 29x24, clicking on its lower border to
> check its size makes it go to 29x2. Quite entertaining ;-)
If I open a tab in the 29x24 tty, it also resizes to 29x2.
*** Bug 669692 has been marked as a duplicate of this bug. ***
Now it says:
(gnome-terminal:3346): IBUS-WARNING **: org.freedesktop.IBus.InputContext.GetEngine: GDBus.Error:org.freedesktop.DBus.Error.Failed: Input context does have engine.
Still the same resizing mess under XFCE.
I'm seeing this too, its quite frustrating.
I've just updated my system to FEDORA 15, using KDE and getting the same, no matter where I start the Terminal. I've tried to open a new tab, it takes 10 seconds and start to shrink.
But when opening a 3rd tab, then it stays at the same size
After installing F15 TC1 and logging into Xfce, I can confirm the same on a clean config. On launch of gnome-terminal, it resizes itself by shrinking in horizontally from the right-hand side. On opening a second terminal, it shrinks vertically from the bottom, leaving you with a 34x3 terminal. Additionally, I can't actually type anything into it.
In GNOME and LXDE, it behaves itself.
In KDE, it behaves similarly to Xfce, but it shrinks both horizontally and vertically as soon as it's run (no need to open a second tab), and I can type into it, it seems to work mostly normally, bar the ridiculous size.
When running an affected desktop, if you manually resize it back to a sensible size, it shrinks itself again.
I don't see any error messages if I launch gnome-terminal from within Terminal.
Re-assigning to mclasen as he seems to be the one doing all the work on gnome-terminal.
Fedora Bugzappers volunteer triage team
FWIW, I am also seeing this on Arch Linux, running gnome-terminal in KDE.
I have the same problem after upgrading from Fedora 14 to Fedora 15. All packages updated to the latest available version.
I noticed other strange behaviour. The Gnome terminal resizes itself even when changing a Style in Appearance settings. Especially when changing to/from he Adwaita style. Maybe it has something to do with change of fonts?
And other think I have noticed is that the look of the Gnome terminal doesn't match the selected Appearance Style. When I select the Xfce-4.6 style with light blue color as a background of a selection and round corners, I see this color and corners in every GTK/GNOME app but not i Gnome terminal where I see dark blue color and sharp corners.
So it's maybe some problem of .gtkrc or something like that. I tried to rename ~/.config and ~/.gconf, logout and login but it's still the same.
I'm quite disappointed with it. I updated to F15 as I expected it to be better than F14. :-(
I hope there will be a solution very soon.
I see the same thing, gnome-teminal resizes, but to much smaller both horizontally and vertically, also at startup.
One additional data point, I have maximize-vertically bound to <super>-m (eg. menu-m). For all other windows this works as expected. For gnome-terminal it often also causes the auto-shrink instead of maximizing the window. Maybe gnome-terminal has a bug where window resize commands trigger a string of resizes that results in a shrinkage?
Additional info regarding the look. I realized that gnome-terminal (and more GTK/Gnome apps) are built on GTK3, while XFCE is built on GTK2. So XFCE settings manager manages GTK2 look.
I'm not sure it this GTK2-GTK3 issue might be the problem of shrinking of gnome-terminal, possibly not.
I can confirm this for
my gnome-terminal also seems to have no skin and resizes to 80x3 90% of the time, regardless of how i open it(alt-f2 / keybindings / menu). I had the impression that turning off compositing in xfwm-tweaks reduces the phenomenon, but it still happens sometimes.
I'm yet Another Fedora 15 XFCE user who has seen this.
*** Bug 713055 has been marked as a duplicate of this bug. ***
I'm also experiencing this on f15 xfce on my mad run away from gnome :)
No solution to this, eh? I'm seeing it too.
As other posters have noted:
* It starts happening as soon as you add a second tab to gnome-terminal.
* It stops happening as soon as you reduce to a single tab (so the tab bar disappears).
It seems like a cycle between gnome-terminal and the window manager. Gnome-terminal is announcing a new size, the window-manager responds with a slightly different size, gnome-terminal adjusts and announces again, etc.
Yet another Fedora user seeing this with XFCE and gnome-terminal. gnome-terminal opens at the size I specify and shrinks. Yes, I know about XFCE's Terminal. I would use XFCE's Terminal, except that I have not figured out how to make each Terminal have its own background and/or color scheme. Changing one changes them all.
I've also seen this problem (not on Fedora here tho' - but I guess this is a common problem). I suspect things work fine under gnome-shell (unrelated issue is giving me problems logging in there right now) so it's likely some issue relating to it being run outside of it's "natural" habitat and just not covering such a case gracefully.
This bug needs to be increased in priority since it greatly affects workflow for a large number of users.
I'm running Fedora 15 x86_64 with XFCE as the desktop environment and I'm seeing this effect as well.
It's worth noting that when using the pywo window placement program (http://code.google.com/p/pywo/) this effect also occurs after you place a window using the pywo move/resize key combinations.
I _may_ have a workaround. It's somewhat kludgy, but workarounds often are.
Open a gnome-terminal. Resize it manually. Click Edit > Profiles... > New > [make up some name for it] > Create.
I called my new profile beigeblack, because it's got black print on a beige background. The edit-the-profile window opens. In the General tab, make sure you check the "Use the system fixed width font" and uncheck the "Use custom default terminal size" box. Use the other tabs to edit the color scheme. Close the edit-the-profile window. Close the Profiles window.
In another terminal, run gnome-terminal with your new profile and your desired geometry. _And_ add a --zoom factor. E.g.:
gnome-terminal --profile=beigeblack --geometry=80x45 --zoom=0.98
This gives a slightly smaller gnome-terminal than without the zoom factor. I experimented a little bit with zooms of 1 and greater. Anything between 1.0 and something less than 1.75 gives a larger gnome-terminal that shrinks. Somewhere just below 1.75 and above, I get a larger gnome-terminal with a stable size. I don't know where the exact cutoff is and I didn't feel like writing a script and opening a couple of dozen gnome terminals to see which zoom factor stopped the shrinkage.
I think know the cause of the bug.
What happens is that gnome-terminal sends a request to the wm for a resize.
The wm does not fully respect this resize (for whatever reasons) and gives gnome-terminal a new size that it did not request. Instead of accepting this (as it should), gnome-terminal sends a new size request to the wm and the whole cycle continues.
I noticed this behaviour while writing my own wm. Gnome-terminal would ask a size, my wm would (incorrectly) assume that only multiples of the prefered increment size given by gnome-terminal are valid sizes. My wm would thus give gnome-terminal a size it did not request which triggered a new resize request of gnome-terminal. As soon as I fixed this bug in my wm solved the problem.
I swear this was reported as an earlier bug, but I can't find it now. (And not the currently-marked duplicate.)
It used to happen on first window open, but that appears to be fixed. Now it mostly stays correct, but still does the funny shrinking act if you, for example, use the keyboard shortcuts to increase or decrease the font size.
The bug is actually in xfwm4, not in gnome-terminal. I am seeing the same with roxterm 2.x built with gtk3/vte3. The GNOME folks only accept is as a bug against GTK3 if you see the same with metacity/mutter, see
The bug was reported against Xfwm4 at
I have tested the fix mentioned in that report and it works. Taking over.
xfwm4-4.8.1-3.fc16 has been submitted as an update for Fedora 16.
xfwm4-4.8.1-3.fc15 has been submitted as an update for Fedora 15.
> xfwm4-4.8.1-3.fc16 has been submitted as an update for Fedora 16.
Works for me: terminal no more shrinks.(In reply to comment #33)
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xfwm4-4.8.1-3.fc16'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Yes xfwm4-4.8.1-3.fc16 fixes the issue for me - great!
How about you all give feedback in the updates system at
to get the update pushed to stable faster?
Already done in my case for f16...
I've upgraded to xfwm4-4.8.1-3.fc15 from updates-testing repo and gnome-terminal works as it did in Fedora 14. Wow, that's great. Thank you all guys who fixed it.
xfwm4-4.8.1-3.fc15 is buggy in a worse way. It fixed the gnome-terminal auto-resize but broke the intentional resize when using window-manager keystrokes to resize horizontal size, vertical size or both to fullscreen.
Go to preferences -> window-manager -> keyboard
set the following:
Maximize window horizontally -> <super>h
Maximize window vertically -> <super>v
Maximize window-> <super>f
Under all previous xfwm4 versions on f15 the keystrokes worked to toggle the window size from the small window to fullscreen in the desired directions (h, v, or both). Under xfwm4-4.8.1-3.fc15 this is broken. The window grows to the max size as requested, but never shrinks back to the original size on the second keypress. This is a worse bug than before. One can always use a different terminal emulator, but not being able to resize windows quickly with a keystroke is a real pain in the posterior.
I can confirm what Wolfgang Rupprecht noticed.
Vertical and horizontal maximize doesn't work. The window stays maximized on second and successive key presses (Ctrl-F9 for vertical and Shift-F9 for horizontal maximize in my case). Normal maximize (Ctrl-Shift-F9 for me) works as expected.
I noticed this behaviour on V/H maximize: on first key press window extends itself to nearly full width/height of the screen. Not full w/h as real w/h is calculated from increments I assume. The maximize/restore icon on top right corner stays "Normal". On the second key press windows extends itself to full width or height of the screen and icon changes to "Maximized". On the third key press window resizes back to the "nearly full" and icon changes to "Normal". From then successive key presses switch from "nearly full" to "full".
Full maximize maximizes the window to "full" screen (ignoring increments?), icon changes to "Maximized" and restore restores the window and icon to its normal size as expected.
I tried V/H maximize on non terminal application (gmpc), both work as expected, window is resized to full width/height, icon changes to "Maximized". On second key press the window and icon are restored to normal as expected.
(In reply to comment #41)
> Under all previous xfwm4 versions on f15 the keystrokes worked to toggle the
> window size from the small window to fullscreen in the desired directions (h,
> v, or both). Under xfwm4-4.8.1-3.fc15 this is broken. The window grows to the
> max size as requested, but never shrinks back to the original size on the
> second keypress.
I am using Alt+F10 for "Maximize Window" and I cannot confirm this: For me it toggles fine, vertically, horizontally and fully. Just to be clear: You press each key twice, you are not using the key for maximize to minimize a window that has been maximized horizontally/vertically, right? In this case the window shrinks back to it's initial size and I consider this the correct behavior.
I'm not a xfce user myself, thus I don't encounter the bug directly. I do however know a thing or two about X and how clients are supposed to communicate with a window manager.
First of all:
A client that does not want to work with the size as set by the window manager by issuing a new configure request is *unacceptable* behaviour on the client's (gnome-terminal in this case) side.
I client should be able to give hints to the window manager about it's size, increments, minimum size. But in the end should cope with every possible size, even if that means displaying a text "I'm too small to display anything".
Btw, this is not me talking out of my ass, this is the ICCCM and EWMH talking.
"Clients must not respond to being resized by attempting to resize themselves to a better size. If the size is impossible to work with, clients are free to request to change to the Iconic state."
And that's exactly what gnome-terminal is doing (So it's not an xfce bug perse)
I do realise the it is sometimes impossible to convince other dev teams of their wrongdoing but I hope that for a change they do the right thing istead of others implementing workarounds for other peoples *ahem* failing.
(In reply to comment #43)
> I am using Alt+F10 for "Maximize Window" and I cannot confirm this: For me it
> toggles fine, vertically, horizontally and fully. Just to be clear: You press
> each key twice, you are not using the key for maximize to minimize a window
> that has been maximized horizontally/vertically, right? In this case the window
> shrinks back to it's initial size and I consider this the correct behavior.
Yes, I'm starting with a small window that I'm trying to temporarily increase in size and then decrease again by pressing the exact same key a second time. This behavior was observed with both the xfce native terminal (/usr/bin/Terminal) and gnu emacs.
> First of all:
> A client that does not want to work with the size as set by the window manager
> by issuing a new configure request is *unacceptable* behaviour on the client's
> (gnome-terminal in this case) side.
That's what I think too. The client should (or must) accept size assigned to it by WM. And I think that it's g-t issue it asks for different size repeatedly.
I observed the same maximize/restore problem with Terminal and xterm under xfwm4-4.8.1-3.fc15. First V/H maximize maximizes the window to "near full" size according to increments (calculated from font size?) but the window isn't marked as maximized (icon is "Normal"). Second maximize maximizes to "full" screen width or height instead of restore. And empty unused space appears on the right between the last column and window frame. And that's wrong.
I've reverted to xfwm4-4.8.1-2.fc15 to see how V/H maximize behaves there. It works as expected. Tested on Terminal and xterm (g-t sucks there). On maximize the window is resized to "near full" size according to increments, but is marked as maximized (icon is "Maximized"). On second key press the window is restored to its original size. I've tried to change font size and maximize/restore, it's always working right.
My conclusion is that xfwm4-4.8.1-2.fc15 works perfectly with standards conforming clients but not with g-t. I'm staying with xfwm4-4.8.1-2.fc15 and Terminal.
Hold on: So you have the problem that an application no more shrinks (this means the second keystroke no longer works) only with gnome-terminal? I have to admit I didn't test this one since I don't use it. All other apps I tested work fine and for me xfce4-4.8.1-3 works just like xfce4-4.8.1-2. If it is only this particular application that is still causing problems, then we indeed see a bug in gnome-terminal.
(In reply to comment #47)
> Hold on: So you have the problem that an application no more shrinks (this
> means the second keystroke no longer works) only with gnome-terminal? I have to
> admit I didn't test this one since I don't use it. All other apps I tested work
> fine and for me xfce4-4.8.1-3 works just like xfce4-4.8.1-2. If it is only this
> particular application that is still causing problems, then we indeed see a bug
> in gnome-terminal.
No I see this V/H maximize bug in all terminals (g-t, Terminal, xterm, ...) maybe it affects other apps which hint increments to xfwm4. Other apps maximize/restore normally. So it's indeed a bug introduced to xfwm4-4.8.1-3 by last changes.
FWIW, I've seen this same problem (g-t shrinking) on KDE as well, so it leads me to believe that the problem is indeed in g-t. Not tested in the last few months (and not on fedora either), but it seems to me like an issue outside of xfce.
That's right, g-t has the problem in other WMs. It may not shrink in Metacity, but from what I know it's the only WM where it works. Maybe there is a workaround in Metacity or even a bug which eliminates/negates the g-t bug.
I think the problem is in g-t and not xfwm4. And as Erik pointed g-t dev team shoud take care of it and don't blame other dev teams.
(In reply to comment #50)
> And as Erik pointed g-t dev team
> shoud take care of it and don't blame other dev teams.
Best way to achieve this is to add your comments to
xfwm4-4.8.1-3.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
xfwm4-4.8.1-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.
Was it pushed to stable repository regardless of the problem with vertical/horizontal maximize?
I don't like this approach - pushing problematic update with known bug to stable repo it a bad way. I don't want my xfwm4 to be updated to this bugged version.
According to gnome bugzilla it seems that whole problem with window autoresize is in gtk3. I hope they'll fix it asap.
I'd rather use current xfwv4 with working V/H maximize and avoid using g-t and other gtk3 apps which hint increments to the WM.
Why was this buggy program pushed to stable? Does fedora no longer have rules to forbid this sort of thing?
(In reply to comment #54)
> Was it pushed to stable repository regardless of the problem with
> vertical/horizontal maximize?
Because several people, one of them being a proven tester and one of them the package owner, could not reproduce the problem.
> According to gnome bugzilla it seems that whole problem with window autoresize
> is in gtk3. I hope they'll fix it asap.
So did you speak up in their bugzilla?
BTW: The fact that you are having problems with *all* terminals, e.g. with Terminal, too, means that your logic cannot be correct. Terminal uses neither gtk3 not vte3.
> Because several people, one of them being a proven tester and one of them the
> package owner, could not reproduce the problem.
Did they try using various font sizes? Did they try it on various screen resolution? In Terminal I use DejaVu Sans Mono Book font, size 9. screen resolution 1600x900. The V/H problem arises (possibly) because first V maximize in my case don't fit to 1600px but (let's say 1594px) and from then successive maximize/restore switch between 1600px and 1594px.
> So did you speak up in their bugzilla?
Yes I did report it, see https://bugzilla.gnome.org/show_bug.cgi?id=649680
> BTW: The fact that you are having problems with *all* terminals, e.g. with
> Terminal, too, means that your logic cannot be correct. Terminal uses neither
> gtk3 not vte3.
No, the problem is *only* with g-t and other gtk3 apps which hint the WM. There is no problem with Terminal and other gtk2 apps. And I wrote this several time in this thread...
xfwm4-4.8.1-4.fc16 has been submitted as an update for Fedora 16.
xfwm4-4.8.1-4.fc15 has been submitted as an update for Fedora 15.
(In reply to comment #57)
> Did they try using various font sizes? Did they try it on various screen
No, because you didn't tell them to do so. If you want people to reproduce your problems, please give detailed instructions.
I still think that my decision to push 4.8.1-3 was right. It fixed more problems than it caused. This is what both the testers and upstream say.
Meanwhile upstream released another fix (after I spoke up, not you) and the latest updates should fix your problems. Please test them ASAP because the final change deadline for F16 is only a few days away.
(In reply to comment #60)
> (In reply to comment #57)
> > Did they try using various font sizes? Did they try it on various screen
> > resolution?
> No, because you didn't tell them to do so. If you want people to reproduce your
> problems, please give detailed instructions.
Ok, maybe it was my fault, but I (wrongly) supposed that when I described the behaviour that the developers would try various settings which might cause the problem.
> Meanwhile upstream released another fix (after I spoke up, not you) and the
> latest updates should fix your problems. Please test them ASAP because the
> final change deadline for F16 is only a few days away.
I have updated to xfwm4-4.8.1-4 and these are my observations:
- Terminal (and hopefully other GTK2 increment hinting apps) - everything seems fine. V/H maximize/restore works as expected. There is only one glitch. When I do V max, then H max I have full max which is ok, but when I then H restore I get original size, not V maximized. But this is not a big issue and I can live with it.
- Gnome-terminal (and possibly other GTK3 increment hinting apps) - there is still problem.
1. open g-t - OK
2. V maximize to width1 (w1) which looks right - OK
3. V restore - FAIL. Doesn't restore the width of the window but decrements the height of the window by one line. Repeating V restore decrements the height until it's 3 lines.
4. Next V restore stops decrementing height and maximizes to width2 (w2) which is bigger than w1 and max/restore icon changes to Maximized.
5. Next V restore "restores" the width to width3 (w3) which is lesser then w1 and max/restore icon changes to Normal.
6. Next V restore maximizes from w3 to w1 (icon stays Normal), then from w1 to w2 (icon Maximized), then from w2 to w3 (icon Normal) and again...
Same with H maximize. As I stated before, I still think that it's the problem of GTK3 as suggested by others in gnome/gtk bugzilla.
Tested on 1600x900, g-t 3.0.1, font Monospace 9.
I propose this bug for F16-accepted because it annoyed quite some people as you can see in this bug report.
it should make the final pre-freeze stable push without being declared nth, but I vote +1 anyway. it's an annoying bug which can be hit in live boots.
xfwm4-4.8.1-4.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
I have installed yesterday the Fedora 16 and try the same problems. After that i have lunched the Terminal from "K" Menu --> System --> Terminal this started width 80x24 and immediately shrunk to 35x4
On this Fedora there is installed xfwm4-4.8.1-5.fc16.i686.rpm.
There isn't problem to use "terminal emulator" /usr/sbin/Terminal
(In reply to comment #65)
> After that
> i have lunched the Terminal from "K" Menu --> System --> Terminal
If you started it from the K- Menu, you are using KDE. Please file a bug against kwin in the kdebase-workspace package.
> There isn't problem to use "terminal emulator" /usr/sbin/Terminal
There is no such thing as /usr/sbin/Terminal, it's /usr/bin/Terminal.
xfwm4-4.8.2-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.