Description of problem: When a new tab is created, it is often "frozen" in that the contents of the terminal is not updated until the user switches to a previously-working tab and back again. Commands do work - typing 'exit<CR>' closes the frozen tab. In one of my current terminal windows open now, 14 out of 17 tabs are frozen. Version-Release number of selected component (if applicable): gnome-terminal-2.12.0-2.x86_64 How reproducible: Almost always. Steps to Reproduce: 1. Open gnome-terminal 2. Create a new tab 3. Type stuff. Actual results: Nothing shows up. Expected results: The stuff you type shows up. Additional info:
Seeing similar symptoms on i386 gnome-terminal-2.12.0-2 vte-0.11.15-1.fc5 Seems to affect some tabs, but not others. I've taken to opening tabs until I get an unaffected tab, then going back and closing the tabs that are affected.
I also sometimes get an entirely blank black tab; switching tabs forwards and back gets the tab redrawn, but such a tab is still affected by the bug.
Looks like a repaint/expose problem; if you drag a window over one of the tabs, it repaints the stuff in the terminal tab that's changed. e.g. type "ls"<ENTER> in one of the tabs; nothing appears to happen; no keypress feedback, but drag a window in front to force repainting and you see the results of your ls (and the entry of the command)
Hey Dave, Zack, Are you guys still seeing this?
The last time I used the machine was Friday, and I was seeing it then.
how about now?
Same. gnome-terminal-2.13.3-1.x86_64 vte-0.11.16-2.fc5.1.x86_64
http://bugzilla.gnome.org/show_bug.cgi?id=125364 seems to be an upstream bug tracking this issue. Given that it is an old issue, and rare, move to FC6Target
Maybe it's 'rare' for i386 users... but I reproducibly have to create 15-20 unusable new tabs for each usable one on my x86_64 boxes. Ouch. Explicitly adding the GNOME bug as a reference.
Add to FC6Destop tracker
Zack, are you still seeing this on x68_64 ? I have not been able to reproduce it on i386
Matthias, yes I am. I can show you today if you want.
You see this in devel?!
Behdad, yes. I'm sorry. I don't think I ever saw it in FC5, which I was using for a while on this system, but I can reliably reproduce it in rawhide. I'll do it again right now. There. :)
Hmm, I just opened 50 tabs on our x86_64 test machine, which has a pretty recent rawhide, and not a single one froze. Zack, you still see this ?
Yes, I'm still seeing it. A lot. :(
I'm also noticing this bug with my x86_64 machine running rawhide
gnome-terminal-2.16.1-1.fc7.x86_64 Any new tab is frozen. Always. This started for me after fc6. sean
installing gnome-terminal-2.16.0-2.fc6.x86_64 as an old package fixes this. Is this an upsteam issue? only on x86-64?
I can fully reproduce it on x86_64 RHEL-5-Gold, but when I switched off ATK, things are suddenly OK (the idea with ATK is from bug 224611, which is quite similar).
A while ago I was already having this problem. After a reinstall everything worked fine for a while, but since a few weeks the problem has returned, though it is a little bit different behaviour this time. The first time the problem was that newly created tabs are often frozen (as the title of this bugzilla entry says :P), but this time the problem occurs a while after creating a new tab. The scrollbar itself behaves fine, but the terminal itself isn't getting any screen refreshes. Terminal I/O seems to work just fine, it's just the screen refreshes that are broken.
Just want to say me to. On a updated rawhide with gnome-terminal-2.17.92-1.fc7 I think i first saw that after fresh FT2 install.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp