JDK-4525474 : Bogus 'focusLost' sent to AccessibleContext listeners.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.3.1
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-11-09
  • Updated: 2002-12-02
  • Resolved: 2002-12-02
Related Reports
Relates :  
JDK-4168483 - Mediumweight popup problem on Solaris
Description
'BasicComboBoxUI.java' mentions a "bogus focusLost" which is sent to the
ComboBox which is detected and handled.  However, this bogus focusLost
event is still passed on to the 'assistive technologies' which now thinks
that the ComboBox pop-up is no longer visible.
Comments
EVALUATION Should be fixed in Hopper. ###@###.### 2002-02-07 Reassigning to the Swing team because it involves significant component UI issues. ###@###.### 2002-04-03 This bogus focus lost is coming from awt, not swing, reassigning. ###@###.### 2002-04-03 Name: dmR10075 Date: 04/04/2002 It is hard to investigate this bug without the testcase. I am not sure that I correctly understand what is meant by "passed on to the 'assistive technologies'". Anyways, it would be easier for us to investigate if there will be standalone test case, could you please either supply report with one or point to some application which can be used in that purpose? On the other hand, after the fix for 4546712 I think this bug should have disappeared, at least in my workspace which contains this fix I don't see any superfluous events, while in Hopper b06 I do see some. This fix will be available in Hopper b08 or it can be obtained from current AWT workspace. ###@###.### 2002-04-04 ====================================================================== Java Accessibility & Assistive Technologies - From the J2SDK1.4 documentation: http://java.sun.com/j2se/1.4/docs/guide/access/index.html "The Java Accessibility Utilities help assistive technologies take advantage of the Java Accessibility API. The Utilities monitor events related to UI components. They also help assistive technologies get additional information about a GUI, such as the current position of the mouse, or the window that currently has focus." Here is the v1.4.0 'BasicComboBoxUI.FocusHandler.focustLost' method: public void focusLost( FocusEvent e ) { hasFocus = false; // GES, 980818: // Note that the second check here is a workaround to bug // 4168483. There is a bogus focusLost sent to the // ComboBox with isTemporary false when a mediumweight menu // is popped up. Until this is fixed in AWT, we make the // tradeoff of not popping down mediumweight popups when // the combobox loses focus. Although this means that the // combobox does not remove such menus when you tab out, // it is seen as more desirable than the alternative which // is that mediumweight combobox menus dissappear immediately // on popup, rendering them completely unusable. if ( !e.isTemporary() && comboBox.isLightWeightPopupEnabled()) { setPopupVisible(comboBox, false); } comboBox.repaint(); // Notify assistive technologies that the combo box // lost focus. if (comboBox instanceof Accessible) { AccessibleContext ac = ((Accessible)comboBox).getAccessibleContext(); if (ac != null) { ac.firePropertyChange( AccessibleContext.ACCESSIBLE_STATE_PROPERTY, AccessibleState.FOCUSED, null); } } } Notice that condition under which the comboBox is set invisible (ie. check for the 'bogus focusLost' before setting popup-visible to false). Also notice that this condition is not replicated when sending the focus lost to the 'assistive technologies' (AccessibleContext). The assistive techologies listening to the these events will believe that the combo-box is no longer visible, when it may in-fact still be visible. I would assume that a work-around would be to completely dump the focusLost event if it is in-fact bogus. Or don't send the "bogus focusLost" in the first place. (see #4168483 for more info) The mentioned bugfix for #4546712 (JCK1.4/1.3a, interactive:api/javax_swing/interactive/JMenuItemTests.html fails) does not appear to be applicable to combo-boxes. ###@###.### 2002-04-04 --------------------------------------------------------------------------- Name: dmR10075 Date: 04/05/2002 I see - there is no need in test case, it is in the code. However, `don't send the "bogus focusLost"` is exactly what the fix for 4546712 is expected to be doing so let's wait till Hopper b08 and verify this bug once again against that build. ###@###.### 2002-04-05 ====================================================================== According to email from ###@###.###, this will not be a showstopper for hopper-beta. If it is not already fixed in hopper, we should try to address it for mantis. ###@###.### 2002-05-03 Name: dmR10075 Date: 08/21/2002 This bug has not been fixed by the fix for 4546712 because the fix had been completed. Completed fix is planned to go in Mantis in the fix for 4452384. ###@###.### 2002-08-21 ====================================================================== The fix for 4452384 mentioned above went into Mantisb02. Need the submitter to confirm or refute that this bug was also resolved. Moving to incomplete. ###@###.### 2002-10-11 Currently all Swing popups are non-focusable. While Swing keeps them so there won't be any bogus focus events. Closing this bug as not reproducible. ###@###.### 2002-12-02
02-12-2002