User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1) Build Identifier: version 2.0.0.0 (20070326) If the Japanese IME is active (for instance, if you have just finished sending an email in Japanese), the keyboard cannot be used to navigate menus by pressing the letters. For example, if I use the context-menu key in Windows to bring up the context menu for a mail item, pressing "k" does not open the Mark submenu. The key is totally ignored. This is because the IME is intercepting the k in order to convert into Japanese kana. Reproducible: Always Steps to Reproduce: 1. On system with Japanese IME, activate the IME (e.g. write an email in Kanji or Katakana, etc.) 2. Select a bunch of mail items in a mail folder 3. Press the "Context Menu" key on the keyboard. The context menu appears. 4. Attempt to press any of the underlined hotkeys for any menu item. Actual Results: The key presses appear to be ignored. (Actually, the Windows IME is intercepting and attempting to convert the keycodes into kana). Expected Results: The keypresses should open the appropriate submenus or execute the menu commands. Pressing the IME Activate/Deactivate key while the context menu is open at this point will deactivate the IME. The context menu will then behave as expected. This is a common problem with Windows software that is not IME aware. There are some simple Windows API calls that can be used to tell the IME not to convert to kana when a particular window (such as a context menu) has the focus. Also, the windows KEYDOWN events are not intercepted by the IME, so they can be used by the context menu.

dupe of bug 55751 (which is already fixed on the trunk version) ?

If you look down to comment 85 of bug 55751, it seems that the bug was not ever truly fixed (or at least, the reported bug was fixed but variations on the theme - such as in my situation - were not fixed). There do not appear to be any other open bugs for this problem, but the problem listed in comment 85 would appear to stem from the same root cause.

This is dup of bug 375752 which was fixed on Gecko1.9.0.