FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
All Linuxes, Solaris and MacOs systems

A DESCRIPTION OF THE PROBLEM :
This is the definition of drag & drop autoscrolling given in the "Drag and Drop Subsystem for the Java 2 Platform Standard Edition 5.0" specification at the address http://java.sun.com/j2se/1.5.0/docs/guide/dragndrop/spec/dnd1.html:

---
Many GUI Components present a scrollable "viewport" over a (potentially) large dataset. During a drag and drop operation it is desirable to be able to "autoscroll" such "viewports" to allow a user to navigate over such a dataset, scrolling to locate a particular member (initially not visible through the "viewport") that they wish to drop the subject of the operation upon.
Components that are scrollable provide drag "autoscrolling" support to their DropTarget by implementing the following interface:
public interface Autoscroll {
        Insets getAutoscrollInsets();
        void autoScrollContent(Point cursorLocn);
}
An implementing DropTarget shall periodically call the autoscroll method of its associated Component (if present), passing the current logical cursor location in Component coordinates, when the following conditions are met:
- If the logical cursor's hotspot intersects with the associated Component's visible geometry and the boundary region described by the Insets returned by the getAutoscrollInsets method.
- If the logical cursor's hotspot has not moved (subject to the next condition below) for an implementation defined period (millisecs)
- If any cursor movement subsequent to the initial triggering occurrence does not exceed a platform dependent hysteresis value (pixels).
---

The above translates in practice to this: if a user drags something over the autoscroll region of a component accepting the drag and partially visible through a scrolling area, then, while the cursor is kept still (with a tolerance), the component itself scrolls automatically to show its hidden parts.
This is standard behavior that can be observed in a lot of applications but it's not what happens with Java applications on Linux and MacOs. I could not test directly on Solaris, but I'm pretty sure it has the same problem.
On these platforms when the cursor enters the autoscrolling region, the autoscrolls starts but stops after a little, even if there are all the conditions to continue: the user doesn't move the cursor, the cursor is in the autoscroll region and there is more hidden area of the component to scroll into view. The user must continuously and annoyingly move the cursor near the scroll bounds to achieve the effect of autoscrolling.
Notable exception to this anomaly are JTextFields, perhaps because they aren't contained in a JScrollPane and they manage autoscroll in a different way.
Conversely, in a Java application running on Windows (tested on Windows2000), the component continues to scroll until it reaches its bound in the scrolling direction.

This is due to a defective implementation of drag & drop autoscroll, that doesn't manifest itself on Windows because the DropTargetContextPeer on that platform continuously calls the dragOver method, even when the cursor is kept still.

As of Mustang b96, I found two classes responsible of drag & drop autoscrolling:
- DropTargetAutoScroller, a member class of java.awt.dnd.DropTarget, responsible of supporting components implementing the Autoscroll interface;
- DropHandler, a member class of javax.swing.TransferHandler, that automates d&d autoscrolling on components implementing the Scrollable interface.

Both classes have the same problems:
- after the autoscroll starts, they check if the cursor moved more than a prefixed value (hysteresis), and in such case they stop autoscroll. But since they use component coordinates for cursor position, they don't check the real cursor move, but the cursor move plus the component scroll under the cursor; the effect is that the autoscroll is often stopped when it shouldn't.
- autoscroll is done with a timer that on actionPerformed informs the component that it must scroll, passing to it the cursor position, in component coordinates, registered on the last dragOver. This position, if the user doesn't move the cursor, is not updated, so after some scroll the cursor position falls outside the autoscroll region. Again, the effect is that the autoscroll is stopped too early.

So, on platforms where the autoscroll timer isn't continuously restarted by dragOver calls, drag & drop autoscroll doesn't work as expected, and it's a real pain to use.
Furthermore, on Windows the autoscroll frequency is lower than what one could expect from the value of the DesktopProperty "DnD.Autoscroll.interval", because the timer can't fire undisturbed, having to stop and restart continuously.
I tested on MacOs with jdk1.5.0_06 and jdk1.6.0-b82-3, on Ubuntu Dapper with jdk1.6.0-b94 and Windows2000 SP4 with jdk1.5.0_04, jdk1.5.0_06, jdk1.5.0_07and jdk1.6.0 b96. For Solaris this post says it all:

http://coding.derkeiler.com/Archive/Java/comp.lang.java.gui/2003-11/0586.html


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
- Create a frame containing a scrollable component in a JScrollPane, e.g. a JTextPane.
- Make sure the component is scrollable toward the bottom, for a JTextPane paste a long text into it and move the cursor to the top.
- Drag something that can be dropped on the component near its bottom border and the don't move the cursor.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The expected result is that the component automatically scrolls until it reaches its bottom, without any user intervention.
ACTUAL -
The actual result is that the component scrolls only one or few times and then stops. To reach te bottom dragging an object the user has to continuously move it in some way to restart the scrolling.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Attached seperatly
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
A partial one is to use a DropTarget that implements correct autoscrolling as the one included in the attached test case, but it has a lot of drawbacks.