verified in 

java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b15)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b15, mixed mode)

 xxxxx@xxxxx  2002-06-14
--------------------------------------------------------It is experienced on jdk1.4.x for Windows only (on jdk1.3 for Windows it seems to be fine).

1) Doing DnD, i.e. dragging component in application on windows using jdk1.4.x, above drop targets and outside drop target borders, occasionally freezes the app. During that time CPU is 100% used, app gives no responses, it takes usually about 5 sec, but were experienced cases up to 82 seconds.

2) On Netbeans it is possible to experience this issue very often, probably it has something to do with the amount of events run in the app. But event on testcase, which is comparing to NB trivial no event handling is done, it is possible to experience the problem. Note: it is experienced neither on jdk for Linux nor Solaris.

3) Testcase. It is possible to experience too. But you have to be more patient. 
Do following:
a) Repeat quickly to drag the component from tree, it seems to, you have to do quick motions, and go also outside the panel, provide the drop to the right area. Do more attempts in the row, sometime above the 10 are necessary to get the problem.
b) Sometimes you get the problematic state, it was experienced on windows jdk1.4.0-fcs, and 1.4.1-b08, but it wasn't on jdk1.3.1_03.
c) The problem is on NB it is seen much more easier, thus making the feature not usable.

N/A

Evaluation:
I was unable to reproduce the bug on WinNT and Win2000 with the
attached test case. The problem readily manifests on Netbeans
development build 200204230100 running on Win2000 SP2 5.10.2195 
with 1.4.1-b10. Here are the possible steps to reproduce:
1)Install and configure Netbeans to run in MDI mode.
2)Run Netbeans with -J-Dnetbeans.winsys.dnd=true.
3)When Netbeans starts up and the main window is displayed there will
  be a tabbed pane with four tabs: Editing, GUI Editing, Running,
  Debugging. Make sure the Editing tab is selected.
4)You should see another tabbed pane with four tabs: Runtime,
  Filesystems, Project default, Javadoc. Click on either of these four
  tabs. The selected tab should receive focus. 
5)Then press the left mouse button on the selected tab and drag the
  mouse over Netbeans panes. Some panes will provide a drag-under
  feedback. 
6)As the mouse is dragged over these panes, the drag freezes will
  manifest. The symptom is that the drag-under feedback is not
  provided. The freezes are typically 5-10 seconds long, but can take
  up to 3 minutes depending on the environment.

The investigation shows that in my environment long freezes (more than
10 seconds) manifest only if either the Netbeans or the JRE are on a
network drive accessed via the Reflection NFS Client or the Client for
Microsoft Networks. The cause is that some WinNTFileSystem methods are
very slow when the file is accessed over the network. In my environment 
a single call to canonicalize(), getBooleanAttributes(),
getLastModifiedTime() can last for 10-20 (and up to 200) seconds. If
this slowdown happens during a drag operation it manifests as a long
drag freeze.

When both the Netbeans build and the JRE are on the local drive the
drag freezes still manifest, but they are not so long - typically 5-10
seconds.

A typical stack trace of the java event dispatch thread at the
point of freeze in WinNTFileSystem is attached to this bug report as
edt-dump.txt.

The time profiling of the java event dispatch thread indicates that
in most cases drag freezes while a
SystemEventQueueUtilities.ComponentWorkRequest is processed.
Typically ComponentWorkRequest processing takes less than 100
milliseconds, but sometimes it takes significant time: 3-7 seconds and
it manifests as a drag freeze. Other events never take more than 100
milliseconds.

For time profiling of the java event dispatch thread I applied 
the patch attached to this bug report as EventDispatchThread.java.pch
to the file src/share/classes/java/awt/EventDispatchThread.java.

ComponentWorkRequest is posted to the java event queue to repaint all
Swing components that are marked as "dirty". For time profiling of the
painting code I applied the patches attached to this bug report as
SunGraphics2D.java.pch and GraphicsPrimitives.java.pch to 
src/share/classes/sun/java2d/SunGraphics2D.java and 
src/share/classes/sun/java2d/loops/GraphicsPrimitives.java
respectively.

