-
Bug
-
Resolution: Fixed
-
P3
-
7
-
x86
-
windows_7
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8015915 | 7u40 | Petr Pchelko | P3 | Closed | Won't Fix |
FULL PRODUCT VERSION :
1.7.05 32 bit but likely all 1.7.*
ADDITIONAL OS VERSION INFORMATION :
Windows 7 64 bit for sure but other likely too
A DESCRIPTION OF THE PROBLEM :
java.awt.Choice.getSelectedIndex() and getSelectedItem() return wrong values in scenarios involving calls to removeAll() when the widget is hidden and selecting the same item twice in row.
It take it there must be some problem in synchronization with the native widget.
REGRESSION. Last worked in version 6u31
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1/ Create a Choice from the main thread with items "a", "b", "c"
2/ Display the Choice and let user select an item (e.g., "b")
3/ Hide the Choice
4/ From another thread do
- removeAllItems()
- re-add the same items (add())
5/ Show the Choice again (from actionPerformed() so again the main thread?)
Result: The first item "a" is selected.
6/ User selects "b"
7/ getSelectedIndex() returns 0 and getSelectedItem() returns "a"
If the Choice has an ItemListener installed, no itemStateChanged() is emitted in step 6/
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The mentioned methods should return values corresponding to the state of the native widget and itemStateChanged should be triggered.
ACTUAL -
See reproduction scenario, step 7.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Selecting another item ("c" from the reproduction scenario) makes the Choice report the selected item correctly (even "b"). Also itemStateChanged gets triggered again then.
But this is not acceptable in a production app so I have to delete and re-create all the Choices every time.
1.7.05 32 bit but likely all 1.7.*
ADDITIONAL OS VERSION INFORMATION :
Windows 7 64 bit for sure but other likely too
A DESCRIPTION OF THE PROBLEM :
java.awt.Choice.getSelectedIndex() and getSelectedItem() return wrong values in scenarios involving calls to removeAll() when the widget is hidden and selecting the same item twice in row.
It take it there must be some problem in synchronization with the native widget.
REGRESSION. Last worked in version 6u31
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1/ Create a Choice from the main thread with items "a", "b", "c"
2/ Display the Choice and let user select an item (e.g., "b")
3/ Hide the Choice
4/ From another thread do
- removeAllItems()
- re-add the same items (add())
5/ Show the Choice again (from actionPerformed() so again the main thread?)
Result: The first item "a" is selected.
6/ User selects "b"
7/ getSelectedIndex() returns 0 and getSelectedItem() returns "a"
If the Choice has an ItemListener installed, no itemStateChanged() is emitted in step 6/
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The mentioned methods should return values corresponding to the state of the native widget and itemStateChanged should be triggered.
ACTUAL -
See reproduction scenario, step 7.
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
Selecting another item ("c" from the reproduction scenario) makes the Choice report the selected item correctly (even "b"). Also itemStateChanged gets triggered again then.
But this is not acceptable in a production app so I have to delete and re-create all the Choices every time.
- backported by
-
JDK-8015915 java.awt.Choice.getSelectedIndex() returns invalid value
-
- Closed
-