Do accellerators work for you in other GNOME programs?
Are you sure it is not a translation problem?

Yes, works for other applications, only gedit does not work.

I cannot reproduce it.
Which is your locale?

also, do you use an input method? My blind guess is that the input method steals alt+F before the menu.

My locale is zh_CN.UTF-8, and I use fcitx as my IME, 
but I can use the menu short cut for other gnome application.

Are shortcuts for the other applications working also when a text widget is focused? Are you sure it is not a translation problem?

yes, I tried this in gnumeric, sylpheed and some others applications, I don't think it is an translation problem because it works on gedit 2.12.x

I removed the Chinese mo file, then start gedit, it shows its UI with English, but the short cut key for menu still doesn't work.

Another information is I can't activate my IME which is fcitx, I can activate fcitx in the file open/save dialog in gedit but can not activate it in gedit. 

Looks like all menu keynav may bve broken in gedit: 

From a Sun-internal bug report, regarding loss of menu keyboard navigation in gedit:

-------8<---------

Found the root reason in gedit-window.c:218
/*
 * GtkWindow catches keybindings for the menu items _before_ passing them to
 * the focused widget. This is unfortunate and means that pressing ctrl+V
 * in an entry on a panel ends up pasting text in the TextView.
 * Here we force events to be first  passed to the focused widget and then
 * we chain up the default handler... this is the opposite of Gtk default
 * behavior so we need to keep an eye open to see if anything breaks.
 */
static gboolean
gedit_window_key_press_event (GtkWidget   *widget,
                              GdkEventKey *event)
{       GtkWidget *focused_widget;
        gboolean handled = FALSE;

        focused_widget = gtk_window_get_focus (GTK_WINDOW (widget));

        if (focused_widget)
        {
                handled = gtk_widget_event (focused_widget,
                                            (GdkEvent*) event);
        }

        if (handled)
                return TRUE;
        else
                return GTK_WIDGET_CLASS (gedit_window_parent_class)->key_press_event (widget, event);
}

focused_widget will catch the key event first, successfully handle it and return handle=true, then menu widget never can't catch the event again. From the comment, it seems in previous realization, it's different here.

Looks like all menu keynav may bve broken in gedit: 

From a Sun-internal bug report, regarding loss of menu keyboard navigation in gedit:

-------8<---------

Found the root reason in gedit-window.c:218
/*
 * GtkWindow catches keybindings for the menu items _before_ passing them to
 * the focused widget. This is unfortunate and means that pressing ctrl+V
 * in an entry on a panel ends up pasting text in the TextView.
 * Here we force events to be first  passed to the focused widget and then
 * we chain up the default handler... this is the opposite of Gtk default
 * behavior so we need to keep an eye open to see if anything breaks.
 */
static gboolean
gedit_window_key_press_event (GtkWidget   *widget,
                              GdkEventKey *event)
{       GtkWidget *focused_widget;
        gboolean handled = FALSE;

        focused_widget = gtk_window_get_focus (GTK_WINDOW (widget));

        if (focused_widget)
        {
                handled = gtk_widget_event (focused_widget,
                                            (GdkEvent*) event);
        }

        if (handled)
                return TRUE;
        else
                return GTK_WIDGET_CLASS (gedit_window_parent_class)->key_press_event (widget, event);
}

focused_widget will catch the key event first, successfully handle it and return handle=true, then menu widget never can't catch the event again. From the comment, it seems in previous realization, it's different here.

Well, while removing that function would 'fix' the problem, it would break other things: what we need to find out is *who* is handling that keypress.

Let's say for instance that the culprit is an input method: removing that function would fix the menus, but break the input method itself since the keypress would not be passed to it.

To me it makes perfect sense that the first to handle the keypress is the focused widget and in particular the textview and only if the keypress is not handled by it then we look in the menu. For instance this fixed a long standing bug with emacs-keybindings gtk preference, where shortucts like ctrl+A where handled by the menu instead of triggering the corresponding emacs command despite the preference being set.

(btw sorry, we already knew that that function was involved, we should have had noted it here with the above explanation in order to save you some debugging)

Apologies for spam-- marking AP1 to reflect accessibility impact.

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

Hi, This bug still exists in the latest version of gedit, I think this is a very serious problem for guys who use zh_CN.UTF-8 locale to work. 

I don't find this issue in any other application what ever they written by gtk+ or gnome. 

So can someone tell me what is the progress about this issue?

Thanks all.

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

We have no clue on how to solve this problem in a sane way.
May be we should ask help to the gtk+ guys.

Any volunteer to find a sane solution for this bug?

Could you please try to disable the input method and tell us if it works?
May be your input method is stealing Alt+F (and the other key press event) before the menu.

-----------------------

<paolo> mclasen: hi, any clue on how to fix bug #331369?
<mclasen> paolo: you get what you ask for, imo
<mclasen> if you take the key event and let it be handled by some widget, then it cannot be used to activate the menu...
<paolo> well, what I cannot understand is why we have the problem only on some locale
<paolo> it the text view does not handle the event, then the menu should be activate
<paolo> and this is what we have in most locales
<paolo> if you see, user is trying to activate the menu with "Alt+F" and AFAIK GtkTextView does not handle Alt+F
* paolo is wondering if the input method is stealing ALT+F before the menu
<mclasen> I guess if you feed the event to the text view, it asks the input method 
<mclasen> and if the input method considers it appropriate to handle Alt-f or just does not care to check the modifiers
<mclasen> ...
<pbor> yes, as noted in the bug I think that's the cause
<paolo> well, if the input method is eating events it does not really manage, I'd consider it a IM bug
<pbor> and making the menu take precedence on the textview is not really a fix since it would break the IM in case it was really using one of those key combination

