From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Description of problem:
First noticed this minor quirk in Severn beta 9.0.93.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open gnome-terminal with default settings.
2. CTRL-SHIFT-t once.
3. CTRL-SHIFT-t again.
Black fills the window except for the prompt.
Should be all white like the previous tab.
Predict this is a vte issue, gnome-terminal hasn't really changed.
FWIW, I can't reproduce this on today's Rawhide. I haven't looked for the bug
before, though, so I can't say if it's been fixed, or if it's just something
that works on my machine.
I still get the problem with gnome-terminal-2.3.2-1 and vte-0.11.10-2 (both in
rawhide and Severn updates).
I'm still seeing this with gnome-terminal-18.104.22.168-1 and vte-0.11.10-4
Moi aussi. Sometimes it takes more than two Ctrl-T's to get the black screen.
The problem is known upstream, see:
I suggest to mark bug #110109 as a duplicate of *this* bug.
*** Bug 110109 has been marked as a duplicate of this bug. ***
The black background is displayed when opening the third, fourth, etc.
tab, but not for the first two
Closing all but the first tab and creating a new tab (i.e. a new
second tab) still gives a white background, but opening a third tab
again gives a black background.
Switching from a tab with a black background to another tab and back
again fixes the background (i.e. makes it white).
seems to be fixed for me in latest rawhide with these versions. Can
anyone else confirm?
I still get it with yesterday's rawhide (>= than yours):
*** Bug 134466 has been marked as a duplicate of this bug. ***
Created attachment 105863 [details]
redraw vte screen when unobscured visibility event is caught
forgot to paste my comments sorry.
This issue seems to be caused by a race condition between the
visibility event and the configure-event. The terminal knows it is
visible, and the vte_terminal_configure_toplevel callback is attached,
but the configure-event never happens. My most elegant solution has
been to run vte_invalidate_all on the terminal when the visibility
event is caught and it's state is UNOBSCURED.
Patch seems to have the desired effect. Thanks Jon, this has been
bugging me too for quite a while...
Please add this patch to vte too.
Patch added to rawhide.
The bug is still in FedoraCore3, which provides vte-0.11.11-6. There
is no standard update (in "updates-released" repository) available for
yum. So, the usual update command:
doesn't solve the bug.
The vte version available in the "development" repository
(vte-0.11.11-15) seems to solve the problem. I've installed it with:
rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora-test
yum --enablerepo=development update vte
It would be useful to have the solution available in the
"updates-released" repository for an easier update. Any possibility to
[In Gnome Bugzilla, Olav recommends to upgrade to vte 0.11.12:
Everyone's favorite bug is back again.
On the creation of the first tab, the terminal is all white (no prompt or
anything). On the creation of the second tab, the terminal is all black. Both
new tabs are unresponsive. Switching to a different tab and back again will
force an update, but it still does not respond interactively.
I don't see this problem with vte-0.13.6-1.fc6.i386.
Are you on i386 or x86_64? Also, try turning on accessibility. It may just
happen more often if you do.
i386 here. How do I turn on accessibility?
You can turn on accessibility via this super-quick menu shortcut:
System->Preferences->Accessibility->Assistive Technology Support->Enable
For me, the various incarnations of this bug have always occurred far more often
on x86_64 than on i386.
I'm seeing this on i386 FC6 without Accessibility enabled. I am guessing this
has some timing basis as it doesn't always happen.
Hmm.. I'm not seeng this on FC5, never has (or FC6). But i see it regularly on
RHEL (WS 4? i think so).
FC5 and FC6 are not supported anymore. Can anyone reproduce this bug on F7 or F8?
I have never seen it on newer FC, but I do think it does occur on RHEL, as
stated in #26. Somebody should probably test that (The RHEL I have access to is
an hour away from here (to acess the console of the machines directly, without
SSH), and it is quite heavily modified...)
reassigning to RHEL 4
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life.
Please See https://access.redhat.com/support/policy/updates/errata/
If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.