Bug 261865 [CommonNavigator] Drag from Project Explorer to Package Explorer gets "assertion failed"
The CommonDropAdapter should be keeping track of the event.detail variable and setting it properly at the end. It currently does not do this all the time. If dragging from the project explorer, a JDT drag adapter checks this code in an assert to verify there is no more work to do. BasicSelectionTransferDragAdapter.dragFinished(etc) has the following code: public void dragFinished(DragSourceEvent event) { // Make sure we don't have to do any remaining work Assert.isTrue(event.detail != DND.DROP_MOVE); LocalSelectionTransfer.getInstance().setSelection(null); LocalSelectionTransfer.getInstance().setSelectionSetTime(0); } Currently, CommonDropAdapter only modifies this event.detail variable via the superclass, and even then, only in some situations. public void drop(DropTargetEvent event) { validateDrop(getCurrentTarget(), getCurrentOperation(), event.currentDataType); if (PluginTransfer.getInstance().isSupportedType(event.currentDataType)) super.drop(event); The superclass and the super-superclass execute the following line almost universally in this method: event.detail = DND.DROP_NONE; This command indicates the event no longer has any work to do. This line is missing from CommonDropAdapter.drop(DropTargetEvent event) in two places. Patch attached. The effect of this bug is that any time this bug is hit, an error dialog appears and something is logged to the error log. Very annoying for users.
bundles/org.eclipse.ui.navigator/src/org/eclipse/ui/navigator/CommonDropAdapterAssistant.java
* Each {@link CommonDropAdapterAssistant} is contained by single content
 * extension. The opportunity for each assistant to handle the drop operation is
 * determined by the <b>possibleChildren</b> expression of the
 * <b>org.eclipse.ui.navigator.navigatorContent/navigatorContent</b> extension;
 * whenever every element in the drag set matches the <b>possibleChildren</b>
 * expression of an extension, it is eligible to handle the drop operation. This
 * initial set is further culled using the <b>possibleDropTargets</b>
 * expression of the <b>commonDropAdapter</b> using the current drop target.
 * </p>
 * <p>
 * If drag operations originate outside of Eclipse, then the set of eligible
 * drop adapters is determined based on the drop target (using the
 * <b>possibleDropTargets</b> expression). Each assistant can then indicate 
 * whether {@link #isSupportedType(TransferData) the incoming type is supported}.
 * <p>
 * Whenever a match is found, the assistant will be given an opportunity to
 * first {@link #validateDrop(Object, int, TransferData)}, and then if the
 * assistant returns true, the assist must
 * {@link #handleDrop(CommonDropAdapter, DropTargetEvent, Object)}. If
 * multiple assistants match the drop target, then the potential assistants are
 * ordered based on priority and their override relationships and given an
 * opportunity to validate the drop operation in turn. The first one to validate
 * will have the opportunty to carry out the drop.
 * </p>
 * 
 * <p>
 * Clients may handle DND operations that begin and end in the current viewer by
 * overriding the following methods:
 * <ul>
 * <li>{@link #validateDrop(Object, int, TransferData)}: Indicate whether this