Painting code profiling shows that in most cases slow processing of a
ComponentWorkRequest can be tracked to one of the three cases:
1)Slow execution of SunGraphics2D methods caused by slowdown in a
  DirectDraw graphics primitive. The excerpt from the Netbeans log
  that demonstrates this situation is attached to the bug report as 
  ide1.log.
  The Netbeans was run with the following additional options:
    -J-Dnetbeans.winsys.dnd=true 
    -J-Dsun.java2d.trace=log,timestamp
2)Slow execution of SunGraphics2D methods not related to graphics
  primitives. The profiling indicates that typically SunGraphics2D
  methods take less than 100ms, but occasionally they execute very
  slowly: up to 3-4 seconds. 
  Here are the peak results for several methods:
   SunGraphics2D.fillRect         - 3936 milliseconds
   SunGraphics2D.drawImage(Image,int,int,Color,ImageObserver)
                                  - 4036 milliseconds
   SunGraphics2D.constrain        - 3835 milliseconds
   SunGraphics2D.makeFontMetrics  - 3986 milliseconds
   SunGraphics2D.drawRect         - 4436 milliseconds
   SunGraphics2D.transformShape(int,int,Shape)
                                  - 3315 milliseconds
   SunGraphics2D.clone            - 3986 milliseconds
   SunGraphics2D.create           - 3655 milliseconds
  This situation manifests more readily when DirectDraw is disabled.
  It is demonstrated by ide3.log
  The Netbeans was run with the following additional options:
    -J-Dnetbeans.winsys.dnd=true 
    -J-Dsun.java2d.trace=log,timestamp
    -J-Dsun.java2d.noddraw=true
3)Slow execution of Swing painting code that is not tracked down to
  a single SunGraphics2D method. 
  This situation manifests more readily when DirectDraw is disabled.
  It is demonstrated by ide2.log and ide3.log.
  The Netbeans was run with the following additional options:
    -J-Dnetbeans.winsys.dnd=true 
    -J-Dsun.java2d.trace=log,timestamp
    -J-Dsun.java2d.noddraw=true

The machine used for profiling has Matrox Millenium G450 DualHead,
driver version 5.72.21.0.

 xxxxx@xxxxx  2002-05-07

Danila has requested reassigning this to 2D.  If more investigation is needed 
by Drag&Drop and AWT, please let us know.  

 xxxxx@xxxxx  2002-05-07

As per agreement with DnD group, reassigning the bug back to DnD.

 xxxxx@xxxxx  2002-06-03




While a drag operation is in progress, the toolkit thread runs
secondary message pump that processes all sent messages, and posted
messages of two types: WM_PAINT messages and application-specific task
messages. This message pump is designed to call PeekMessage filtering
WM_PAINT and task messages in a tight loop. Although PeekMessage is
documented to yield at appropriate time, on Win2000 the secondary
message pump occasionally occupies all processor time that manifests
as drag freezes.

 xxxxx@xxxxx  2002-06-04

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

This fix will be verified by the Forte group.  

 xxxxx@xxxxx  2002-06-06

What is Hopper-beta and when will it be available?

Yes indeed this is a nasty bug.  I don't see what you did
to fix it but I hope you did.  What is the hopper-beta and 
when is it scheduled for release?

Hopper-beta = JDK 1.4.1beta
Release = ? (maybe end of 2002)

The symptoms also occur on DnD operations that are 
contained to an Applet. I'm placing odds on a mishandled 
event condition in a process pump.

This problem is critical for the next release of our 
application. We still experience the problem with the 1.4.1-
b14. It seems that you have fixed the problem in the 1.4.1-
rc. When will it be available for evaluation ? Can we 
expect a 1.4.1 final release for this summer ? In case not, 
we would have to ship our app with a JRE 1.3.1 on Windows. 
Thanks !

Gilles

FYI

As of Today July 16, 2002 the download j2sdk-1_4_1-beta-
windows-i586.exe 
java -version gives 1.4.1-beta-b14
This does not contain the fix to the problem.

As of Today July 21, 2002 the download j2sdk-1_4_1-beta-
This does not include the fix of this problem, and it causes 
our application to freez and makes our customers mad.

This is what Sun says in its release notes for FCS: "4669873: 
A drag and drop bug, reported on hopper-beta under 
Microsoft Windows, caused an application to briefly freeze 
during DnD and is fixed in the final release of 1.4.1."

Then why is the bug not listed in the bugs fixed list?!?