We recently bumped into a problem: in Gnome (CentOS 5.2), in Java Applet, the JIDE comboboxes have a strange glitch: if you open a combobox, and switch to other window, combobox stays on the screen, on top of all the windows though you'd expect it to hide
I took a liberty of searching the web, and found a bug, http://bugs.sun.com/bugdatabase/view_bu ... id=5070056 which looks very similar given that JidePopup uses JWindow. Digging in the JidePopup sources gave me the following code snippet, on which I'm stuck, as I don't really understand the comments, especially the "TODO: don't why DEACTIVATED event is fired" part. Could please anyone give me a clue on whether the EmbeddedPane check is still necessary?
- Code: Select all
// The cases for window deactivated are too complex. Let's not consider it for now.
// One case the code below didn't consider is an dialog is shown while in another thread, alert is showing and the owner is the frame.
// At the end, frame received deactivated event and cause alert to hide immediately.
//
// 1/2/07: we have to put this code back because combobox's popup not hiding when the window is deactivated.
// But I also copied the code from MenuSelectionManager to check doUnpostPopupOnDeactivation. Hopefully that addresses the issue above.
else if (isTransient()
&& e.getID() == WindowEvent.WINDOW_DEACTIVATED
&& !(e.getWindow() instanceof EmbeddedFrame)) {
// TODO: don't why DEACTIVATED event is fired when popup is showing only if the applet is in browser mode.
// so the best solution is to find out why. For now just skip the case if the frame is a EmbeddedFrame.
if (doUnpostPopupOnDeactivation()) {
if (e.getOppositeWindow() != getTopLevelAncestor()) {
hidePopup(true);
}
}
}