fixes for the drag & drop behaviour:
fixes for the drag & drop behaviour:

- when dropping on a nondroppable, e.g. when dragging a file on top of another file, the operation was not correctly reverted/aborted. This includes not hiding the download/rename/delete icons, while the mouse pointer will definitely hover over some other place right now, so the regular code has no chance there to reset the icons to invisibility.

- when dropping a file onto a directory, two requests would be fired simultaneously: a 'move' (or 'copy') and a 'detail' (!) request for the dragged item: the latter request however does erratically collide with the move, forcing the 'move' to fail as the server reports it cannot do so due to the source being locked by another tread accessing it (the 'detail' view sniffing mime type). Since, on a move, fetching 'detail' for an item that will be gone from view in very short order is nonsense anyway, so a drag&drop state indicator is added to the class and any 'detail' requests are blocked from being executed as long as the 'drop' operation is still pending.

cpojer/mootools-filemanager,cpojer/mootools-filemanager