Cloning for GTK+ 3.
This was triggered by the update to gtk3-3.2.2-2.fc16.
+++ This bug was initially created as a clone of Bug #626792 +++
Opening against gnome-terminal since I'm not sure what actually broke this...
"Alt + numberkey" combinations no longer seem to work in gnome-terminal. Usually when you run gnome-terminal with bash, hitting alt + 1 will give you output like this:
...as of a recent yum update, it just prints out '1'. The alt key seems to be ignored. This breaks a number of apps running within gnome-terminal.
--- Additional comment from firstname.lastname@example.org on 2010-08-24 11:04:46 EDT ---
Not just Alt+number - by any other key as well...
This makes usage of text editors or 'mc' quite painful in gnome-terminal.
Xterm works normally.
In fact it's a bug of 'vte' package vte-0.25.90-1.fc15.
Revert to version:
Fixes issue for this moment.
--- Additional comment from email@example.com on 2010-08-24 15:12:20 EDT ---
Should be fixed in the updates, or will be fixed soon. Already fixed upstream. There's a dup bug around.
--- Additional comment from firstname.lastname@example.org on 2010-08-24 19:15:35 EDT ---
Confirmed... I don't see a newer vte package in koji, but downgrading vte fixed the issue.
Changing to a vte bug.
--- Additional comment from email@example.com on 2010-08-30 09:09:51 EDT ---
Still no fixed package in koji. Can you push out an update for this soon? It makes gnome-terminal essentially useless.
--- Additional comment from firstname.lastname@example.org on 2010-09-01 07:53:21 EDT ---
Seems to be fixed as of this morning's update (vte-0.25.91-1.fc14.x86_64)
--- Additional comment from email@example.com on 2010-09-24 06:56:31 EDT ---
Why is this bugzilla still open?
--- Additional comment from firstname.lastname@example.org on 2010-09-24 07:17:10 EDT ---
Good question. It has been fixed for some time.
--- Additional comment from email@example.com on 2011-06-24 09:31:36 EDT ---
I've upgraded with preupgrade from Fedora 13 to Fedora 14 recently. With the current vte-0.26.1-1.fc14 I can still reproduce this bug 100% times.
I have to downgrade to vte-0.25.1-2.fc14 for fix.
--- Additional comment from firstname.lastname@example.org on 2011-11-26 15:18:08 EST ---
I am seeing a bug like this right now on Fedora 16 using:
I found similar bugs with Google:
--- Additional comment from email@example.com on 2011-11-26 22:50:14 EST ---
Happens to me too.
That bug was previously fixed long time ago, and it’s now broken again, in vte3 I think.
--- Additional comment from firstname.lastname@example.org on 2011-11-27 21:48:47 EST ---
Seeing this on F16 in g-t (vte3) and roxterm (vte)
--- Additional comment from email@example.com on 2011-11-28 04:02:44 EST ---
I'm seeing this since updating to vte-0.28.2-1.fc16 (vte3 was updated to vte3-0.30.1-2.fc16 two weeks earlier without adverse effects). This is quite unfortunate, as this makes it less easy to use irssi effectively.
--- Additional comment from firstname.lastname@example.org on 2011-11-28 04:10:03 EST ---
esh, I'm also seeing this now in f16 on updates-testing:
As JHM mentioned, it seems like the vte update (rather than vte3) is the culprit
--- Additional comment from email@example.com on 2011-11-28 04:16:52 EST ---
well, downgrading vte to 0.28.1 didn't seem to fix it, and gnome-terminal uses vte3 anyway:
[bpowers@fina ~]$ cat /proc/**/maps | grep vte
3f6d000000-3f6d09b000 r-xp 00000000 fd:00 3708245 /usr/lib64/libvte2_90.so.9.3000.1
3f6d09b000-3f6d29b000 ---p 0009b000 fd:00 3708245 /usr/lib64/libvte2_90.so.9.3000.1
3f6d29b000-3f6d29d000 r--p 0009b000 fd:00 3708245 /usr/lib64/libvte2_90.so.9.3000.1
3f6d29d000-3f6d2a1000 rw-p 0009d000 fd:00 3708245 /usr/lib64/libvte2_90.so.9.3000.1
7fe7a7e84000-7fe7a7e85000 r--p 00000000 fd:00 5638469 /usr/share/vte/termcap-2.90/xterm
so I don't think that was the issue. I'm at a bit of a loss on this one.
--- Additional comment from firstname.lastname@example.org on 2011-11-28 04:24:17 EST ---
through process of elimination, it seems that gtk3 is the cause of the breakage: https://admin.fedoraproject.org/updates/FEDORA-2011-16356/gtk3-3.2.2-1.fc16 (downgrading gtk3 to 3.2.1-1 enabled me to use the 'alt' key again).
--- Additional comment from email@example.com on 2011-11-28 04:32:35 EST ---
its most likely fallout from this commit: http://git.gnome.org/browse/gtk+/commit/?h=gtk-3-2&id=273283db9217960970810e90ef841f685231484a
--- Additional comment from firstname.lastname@example.org on 2011-11-28 12:48:29 EST ---
*** Bug 757795 has been marked as a duplicate of this bug. ***
--- Additional comment from email@example.com on 2011-11-28 12:57:43 EST ---
fwiw, I still see this even after downgrading to gtk3-3.2.1-1.fc16.x86_64
--- Additional comment from firstname.lastname@example.org on 2011-11-28 13:07:38 EST ---
The other Alt key (Alt Gr, on the right of the spacebar) seems to work for me.
--- Additional comment from email@example.com on 2011-12-02 04:08:56 EST ---
For vte there's a patch available in https://bugzilla.gnome.org/show_bug.cgi?id=663779 .
For testing purposes, I've build a vte package with this patch applied, see
This makes irssi in xfce's Terminal work for me again.
--- Additional comment from firstname.lastname@example.org on 2011-12-02 04:09:41 EST ---
*** Bug 759128 has been marked as a duplicate of this bug. ***
--- Additional comment from email@example.com on 2011-12-02 20:14:16 EST ---
(In reply to comment #20)
> For testing purposes, I've build a vte package with this patch applied, see
> This makes irssi in xfce's Terminal work for me again.
I confirm this fixes the issue for me.
--- Additional comment from firstname.lastname@example.org on 2011-12-02 20:50:02 EST ---
I can't live without alt-d for forward-word-delete in bash.
"yum downgrade gtk2 gtk2-immodule-xim" restored my precious alt-d for now. Will be --excluding gtk2\* updates until I see an update with the fix.
--- Additional comment from email@example.com on 2011-12-03 10:22:37 EST ---
There seems a bit of confusion, so allow me to summarize:
1. We are facing two different bugs although the symptoms are the same. The bug one from 2010 and F14 is not what we are facing now in F16.
2. The old bug should be fixed.
3. The nex bug was introduced by the gtk2-2.24.8-2.fc16 update, or to be more precise by this commit: http://git.gnome.org/browse/vte/commit/?id=b73782a28894e25ed146271f9d6c6775a6836199
4. The commit makes sense but requires a change in vte, too. There is a bug for this open at https://bugzilla.gnome.org/show_bug.cgi?id=663779
5. There is a patch available at https://bugzilla.gnome.org/attachment.cgi?id=201649 and it is confirmed to fix the issue.
6. As this bug affects all vte based terminals (Xfce's terminal, lilyterm, sakura, termit) we need a fix ASAP.
--- Additional comment from firstname.lastname@example.org on 2011-12-03 10:36:45 EST ---
(In reply to comment #24)
> 3. The nex bug was introduced by the gtk2-2.24.8-2.fc16 update, or to be more
> precise by this commit:
Is this really a good change? I see Xfce now gets confused about key sequences such as ctrl+alt+del becomes primary+alt+del.
I'd say this change wasn't carefully tested and should be reverted.
--- Additional comment from email@example.com on 2011-12-03 11:19:28 EST ---
*** Bug 759522 has been marked as a duplicate of this bug. ***
--- Additional comment from firstname.lastname@example.org on 2011-12-06 11:47:36 EST ---
*** Bug 760605 has been marked as a duplicate of this bug. ***
--- Additional comment from email@example.com on 2011-12-08 11:33:01 EST ---
Thomas's rpm's in comment 20 have been working fine for me for the last week with no noticable side-effects.
--- Additional comment from firstname.lastname@example.org on 2011-12-10 11:27:09 EST ---
*** Bug 766132 has been marked as a duplicate of this bug. ***
--- Additional comment from email@example.com on 2011-12-12 04:47:11 EST ---
After last update (probably gtk3), I am getting same behaviour in gnome-terminal which worked previously fine. Xterm still works for me.
--- Additional comment from firstname.lastname@example.org on 2011-12-12 06:09:23 EST ---
Yes, me too, may be it's related to:
--- Additional comment from email@example.com on 2011-12-12 06:11:03 EST ---
This bug imho is a nice example why bugzilla sometimes is a misleading and confusing tool. We *afaics* talk about one or two bugs in two different places:
- one seems in vte -- the responsible component marked in buzilla since a few days. I assume it can be worked around with the packages from thm (see comment #20)
- one seems to be in the stack that gnome-termial depends on -- that was the assigned component earlier [ and this is why I'm here ;-) ]
Not to mention that this bug was initially for a older release and then reopened, which adds to the confusion. And maybe my comment will lead to even more confusion now, even if I hope it avoids some of it
--- Additional comment from firstname.lastname@example.org on 2011-12-12 07:48:34 EST ---
Cloned this for vte3. See bug 766607.
--- Additional comment from email@example.com on 2011-12-12 09:55:45 EST ---
I got bit by this this morning in my gtk3-using ROXTerm after upgrading to gtk3-3.2.2-2.fc16.x86_64.
--- Additional comment from firstname.lastname@example.org on 2011-12-12 11:14:19 EST ---
(In reply to comment #33)
> Cloned this for vte3. See bug 766607.
As you mention in that bug, reverting gtk3 solves the problem, and I think that's the way to go. Sure, all the users of this, like vte should be fixed, but this change should not be rolled out _until_ all those are fixed.
The important thing is not to break user-experience, which currently is broken, and reverting is the safest way to do that. In fact, I say this should be patched in the newest versions of gtk3, so we don't get stuck, and only remove the patch in rawhide, that's were people should be testing this kinds of stuff.
--- Additional comment from email@example.com on 2011-12-13 12:03:37 EST ---
Ran into this when I updated last night (F16 x86_64 on Dec. 12, 2011). Downgraded and got the <alt> key back;
yum downgrade gtk3 gtk3-immodule-xim
(gtk3 + anything it depends on, gtk3-immodule-xim in my case, gtk3-devel, etc)
--- Additional comment from firstname.lastname@example.org on 2011-12-13 16:50:45 EST ---
*** Bug 759471 has been marked as a duplicate of this bug. ***
--- Additional comment from email@example.com on 2011-12-13 16:53:07 EST ---
updates-testing now has vte-0.28.2-2.fc16.i686 for which I can confirm that it fixes the problem
--- Additional comment from firstname.lastname@example.org on 2011-12-14 00:58:40 EST ---
I can confirm, that vte-0.28.2-2.fc16.i686 fixes roxterm problem.
--- Additional comment from email@example.com on 2011-12-14 12:30:39 EST ---
unfortunately behaviour for gnome-terminal hasn't changed with 0.28.2-2.fc16
--- Additional comment from firstname.lastname@example.org on 2011-12-14 13:12:36 EST ---
(In reply to comment #40)
> unfortunately behaviour for gnome-terminal hasn't changed with 0.28.2-2.fc16
You are at the wrong bug. You are looking for bug 766607 -- gnome-terminal uses vte3, not vte. You need to update to vte3-0.30.1-3.fc16 from updates-testing to fix gnome-terminal.
Created attachment 547177 [details]
Revert to old behavior
This patch should make the issue go away.
The problem should be fixed in current updates.
(In reply to comment #2)
> The problem should be fixed in current updates.
No, it's not. The above patch is not applied, only vte* was patched, and who knows what else must be broken... But whatever, I don't care any more, I'm not using Fedora any more.
I can confirm that this problem was fixed for me a while ago, whenever the updates landed.
Felipe, you issue may be something different, if you're still having problems. Are you sure you're running all the latest updates?
(In reply to comment #4)
> I can confirm that this problem was fixed for me a while ago, whenever the
> updates landed.
Yes, the vte updates, which means your issue was with terminals.
> Felipe, you issue may be something different, if you're still having problems.
> Are you sure you're running all the latest updates?
No, I don't have any _real_ issues, they are mostly _theoretical_, and they wouldn't be related to terminals (or rather anything that uses vte), but anything else that uses GDK_MOD1_MASK.