JDK-5072554 : Extra PropertyChange notification when vetoing a focus change event
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2004-07-09
  • Updated: 2005-12-01
  • Resolved: 2004-10-11
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.
JDK 6
6 b08Fixed
Description
I have a test application (attached as FocusChangeTest.java) that has two JTextFields. I've added a VetoableChangeListener to the KeyboardFocusManager to veto any focus change that would put focus on the second JTextField. It also prints out the old and new values in the PropertyChangeEvent.

Upon launching the application, the following is printed to the console, as the first text field gains focus:

0 Old=null, New=One

After hitting TAB, the following is printed out.

1 Old=One, New=null
2 Old=null, New=Two
VETOING
3 Old=Two, New=null
4 Old=null, New=null
5 Old=null, New=One

Line is quite odd and doesn't really make sense. Seems like a bug to me.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang FIXED IN: mustang
11-09-2004
SUGGESTED FIX ------- KeyboardFocusManager.java ------- *** /tmp/sccs.R2aqSo Wed Jul 28 19:22:11 2004 --- KeyboardFocusManager.java Wed Jul 28 12:53:07 2004 *************** *** 1369,1379 **** * @param propertyName the name of the property that has changed * @param oldValue the property's previous value * @param newValue the property's new value */ protected void firePropertyChange(String propertyName, Object oldValue, ! Object newValue) { PropertyChangeSupport changeSupport = this.changeSupport; if (changeSupport != null) { changeSupport.firePropertyChange(propertyName, oldValue, newValue); } } --- 1369,1383 ---- * @param propertyName the name of the property that has changed * @param oldValue the property's previous value * @param newValue the property's new value */ protected void firePropertyChange(String propertyName, Object oldValue, ! Object newValue) ! { ! if (oldValue == newValue) { ! return; ! } PropertyChangeSupport changeSupport = this.changeSupport; if (changeSupport != null) { changeSupport.firePropertyChange(propertyName, oldValue, newValue); } } *************** *** 1545,1554 **** --- 1549,1561 ---- */ protected void fireVetoableChange(String propertyName, Object oldValue, Object newValue) throws PropertyVetoException { + if (oldValue == newValue) { + return; + } VetoableChangeSupport vetoableSupport = this.vetoableSupport; if (vetoableSupport != null) { vetoableSupport.fireVetoableChange(propertyName, oldValue, newValue); ###@###.### 08/13/2004 ###@###.### 2004-08-13
13-08-2004
EVALUATION Name: aaR10319 Date: 07/15/2004 in the application listed focus events are: 1. at startup - FOCUS_GAINED on "One" (opposite is null) 2. when user hits Tab - FOCUS_LOST on "One" (opposite is "Two"), after it focusOwner and permanentFocusOwner become null 3. FOCUS_GAINED on "Two" (opposite is "One") - that is vetoed, so focusOwner becomes "One" and permanentFocusOwner = null 4. because of veto - FOCUS_LOST on "Two" (opposite is One), focusOwner and permanentFocusOwner become null 5. FOCUS_GAINED on "One" (opposite is "Two"), focusOwner and permanentFocusOwner become "One" All the changes to permanentFocusOwner property cause user notification, so in the 4. notification will be the vetoableChange with both old and new values set null. As a possible solution we probably should not generate vetoable PropertyChangeEvent if old and new values are equal. And users would better veto either both focusOwner and permanentFocusOwner properties or none of them, though this is not a requirement ###@###.### ====================================================================== Name: at153223 Date: 07/26/2004 The problem is that the case when old and new property values are null is considered by PropertyChangeSupport class to require notification. Though in case of focusOwner property we don't have to be notified. ###@###.### 07/26/2004 ====================================================================== Name: at153223 Date: 07/28/2004 Suggested fix (see also Artem's evaluation above) is to test if an old and new property values are the same ('null' and 'null' case is included) not relying on PropertyChangeSupport checking. ###@###.### 07/28/2004 ======================================================================
28-07-2004