JDK-4522405 : REGRESSION: Can't click on Scrollbar of a JComboBox drop down with Windows LaF
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2001-11-02
  • Updated: 2001-11-06
  • Resolved: 2001-11-06
Related Reports
Duplicate :  
JDK-4492892 - REGRESSION: windows l&f: mnemonics do not work in menus
Relates :  
JDK-4525962 - Opposite component calculated inaccurately
Relates :  
JDK-4523000 - REGRESSION: Can't select an item in a JComboBox after opening a menu in Win LAF
Description

Name: rmT116609			Date: 11/02/2001


java version "1.4.0-beta3"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta3-b84)
Java HotSpot(TM) Client VM (build 1.4.0-beta3-b84, mixed mode)

With windows look and feel click and release on a JComboBox that has a list of choices long enough to
require a scrollbar. If you then attampt to click on the scrollbar to scroll the list of choices the drop down 
dissappears instead.

When I first played with the combo box example using the windows look and feel it worked correctly, no
matter how much a fiddled with the comboboxes.  But I swithed back to the metal (java) look and feel 
played a bit and then switched back and to windows look and feel and it started failing 100% of the time.

I made another important discovery!!!  There is another bug that is related.  When the windows look and feel
is in the state where it is always failing it seems it doesn't matter where you click in the drop down list - the 
result is that the list dissappears without any selection action being taken or scroll or anything.

With that same session of SwingSet2 I switched back and forth several times between the java look and feel 
and the windows look and feel, the windows look and feel was consistently broken for all but the very first 
time I tried it.  The java look and feel worked fine every time.

I exited and launched the SwingSet2 demo again.  The first time I switched to windows look and feel it worked.
I switched back to java look and feel and then back to windows look and feel and it was broken again. I tried 
two more times.. same result - when I switch to windows look and feel the second time it will be stuck such that
it always fails.

please look into Bug Id 4163682 for information as well.


Additional information:

When I first encountered the bug I was using an XML editor called "Merlot" version 1.0.1 http://www.merlotxml.org/downloads.shtml

I have re tried the experiement on my home computer (same JDK, Win2k SP2, dual processor, 256MB RAM, GeForce DDR ).  I used 
the SwingSet2 demo that comes with the JDK.
(Review ID: 134847) 
======================================================================
Comments
EVALUATION Name: pzR10082 Date: 11/05/2001 Switching LAF from Windows to Metal and back affects focus events that are sent to the combo box when user clicks inside combo popup. After the switch, these events become non-temporary for some reason. BasicComboBoxUI.FocusHandler hides the popup when it encounters a non-temporary event. This bug is not reproducible with fix for 4492892 applied. ###@###.### 2001-11-05 ====================================================================== Name: pzR10082 Date: 11/05/2001 When user clicks on combo popup, bad FOCUS_LOST event is dispatched: its source is the combo box, opposite component is the popup menu that belongs to the "Look & Feel" menu, and temporary==false. This event is created in DefaultKeyboardFocusManager.dispatchEvent(). It determines oppositeWindow correctly (it is com.sun.java.swing.plaf.windows. WindowsPopupMenuWindow), then it calls getMostRecentFocusOwner() on it. For some reason this call returns the popup menu, which is not even a child of this Window. ###@###.### 2001-11-05 ====================================================================== Name: pzR10082 Date: 11/06/2001 This bug occurs whenever we try to reuse heavyweight popup windows. When user opens the menu, a HW popup window is used to host JPopupMenu. Then the same window is used for combobox popup. When user clicks on this combobox popup, a FOCUS_LOST event is to be sent to the combobox. DefaultKeyboardFocusManager tries to determine the opposite component and calls getMostRecentFocusOwner() on the popup window. This call returns JPopupMenu which has had focus before. But JPopupMenu is not a popup window child any more. DefaultKeyboardFocusManager gets confused. As a side effect, focus event's temporary flag is changed from true to false, so BasicComboBoxUI.FocusHandler hides the combobox popup. This bug occurs in all LAFs, though it can be most easily seen in WinLAF, as WinLAF always uses heavyweight popups. Fix for bug 4492892 also fixes this bug, because with this fix, JPopupMenus no longer request focus. However, this issue makes more difficult reusing Windows containing focusable components. ###@###.### 2001-11-06 ======================================================================
06-11-2001