FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Linux XXXXX 2.6.11.4-20a-smp #1 SMP Wed Mar 23 21:52:37 UTC 2005 i686 i686 i386 GNU/Linux

A DESCRIPTION OF THE PROBLEM :
This bug was first discovered as https://bugs.eclipse.org/bugs/show_bug.cgi?id=141893

When having multiple embedded AWT frames, dropping elements into any of them results in dropping into the first one opened, due to bad management of drop targets in XEmbeddedFramePeer/XWindowPeer classes.

In eclipse bug originator's words:

"...within the XWindowPeer (base class of XEmbeddedFramePeer) there
are public methods called addDropTarget() and removeDropTarget(). It appears
that when addDropTarget() is called for more than one XEmbeddedFramePeer at a
time (the case when mutliple bridge editors are simultaneously open), just
the first one called becomes an active droptarget and the calls for
subsequent peers fail to become active drop targets."

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See eclipse bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=141893 for steps (snippet included) to reproduce, and event workaround.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The awt frame that notices the drop action should be the correct one.
ACTUAL -
The awt frame that notices the drop action is the first that was opened.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
See referred eclipse bugzilla.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
See referred eclipse bugzilla.