JMJimmy wrote:Edit 2: Further information, I've narrowed it down. If you drag after a newline character but still within the textarea, or after the EOF equiv for the textarea the behaviour changes from Firefox default to Quickdrag. The expected is that if you drop it after a newline/EOF that the text drops in and wraps appropriately or generates the 'can't move here' symbol. This is overridden by QuickDrag to assume whitespace even though it's still within the textarea.
Oh, okay, I see what you mean now. When you drag within/into/between an editable area (text box, text area, contenteditable), the default built-in behavior draws an insertion point (the vertical line that tells you where stuff will be dropped) if action is valid, and in that case, QD will not interfere in any way. If the action is not valid (basically, if you are dropping a selection in the same location as before), then the default built-in behavior will disable itself. If QD is not installed, then you will get the you-cannot-drop-here mouse cursor, and if QD is installed, then, since the default drag behavior has declined to handle the drag, the event will bubble up to QD.
Your "EOF" thing is actually just a special case of this. If your selection extends to the very end of the editable area, then any attempts to drop it at the end will be deemed invalid (since your selection is already at the end). If you select everything except for the last character, then dropping past the "EOF" will be valid and will work.
Anyway, I don't think that this behavior should be classified as a bug. Because the only time that QD is "overriding" the default behavior is when the default behavior has declined to handle the drag. IOW, it would have been a drag-not-allowed scenario. If the drag was legal and allowed, the event would never have bubbled up to QD, and QD would not have been involved--QD will never prevent you from drag-and-dropping text into, within, or between editable areas
So the question is, if the drag is not a valid move operation, should it be a no-drag-allowed? On one hand, it would make it clearer to the user that this drag is not valid if the user was intending a move (you could always look to see if the insertion marker is being drawn, but that is not as obvious). On the other hand, I personally find this behavior to be useful. I sometimes need to search for some text that has been typed into a text box. I can select the text and drag it just a few pixels (so that the mouse is still over the selected text, which would make this an invalid move operation since the position's still the same) to search, whereas if QD also declined to handle it, then I would have to drag all the way out of the editable area before QD will handle it (which is annoying for big multiline boxes). So there are benefits and downsides to both approaches of handling this.
In any case, QD is only handling drags that the other handlers have all declined to handle, so this is not a bug. I can see why you might want the no-drag-allowed behavior instead, so I will give this some consideration as a potential feature request...