This bug only shows up after JDK1.1v (if this helps at all) and is seen in all
the JDK1.1.1 builds.
On win32, we are getting a MOUSE_DOWN event when the MOUSE_DRAG is in effect.
In HJ, when we see a MOUSE_DOWN followed by a MOUSE_DRAG it is a trigger for us
to initiate a DRAG operation in the Remembered Places window. Because of the extra MOUSE_DOWN events introduced during MOUSE_DRAG, multiple draggable
containers are created with the visual effect of blotched display
when drag and drop is attempted in the Places window.
As a workaround, in ui/HotListFrame we are not creating new draggable containers if a valid one already exists. This covers us for now but there may be other cases where bad things could happen.


=================================

case DraggableContainer.DRAG_START:
// This is a workaround for an AWT bug on win32 where
// a spurious MOUSE_DOWN is generated during MOUSE_DRAG.
// When we see a MOUSE_DOWN followed by a MOUSE_DRAG, we go
// ahead and build a DraggableContainer to initiate a drag.
// Because of the spurious MOUSE_DOWN, we would end up creating
// multiple DraggableContainers. Only the last such container
// would be disposed on a DROP event as we still have a handle
// to it via the draggable variable. The rest of the windows
// would remain as floating windows till the Places window was
// closed.
// With this workaround we ignore requests for creating
            // DraggableContainer if a valid container already exists.
if (draggable == null ) {
DragStartInfo startInfo = (DragStartInfo)evt.arg;
draggable = new DraggableContainer(this, this, startInfo);
}
return true;