Run the attached test. In the test I create a frame and an embedded frame, then put embedded frame into the frame. Inside the embedded frame there are several Swing components including JComboBox which behaves wrong: when I click on it, it is expanded (unfurled) and immediately collapsed back. If I expand the combo box with keyboard, it works correctly.

I tried to reproduce this bug using SwingSet2 applet from java.sun.com, but the applet works fine. I also tried to add JApplet into embedded frame (like it is done in browser) and place all the Swing components into it instead of embedded frame, but this doesn't help.

I suspect something is wrong with AWT grab, so I'm filing this bug against AWT, not Swing group. The test to reproduce the bug is attached.
Posted Date : 2006-12-29 09:14:24.0

N/A

well the problem is that our embedded frame does not have correct location.
Good news is that the problem does not affects applets since as soon as we add
JApplet (or Applet) everything is ok.  Also SWT should not be affected by this since they
are supposed to update location of embedded frame.
The only question is if this is a bug or not (need to discuss this :)
Posted Date : 2007-01-09 18:59:21.0

it looks like the problem is that getLocation() and getLocationOnScreen() for embedded
frame returns different values and we use incorrect one :(
I've also found that getLocation() sometimes return (0,25), sometimmes (300, 200), but 
location is never changed during embedded frame life cycle :(
Posted Date : 2007-02-15 14:05:05.0

When grab is active we retarget mouse events
and recalculate their coordinates.  But we use getX/getY to get
coordinates of a window to which we are going to retarget an event.
This is ok for most toplevels except embedded ones.  We should use
getAbsoluteX/getAbsoluteY instead.
Posted Date : 2007-02-26 11:37:08.0

The fix subtracts toplevel's absolute coordinates from event's coordinate.

The absolute location of frame is shell location (that is adds insets). At the same time, a component in the frame has relative coordinates that include frame's insets. This implies that the fix incorrectly calculates event's relative coordinates because it subtracts insets twice.
Posted Date : 2007-12-21 11:51:09.0

In this case XWindowPeer should translate absolute coordinate to local coordinates more carefully. XBaseWindow.toLocal method uses content window to calculate local coordinates. Content window holds coordinates of window in terms of Java and it can be painlessly used for top-levels and embedded frames.
Posted Date : 2008-01-17 10:06:34.0