*** Bug 661822 has been marked as a duplicate of this bug. ***

Does your gnome-terminal print the symbol "~" on F10?

Yes, it prints "~".

I have this issue too.

Same problem here.

*** Bug 666959 has been marked as a duplicate of this bug. ***

It's not just the gnome-terminal. After setting gtk-menu-bar-accel to "" in 
settings.ini (this is what gnome-terminal do for itself) every gtk3 app shows the context menu on F10. Same with gtk2 and .gtkrc-2.0.

Why is this bug unconfirmed? It is confirmed many times.

Hi.

Not sure whether this is anyhow related (as it appeared before the xkb-data upgrade),... but perhaps you can also have a look at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656162

Thx,
Chris.

*** Bug 669935 has been marked as a duplicate of this bug. ***

Confirm. Same issue with terminator. "~" also printed after displaying right-click menu. In exaile it opens File menu. In empathy and pidgin it opens Contacts menu. In firefox 11 it displays menubar.

Confirm. This is very annoying, especially using mc in gnome-terminal.

My configuration:
Debian Sid, Gnome 3.4.1, gnome-terminal 3.4.1.1, gtk+ 3.4.1-2, xkb-data 2.5.1-1

downgrading xkeyboard-config to 2.3 helps here.

Could someone who is experiencing the problem try to bissect xk-c commits and find the one that breaks things?

Reverse applying this one solves the problem: http://cgit.freedesktop.org/xkeyboard-config/commit/?id=062b5bfcc59f9f6e4e11ba394bbe459af2a07b7e

I think it's already known what change caused the breakage, and the majority opinion is that GTK3 is still to blame despite the change in xkeyboard-config. See <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656685> and <https://bugs.freedesktop.org/show_bug.cgi?id=45008>.

So what happenens here in g-t is this:

Press F10 -> we get a "popup-menu" signal. 

Printing the stack trace, we see that gtk_widget_real_key_press_event () gets a GdkEventKey of type GDK_KEY_PRESS with keyval GDK_KEY_F10 and state 0 (ie *no* modifiers set). This event is then passed to gtk_bindings_activate_event() which ends up calling gtk_binding_entry_activate() for a GtkBindingEntry which has keyval GDK_KEY_F10 but modifiers GDK_SHIFT_MASK ! That is the binding for the 'popup-menu' signal which is therefore emitted, and we end up showing the context menu.

So this is clearly a gtk bug.

*** Bug 673739 has been marked as a duplicate of this bug. ***

*** Bug 677096 has been marked as a duplicate of this bug. ***

It looks like the patch below fixes the problem for me.  I'll be
testing it a little bit for a little while.

diff --git a/gtk/gtkwindow.c b/gtk/gtkwindow.c
index 1ebe497..4e2d788 100644
--- a/gtk/gtkwindow.c
+++ b/gtk/gtkwindow.c
@@ -9468,7 +9468,8 @@ gtk_window_activate_key (GtkWindow   *window,
             }
           else 
             {
-              if (enable_accels && !found_entry)
+              if (enable_accels && !found_entry
+		  && entry->modifiers == event->state)
                 {
 	          found_entry = entry;
                 }

Created attachment 217534 [details] [review]
Candidate Patchlet

Better add the patch as an attachment, it seems.

Created attachment 217536 [details] [review]
A better patch

This patch should be better.

I guess a similar approach should be taken (in the patch) for mnemonics as well.  Not only for accelerators.  I'll do that later.

*** Bug 681517 has been marked as a duplicate of this bug. ***

I just filed a bug about gnome-terminal not following the config checkbox for disabling F10 and it was marked as a dupe of this bug. I'm surprised to see that it's been nearly a year since the first report and it's still broken. Is there anything I can do to help speed up a fix? I can provide screens shots of the problem in gnome-terminal or maybe provide other info if someone knows what's needed. 

For someone who works in terminals all day and frequently uses MC, this bug is a major pain.

I also filed a bug report over in the RedHat database so maybe someone there will be able to figure out what's wrong and send a fix upstream.

 https://bugzilla.redhat.com/show_bug.cgi?id=847033

There is already a bug 800856 in RH bugzilla  covering this issue and it contains  a workaround - https://bugzilla.redhat.com/show_bug.cgi?id=800856#c4.

(In reply to comment #26)
> There is already a bug 800856 in RH bugzilla  covering this issue and it
> contains  a workaround - https://bugzilla.redhat.com/show_bug.cgi?id=800856#c4.
Unfortunatelly this workaround works only with xterm and does not with other terminals like Terminator (which IMHO is superior).

Jiří: thanks, I've seen the workaround but I'd rather see some progress towards a fix for the underlying problem.

*** Bug 681273 has been marked as a duplicate of this bug. ***

Review of attachment 217536 [details] [review]:

This patch is wrong - the problem is at a lower level.
With current xkeyboard-config, what is happening when you hit Shift-F10 is that XKB tells us that it consumed the Shift modifier to translate F10 into ... F10.
GTK+ ignores modifiers that have already been consumed by the X-level translation.

I've reopened https://bugs.freedesktop.org/show_bug.cgi?id=45008 and commented there.

(In reply to comment #17)
> So what happenens here in g-t is this:
> 
> Press F10 -> we get a "popup-menu" signal. 
> 
> Printing the stack trace, we see that gtk_widget_real_key_press_event () gets a
> GdkEventKey of type GDK_KEY_PRESS with keyval GDK_KEY_F10 and state 0 (ie *no*
> modifiers set). This event is then passed to gtk_bindings_activate_event()
> which ends up calling gtk_binding_entry_activate() for a GtkBindingEntry which
> has keyval GDK_KEY_F10 but modifiers GDK_SHIFT_MASK ! That is the binding for
> the 'popup-menu' signal which is therefore emitted, and we end up showing the
> context menu.
> 
> So this is clearly a gtk bug.

Here is what I see in gtkwidget.c:

  gtk_binding_entry_add_signal (binding_set, GDK_KEY_F10, GDK_SHIFT_MASK,
                                "popup-menu", 0);
  gtk_binding_entry_add_signal (binding_set, GDK_KEY_Menu, 0,
                                "popup-menu", 0);

So it is no wonder that you get a popup-menu signal for F10 with or without Shift...

Sorry, misread the second add call, ignore that comment.

The following fix has been pushed:
314b6ab Try harder to discriminate Shift-F10 and F10

Created attachment 223188 [details] [review]
Try harder to discriminate Shift-F10 and F10

A change in xkeyboard-config 2.4.1 made it so that function keys
now have a shift level which has the same symbol, but 'eats' the
shift modifier. This would ordinarily make it impossible for us
to discriminate between these key combinations.

This commit tries harder to discriminate in 2 ways:
- XKB has a mechanism to tell us when a modifier should not be
  consumed even though it was used in determining the level.
  We now respect such 'preserved' modifiers. This does not fix
  the Shift-F10 vs F10 problem yet, since xkeyboard-config does
  not currently mark Shift as preserved for function keys.
- Don't consume modifiers that do not change the symbol. For
  the function keys, the symbol on the shift level is the same
  as the base level, so we don't consider Shift consumed.

For more background on the xkeyboard-config change, see
https://bugs.freedesktop.org/show_bug.cgi?id=45008

xk-c fix pushed. Thanks again to Matthias!

*** Bug 682520 has been marked as a duplicate of this bug. ***

*** Bug 671562 has been marked as a duplicate of this bug. ***