JDK1.2.1-H build : Alt+menmonic char not working when menu & menuitem have same mnemonic char. This happens only on Windows platforms. Worked fine in JDK1.2.1-G build.

Steps to simulate the problem,
1. Run the attached program.
2. There are 2 menus, 1 - First Menu and 2 - Second Menu. First Menu has menmonics for menuitems also. Second Menu does not have mnemonics set for menuitems
3. Pressing Alt+1 does not drop down the list of menuitems.
4. Pressing Alt+2 drops down the list of menuitems.

--- Sample Code ---
import java.awt.*;
import java.util.*;
import javax.swing.*;
import java.awt.event.*;
import javax.swing.border.*;

public class Bug extends JFrame {
	public Bug() {
		Container content = getContentPane();
		content.setLayout(new BorderLayout());
		content.add("North", createMenuBar("1 - First Menu", true));
		content.add("South", createMenuBar("2 - Second Menu", false));
		pack();
		show();
	}
	
	public JMenuBar createMenuBar(String str, boolean bFlag) {
		JMenuBar menubar = new JMenuBar();
		JMenuItem menuitem;
		
		JMenu menu = new JMenu(str);
		menu.setMnemonic(str.charAt(0));
		
		menubar.add(menu);
		for(int i = 0; i < 10; i ++) {
			menuitem = new JMenuItem("JMenuItem" + i);
			if(bFlag)
				menuitem.setMnemonic('0' + i);
			menu.add(menuitem);
		}
		return menubar;
	}

	public static void main(String argv[]) {
		new Bug();
	}
}

--- Sample Code ---




I'm concerned that, in JDK 1.2.2RC, bug 4127078 is still not 
fixed. In a previous correspondence, you informed me that this
behavior is covered under bug 4186905, which is marked fixed 
in a "non-public-release." 

While much of the behavior described in bug 4186905 now appears 
to be working, I hope that bug 4127078 hasn't slipped through
the cracks.

Here's what you wrote me in a previous release.

"Thanks for your report. Believe me, we know this
is still a problem. The reason there may be 
confusion re. the state of some bugs is that the 
problem appears to be getting worked on under bug
# 4186905. It is definitely the same problem. 
Sorry this still exists in the current release,
but I want to assure you that this bug has a high
priority."

If JDK 1.2.2 gets released without this fix (I hope, that doesn't
happen) please consider reopening bug 4127078.
(Review ID: 84626)
======================================================================
 xxxxx@xxxxx  2000-12-18
The test name of one of the included bugs is Regression test:
javax/swing/JMenu/4213634/bug4213634.java from bug 4376660

|-*-*-*-|-*-*-*-|-*-*-*-|-*-*-*-|-*-*-*-|-*-*-*-|-*-*-*-|-*-*-*-|

 xxxxx@xxxxx  2001-02-02
The regression test that demonstrates this failure:
javax/swing/JMenu/4213634/bug4213634.java
Was successfully fixed with Ladybird as of b14 but still fails with Merlin b50.
I'm resetting this bug to NYI for the Merlin verification failure.

N/A

This happens because the PostAction is triggered on keyPressed, posting
the menu, but the mnemonic handling happens on keyTyped.  Since the
menu has already opened, the keyTyped processing finds the mnemonic
for the item on the open menu and activates it.  
 xxxxx@xxxxx  1999-05-13

This problem is not completely fixed.  It still occurs intermittently.
 xxxxx@xxxxx  1999-08-18

It works correctly on Solaris, but fails on Windows.  My guess is that 
there is a difference in event delivery order on the two platforms.
 xxxxx@xxxxx  1999-10-11

The original bug listed here is fixed in kestrel.  Although things fail now in
a different way and just on Windows, this new failure is covered by bug 4246725
 xxxxx@xxxxx  1999-10-13


This bug is bounced back from integrated state, because this bug still happens in Kestrel FCS-O build on Win NT.

 xxxxx@xxxxx  1999-11-15

I've tested this on RC2 and it doesn't happen as often although it may show up intermittantly. However, this bug does not appear at all in the latest Merlin build for Windows (JDK 1.4.0.alpha-B). I closed out 4313287 with the same diagnostics.
 xxxxx@xxxxx  2000-03-08

In order to verify this, Mukund and I checked the attached code with the latest Merlin release (build 1.4.00beta-D), and it still happens intermittently, so I'm changing the status of this bug to Fixed.
 xxxxx@xxxxx  2000-03-17

It seems that this bug has regressed since my last evaluation. I closed 4329287 as a duplicate of this bug. You may want to take a look at the test case for that bug since I can reproduce Problem 1 (this bug) with that case consistently with 1.4 beta 12 on Win32 only. It doesn't appear on Solaris at all. I think we may be chasing our tail and this could be a focus or an AWT bug. Anyway, it's still a bug which isn't fixed so I'm rolling back this bug from fixed. Yuck!
 xxxxx@xxxxx  2000-05-15

