JDK-6531406 : Mouse pointer remains to TextCursor when mousepointer is on the MenuItem.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2007-03-06
  • Updated: 2011-01-28
  • Resolved: 2011-01-28
Related Reports
Relates :  
Relates :  
Relates :  
Description
I have a frame, which has a menu & a textarea. When i move the mouse pointer on the textarea the cursor is text cursor , which is the correct behaviour. I move the mouse pointer just below the menubar & press F10 to invoke the menu & see the menuitem. When Menu items are visible the mouse pointer should change to default cursor, but this is not happening. This works fine in Mustang b70 , but fails after that. Hence its a regression because it works fine in tiger.

step to reproduce
---------------
1) Run the below program in Metal LookAndFeel & GTK LookAndFeel .
2) Move the mouse below the menubar. Observe that mouse cursor is text cursor.
3) Press F10  , Observe that menuitems are visible, but mouse cursor remain to textcursor. If you see the same then the bug is reproduced.
I tested this in jdk7.0 b09 on solaris ( sun ray ).

import javax.swing.*;

public class TestMenuCursor {
	public JFrame frame=null;	
	TestMenuCursor( ){
		frame = new JFrame();
		JMenuBar menuBar = new JMenuBar();
	    	JMenu menu = new JMenu("Menu Label");
		menuBar.add(menu);
	    	JMenuItem item1 = new JMenuItem("Praveen Mohan");
		JMenuItem item2 = new JMenuItem("Girish.R");
		JMenuItem item3= new JMenuItem("Lawrence Prem Kumar");
		JMenuItem item4= new JMenuItem("Lawrence Prem Kumar Lawrence Prem Kumar Lawrence Prem Kumar Lawrence");
		menu.add(item1);
		menu.add(item2);
		menu.add(item3);
		menu.add(item4);
		frame.getContentPane().add(new javax.swing.JTextArea());
	    	frame.setJMenuBar(menuBar);
		frame.setSize(400,400);
		frame.setVisible(true);
	}
	
	public static void main(String []args){
		new TestMenuCursor();
	}
}

Comments
EVALUATION It's defered couple times so most likely will never be fixed.
28-01-2011

EVALUATION Two ways for possible fix: 1. Ensure that grab is queried prior to creating a window for swing's menu. Here, grabbing is queried from swing's code. Thus, it might (not sure now) assume some undesirable changes in swing or even in grabbing on Windows. 2. Ignore Enter/LeaveNotify (EN/LN) marked with NotifyGrab/Ungrab (NG/NU) If EN/LN are caused not by "real" entereing/leaving, but by (un)grabbing, they are marked with different mode - NG/NU. Instead of NotifyNormal for "real" crossings. If we ignore EN/LN marked with NG/NU, this will make XAwtState track the hevayweight under mouse correctly, which will make cursor also become correct. But there're also some problems with this approach. Before fixing 6242833 and then 6404708, NG/NU crossing events were indeed ignored. And those fixes made those events be not ignored sometimes. So, we should be carefull here, to not introduce cyclic regression.
31-08-2007

EVALUATION Note on behavior: TextCursor is always incorrectly set for the first time menu is shown. After that sursor is set nondeterministically. Cause: On X, choosing cursor is based on tracking current heavyweight under mouse, which is queried from XAwtState, which maintains it according to EnterNotify and LeaveNotify native events. When swing's popup is shown, correct DefaultCursor case corresponds to receiving "exit content pane" event, then "exit frame", then "enter menu window". They make XAwtState think that current heavyeweight is menu window. Incorrect TextCursor case corresponds to receiving those 3 events above, followed by 3 "reverse" events: "exit menu window", "enter frame", "enter content pane". What's also important here, is that pointer is grabbed for showing swing's menu. When grab happens, we receive some "leave current window" and "enter grabber window" events. So that pointer "enters" grabber window regardless to if pointer is indeed over that window or not. Non-determinism comes from order (in time) of when pointer is grabbed, and when swing's menu (really!) appears under pointer. If pointer is grabbed first, we receive 3 above events, XAwtState "thinks" that mouse is over menu, and DefaultCursor is shown. If menu appears first, we receive 6 events, mouse is thought to be over content pane, and TextCursor is set.
31-08-2007

EVALUATION It's reproducible only on X, only with SWING classes, and not every time (though, regularly). Never I saw it happen with analogous AWT clasees on X, and never on Windows, with either AWT or SWING classes (though, I think Windows+AWT combination is irrelevant for this bug). It appears that cursor is set 3 times on each menu show/hide. Correct behavior corresponds to setting cursor to "text" on 1-st occasion, and then setting it to "default" on 2nd and 3rd occasions. Buggy behavior corresponds to the case, when all 3 times cursor gets set to "text".
03-07-2007

EVALUATION This is a platform-specific issue indeed I just reproduced it on Solaris i586 when it's not reproducible on Windows reassigned to AWT Interesting thing mouse cursor works correctly for lightWeight menus, only heavyweight ones don't update it properly you can check it by making a menu small enough to not overlap the frame's border
06-04-2007

EVALUATION I don't see the problem on Windows. Could this be platform specific, and an AWT issue?
28-03-2007