JDK-5036146 : REGRESSION: problems with 1.5.0 action listeners
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.2,5.0,5.0u2,5.0u3
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux,solaris_8,solaris_9,windows_2000,windows_xp generic,linux,solaris_8,solaris_9,windows_2000,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 2004-04-22
  • Updated: 2005-09-20
  • Resolved: 2005-09-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u12Fixed 6 b53Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
The testcase in attachment (classes BUG15, CheckBugList, CheckListCellRenderer, CheckListener InstallData) has been extracted from a Sun internal application (openduty2) There is a JPanel added to the JMenu which has been created because it was needed a scrollbar to handle the long list of selectable items (support queues) loaded by the application
The application (openduty2) and the testcase BUG15 perfectly runs with 1.3.x and 1.4.x, but do not work with tiger beta2:

- cannot select more than one item
- cannot scroll
- cannot use buttons to execute any action

In the panel there is a long list of items which are support queues to be selected (in the testcase the list is simply long enought to have an automatic scrollbar, but in the real application it is often longer)
In the attached Screenshot.png you see the original application openduty2 (using acqua Theme) with some queues selected and the same panel in the testcase without any JCheckBox selected

The behaviour changes for check boxes and scroll pane using shift key while selecting or scrolling, but listeners do not receive any JButton action
To verify this behaviour instead of using only the mouse to click on JCheckBox,JButton and scrollbar, use SHIFTKey+MouseClick together on JCheckBox and on the arrows of the scrollbar (dragging scrollbar does not work)
Using SHIFTKey+MouseClick I can select more than one JCheckBox and use the scrollbar arrows: the JScrollPane perfectly moves.
The JButton(s) still do not work even with a SHIFTKey+MouseClick

The behaviour changes for check boxes if the opened JPanel is detached from the application (this is not possible in 1.4.x, but can be done in this testcase using 1.3.1) but JButton still do not work as expected
To verify this behaviour simply move the JPanel which can float in 1.5.0-beta2 in your desktop because, because it is no more linked to the JMenu ( is a new window) See the Screenshot.png where I've moved the panel in the testcase, but I cannot do that in the application when running with 1.4.2_0x, because it is attached to the JMenuBar. 

The look and feel is different using 1.3.x, 1.4.x and 1.5

The problems has been verified on Sol8 and Sol9 with gnome and CDE using java 1.5.0-beta2-b48, simply running: /usr/jdk/j2sdk1.5.0/bin/java -jar BUG15.jar
To run it with 1.3 you need to recompile the classes (see build13 script)

SUGGESTED FIX ------- BasicPopupMenuUI.java ------- *** /tmp/sccs.kcaOex Tue Jun 7 13:24:18 2005 --- BasicPopupMenuUI.java Tue Jun 7 13:11:02 2005 *************** *** 775,780 **** --- 775,783 ---- case MouseEvent.MOUSE_RELEASED: src = (Component)ev.getSource(); + if(!(src instanceof MenuElement)) { + break; + } if(src instanceof JMenu || !(src instanceof JMenuItem)) { MenuSelectionManager.defaultManager(). processMouseEvent((MouseEvent)ev); ###@###.### 2005-06-07 09:24:46 GMT

EVALUATION Name: sh120115Date: 04/22/2004 It is very odd to see a panel added to a JMenu like this. However, we should try and be backward compatible. I tried the submitter's test case on 1.5.0 and found the following: - cannot select more than one item * I don't understand what the submitter is talking about so wasn't able to test this - cannot scroll * verified that the scrollbar does NOT work - cannot use buttons to execute any action * Correct, NONE of the buttons work, and they remain pressed. I don't understand the comment about the behavior changing when using the SHIFT key. I also don't understand what is meant by detaching the JPanel from the application - how would I do this? In any case, I DO see a significant problem with mouse event delivery. Components in the popup menu are getting mousePressed notification, but not mouseDragged or mouseReleased. This is the root of all the problems that I see. ###@###.###, I'm wondering if this is related to the code changes you did for 4730233. ###@###.### 2004-04-22 ====================================================================== Name: pzR10082Date: 04/23/2004 MouseGrabber.eventDispatched() method redirects MOUSE_RELEASED event to JPopupMenu. The idea behind the redirecting code is to traverse selected path starting from the innermost MenuElement up to the roots, and redirect event to the first component encountered that contains the point at which the event occurred. This code assumes that no component inside popup menu will want to process mouse events. ###@###.### ====================================================================== Updated the Description with some more details about testcase ###@###.### 2004-04-23 See also 6179677 which has another test case regarding JSpinner. I'm closing that bug as a duplicate, but we need to verify that any fix to this corrects that bug as well. ###@###.### 10/18/04 14:46 GMT We also need to verify that the fix to this addresses 5082541 and 6222765 which I'm also closing as duplicates. ###@###.### 2005-1-31 18:34:44 GMT Note: 6269935 is another bug that looks like it might be the same problem. ###@###.### 2005-05-26 19:01:16 GMT Please also verify that the fix to this corrects bug 6278722, which I've closed as a duplicate. ###@###.### 2005-06-01 20:49:36 GMT In the MouseGrabber we are forwarding mouse events to the MenuSelectionManager even if event source is not a MenuElement. We should not do that. MenuSelectionManager deals with the MenuElements only. The idea of fix is to ignore events targeted to non-menuelements in the popup. ###@###.### 2005-06-07 09:24:46 GMT

WORK AROUND - go back to 1.3.x or 1.4.x OR - do significant code changes in your Java application/applet (use dialogs rather than GUI components/beans at a JMenu) ###@###.### 2005-05-12 09:20:49 GMT