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.
EVALUATION
The reason is in the old change marked by 2005 and there is a big change in XWindowPeer.handleButtonPressRelease.
Roughly speaking we get "!containsGlobal(x, y)" as true and falls to the return statement below:
if ((target == this || target == getContentXWindow()) && !containsGlobal(xbe.get_x_root(), xbe.get_y_root())) {
postEventToEventQueue(new sun.awt.UngrabEvent(getEventSource()));
return;
}
It's not false because we seem not in the original toplevel anymore which means we still use preserved old toplevel (window) and compare its coordinates with bounds of the new window which is swing menu.
14-12-2009
EVALUATION
I observed a diff in behaviour b/w JDK5RC and JDK6RC.
1) If I press the button and drag it out of the combobox, in both cases the new item don't become selected and the menu hides. But in JDK6 we also fires PopupMenuCanceled event.
2) Moreover, the bug even more visible if I have a long list which goes outside the toplevel. In that case I can't select "outside" menu items with drag. It always closes the menu and don't fire ItemStateChanged event.
If I read right, the complain was about 1). 2) might be even worse problem too.
14-12-2009
EVALUATION
We switched the underlying toolkit on solaris in JDK6 and likely it's a XToolkit regression. There also were some difference in event processing some of which could cause that effect.
11-12-2009
EVALUATION
This is a Solaris specific problem, reassigned to AWT