Another bug introduced by 6u10 ?

Question

Here is another possible bug introduced by 6u10. Looks like that the feature of ‘setLookAndFeel’ under 6u10 breaks Mouse Listener.
See the short test program below, which works fine under 6u7 but fails under 6u10.
Here are the test steps :
1.     Click on ‘menu’ but don’t click on any menu items.
2.     Move mouse to the white area (JPanel)
3.     Click mouse once. Nothing happens but it should draw a red dot. The mouse listener does not recognize the first click. The subsequent clicks are fine.
If you perform this test under 6u7, it works fine ( recognize the first mouse click) . If you take out setLookAndFeel, it works fine also. Anyone knows a workaround.
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;      
public class MouseClickTest  extends JFrame
     static int sxw=800;
     static int sxh=800;
     int mx, my;
     JPanel jpl;
     public MouseClickTest()
          init();
     private void init()
          jpl =new JPanel()
               public void paintComponent(Graphics g)
                    Graphics2D g2=(Graphics2D) g;
                    g2.setColor(Color.white);
                    g2.fillRect(0,0,800,800);
                    if ( mx > 0 && my > 0 )
                         g2.setColor(Color.red);
                         g2.fillOval(mx,my, 20,20);
          jpl.setPreferredSize(new Dimension(sxw, sxh));
          jpl.addMouseListener(new MouseAdapter(){
          public void mousePressed(MouseEvent e)
               mx=e.getX();
               my=e.getY();
               jpl.repaint();
          JMenuBar mb = new JMenuBar();
                  JMenu menu = new JMenu("menu");
                  for(int i=0; i<5; i++)
               menu.add(new JMenuItem("Item "+i));
                  mb.add(menu);
          setJMenuBar(mb);
          getContentPane().setLayout(new BorderLayout());
          getContentPane().add(jpl, BorderLayout.CENTER);
          setSize(800,800);
          pack();
          setVisible(true);
           addWindowListener(new WindowAdapter() {
                 public void windowClosing(WindowEvent ev) {
                          System.exit(0);
     public static void main(String[] args)
          try {
               //this is ok.
               //UIManager.setLookAndFeel(UIManager.getCrossPlatformLookAndFeelClassName());
               //these are bad
               //UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
                         UIManager.setLookAndFeel("com.sun.java.swing.plaf.windows.WindowsLookAndFeel");
               //UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");
              catch (Exception e) {     }
          SwingUtilities.invokeLater(new Runnable()
                   public void run()
                    new MouseClickTest();
}

Answer 1

I can confirm that the behavior is different in 6u10. If a JMenu or JPopupMenu is displayed, and the user clicks on some other part of the GUI to hide the popup, that part of the GUI doesn't actually receive (or react to) a MouseEvent. If you click on an unselected tab, for example, that tab doesn't become the active tab, whereas in 1.5 and 1.4 (and according to the OP, 1.6 pre 6u10), it did.
Is this really a "bug"? I suppose it is. Native Windows appears to send mouse events to items when a popup menu is dismissed with a click. But why does your application rely on this behavior - that is, why is this change so serious to you?
Oh, and XOR painting isn't broken in 6u10, it's just unusably slow. :)