-----------------------

This is not a XIM problem, since I can do this well at any other gnome program. 

Before 2.15 of gedit, it works. 

My locale setting is zh_CN.UTF-8, seems this problem is related to the locale setting, when I switched to en_US, it works again, but that is not what I wanted. 

> This is not a XIM problem, since I can do this well at any other gnome program. 

Actually that doesn't prove anything: as explained above gedit makes sure that key are first processed by the textview. This is not the default and other gnome programs do not do that, but it makes sense and fixes other separate issues. If the IM is handling key combinations it should not handle, then it is a IM bug.

hmmm... you said that when you switched to en_US gedit is working. Are you using XIM with en_US?

Could you please explain me how to install/configure/use XIM with gedit so that I can investigate the problem?

Note that I know very little about Input Methods and how to use them so please explain me also the obvious things. 

If some developer looking at this bug and that knows XIM want to help me it will be very cool.

I am seeing this on Solaris without using an interesting locale

How about adding the following code before call to gtk_widget_event()
                handled = gtk_window_activate_key (GTK_WINDOW(widget), event);
                if (handled)
                        return TRUE;

This happens in openSUSE 10.2 with *all* locales. gedit 2.16.1, gtk+ 2.10.3
https://bugzilla.novell.com/show_bug.cgi?id=208679

Dan, I don't think is an issue with the locale, however can you check if any input method is active?
As said in the above discussion with mclasen our guess is that is the input method that intercepts the short cuts.

If that's not the case, some investigations of where the key press gets eaten would be very appreciated.

I can ensure that this problem is not XIM related, with the same locale setting, XIM works fine in leafpad, but not work in gedit and gvim, so I think there are some problems with these applications, in some cases they catch the key press event. 

anyway, in en_US settings without XIM, the short cut works. 

(In reply to comment #24)
> Dan, I don't think is an issue with the locale, however can you check if any
> input method is active?

Huh... ok, apparently we are patching the default input method to "X Input
Method" rather than "Default". (Although there is no actual X Input Method
running.) Full story at
https://bugzilla.novell.com/show_bug.cgi?id=131498. It looks like that patch
can be reverted now though (although of course, people actually using XIM
would still lose).

Younker: as explained above, gedit makes sure that the event is passed to the Text  widget *before* the GtkWindow. This is not the deafult in gtk (that's why you don't see the issue in leafpad), but it is *intentional*. This is required so that combination like ctrl+V in a sidepane entry do not paste in the main textview. In fact if we didn't do that, a key combo which is a *real* input method combination, but also a menu shortcut would trigger the menu, which is IMHO a problem.

To sum it up this is a bug in XIM: it should *not* eat key combos it doesn't need. The fact that the gtk default behavior hides this, just made the bug less noticeable.

So, yeah, gtk_im_context_xim_filter_keypress() is claiming the event, because
XmbLookupString() succeeds even when Alt is down. It seems like either
XmbLookupString is broken, or else GtkIMContextXIM is supposed to know to not
call it if Ctrl/Alt are pressed?

(In reply to comment #21)
> Could you please explain me how to install/configure/use XIM with gedit so that
> I can investigate the problem?

All you have to do is right-click on the main textview, and choose Input
Methods -> X Input Method. You don't need to configure anything else.

> So, yeah, gtk_im_context_xim_filter_keypress() is claiming the event, because
> XmbLookupString() succeeds even when Alt is down. It seems like either
> XmbLookupString is broken, or else GtkIMContextXIM is supposed to know to not
> call it if Ctrl/Alt are pressed?

I've confirmed that XmbLookupString() with "Alt-f" does return 1 for num_bytes and "f" for the character buffer.  This makes return value of gtk_im_context_xim_filter_keypress() TRUE.

In contrast,  XmbLookupString() with "Ctrl-f" return 1 and the character 0x6, which result in return FALSE in gtk_im_context_xim_filter_keypress(), and gedit properly shows Find dialog.

Thus the bug is not in XIM server itself, but in gtkimcontextxim.c.  I think gtk_im_context_xim_filter_keypress() must check accelerator mod_mask except for Control and Shift mask.  Here is the workaround, and I'll file a bug in GTK+ later.

--- gtkimcontextxim.c.orig      2005-07-01 03:42:44.000000000 +0900
+++ gtkimcontextxim.c   2006-11-21 07:50:16.000000000 +0900
@@ -705,6 +705,7 @@
   Status status;
   gboolean result = FALSE;
   GdkWindow *root_window = gdk_screen_get_root_window (gdk_drawable_get_screen (event->window));
+  guint accel_mod_mask;

   XKeyPressedEvent xevent;

@@ -728,6 +729,10 @@
   if (XFilterEvent ((XEvent *)&xevent, GDK_DRAWABLE_XID (context_xim->client_window)))
     return TRUE;

+  accel_mod_mask = gtk_accelerator_get_default_mod_mask() & ~(GDK_CONTROL_MASK | GDK_SHIFT_MASK);
+  if (event->state & accel_mod_mask)
+    return FALSE;
+
  again:
   if (ic)
     num_bytes = XmbLookupString (ic, &xevent, buffer, buffer_size, &keysym, &status);

It found this is already filed in GTK+ bug #335796.

*** This bug has been marked as a duplicate of 335796 ***