Georges original evaluation is correct, unfortunately the fix was not the best. The selection was changed (and requestFocus issued) via an invokeLater. The problem with this approach is that you are not guaranteed the key typed will be dispatched before the invokeLater Runnable has been processed. This is why the bug manifests itself intermitantly, it depends upon what is happening on your processor at that moment. For example, it happens consistantly on a 350Mhz pentium running '98, but not on a 360Mhz Ultra or dual 450Mhz pentium running NT.
The best way to fix this is to select, and give focus to, the menu right away and have JMenu eat the next key typed event. With the current architecture such a fix is not possible. JMenu overrides processKeyEvent and passes the call off to the MenuSelectionManager before JComponent.processKeyEvent is invoked, so that there is not a conveniant way to consume the typed event so that the menuitem doesn't see it. Of course we could add some API to JMenu to accomodate this, but it really starts to feel hacky to have to add this sort of API to eat the next event.
On the positive side, the new focus infrastructure is nearing completion and will soon be added. With this architecture it is possible to see KeyEvents before other components do (via the KeyEventDispatcher). As such, BasicMenuUI.PostAction.actionPerformed should do the following (assuming force is true):

 . change the selection immediately
 . If the menu has focus, add a KeyEventDispatcher to the KeyboardFocusManager
 . The KeyEventDispatcher will eat the next typed event, assuming it is
   targeted at the JMenu, and remove itself from the KeyboardFocusManager.

We will have to investigate step 3, we may consider eating all events until a key release is seen.
 xxxxx@xxxxx  2000-08-16

After investigating the problem some more, we have come up with a simpler solution that does not require the new focus API. The basic idea is to only create MenuKeyEvents if a KEY_PRESSED event has been received and the JMenu is selected. This will be accomplished by doing the following:

Add the following to JMenu:

    /**
     * Set to true when a KEY_PRESSED event is received and the menu is
     * selected, and false when a KEY_RELEASED (or focus lost) is received.
     * If processKeyEvent is invoked with a KEY_TYPED or KEY_RELEASED event,
     * and this is false, a MenuKeyEvent is NOT created. This is needed to
     * avoid activating a menuitem when the menu and menuitem share the
     * same mnemonic.
     */
    private int receivedKeyPressed;

Conditionally dispatch to the MenuSelectionManager in JMenu.processKeyEvent, by changing the code to:

        boolean createMenuEvent = false;
        switch (e.getID()) {
        case KeyEvent.KEY_PRESSED:
            if (isSelected()) {
                createMenuEvent = receivedKeyPressed = true;
            }
            else {
                receivedKeyPressed = false;
            }
            break;
        case KeyEvent.KEY_RELEASED:
            if (receivedKeyPressed) {
                receivedKeyPressed = false;
                createMenuEvent = true;
            }
            break;
        default:
            createMenuEvent = receivedKeyPressed;
            break;
        }
        if (createMenuEvent) {
            MenuSelectionManager.defaultManager().processKeyEvent(e);
        }


Reset the receivedKeyPressed when focus is lost:

    protected void processFocusEvent(FocusEvent e) {
        switch(e.getID()) {
          case FocusEvent.FOCUS_LOST:
              receivedKeyPressed = false;
              break;
        default:
            break;
        }
        super.processFocusEvent(e);
    }

And replacing the following code in
BasicMenuUI.PostAction.actionPerformed:
		    SwingUtilities.invokeLater(new Runnable() {
			public void run() {
			    defaultManager.setSelectedPath(me);
			}
		    });

with:

                    defaultManager.setSelectedPath(me);

 xxxxx@xxxxx  2000-09-15

I am moving this back to integrated into merlin-beta. The regression test is bogus and needs to be updated. The regression test was updated for ladybird, but not merlin. I will integrate that in next putback.
 xxxxx@xxxxx  2000-12-19

Despite their claim that this is fixed, it's still
a problem. It is now covered by bug 4246725.

Quote from above evaluation: "... and it still happens intermittently, 
so I'm changing the status of this bug to Fixed."

Say what?!?

I'd like to expand on the behavior of the above sample program when Alt+1
is pressed.  Not only does this not drop down the list of menuitems
as step 3 above indicates.  It ALSO INVOKES JMenuItem1 in FirstMenu.
This can be very upsetting to users of a program - depending on just
what "JMenuItem1" does.

This can be seen by adding the following line to the 'for' loop:

      menuitem.addActionListener(new MyActionListener(i));

where 'MyActionListener' is defined as:

class MyActionListener implements ActionListener {
    
    int itemNumber;
    
    MyActionListener(int i) {
        itemNumber = i;
    }
    
    public void actionPerformed(ActionEvent e) {
        System.out.println("JMenuItem " + itemNumber + " invoked");
    }
}

This is not intermittent behavior on my platform.  It's very consistent.
I'm using Sun's 'Classic VM build JDK-1.2.2-001...' on WinNT service pack 5 to 
produce this behavior.

Please don't mark this bug as Fixed until it really is!