[Webkit-unassigned] [Bug 66469] window.getSelection().rangeCount does not update during a drag and drop

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=66469





--- Comment #4 from Richard York <richard at deadmarshes.com>  2011-08-18 16:17:30 PST ---
My apologies, I didn't intend to be snarky.

I didn't realize that the rangeCount property is boolean.   So what I really want is for baseOffset to update with the position of the floating caret, since it's my understanding that baseOffset provides the actual offset position of the caret within the content.   And, since you say the floating caret in a drag isn't the real caret, I believe that the floating caret that moves with the selection should be considered the 'real' caret, since that's the illusion conveyed to the user with the UI, otherwise, why draw a caret?  Well, regardless of what that line is presently considered, I think there should be some way to know where within a text node a drop has occurred, in terms of that floating caret, so that the drop operation can be manipulated and controlled with more precision and flexibility.

The objective is to be able to utilize the drag and drop API in a WYSIWYG editor, so that the user can drag and drop an item to a precision position within a body of text content.

Presently, I can think of three possible ways to approach this, but all three are unworkable:

1. You cannot detect a drop without canceling the default dragover event, therefore, you cannot manipulate a drop on the fly.  If you cancel the default dragover, you lose the floating caret, losing precision placement of a dropped element.  This could work if you could detect a drop and access the clipboard upon drop without canceling the default behavior.

2. Without being able to detect a drop, an alternative approach is to roll a custom clipboard (a hodgepodge, but theoretically possible), but since it is also impossible to detect the position of the floating caret, this approach cannot work.

3. Yet another possible approach is detecting a dragstart event, but since this event only fires on the element on which dragging began, this approach is also not workable, and that's because drag and drop can occur between multiple windows (with no DOM relationship between each window, and it even works between completely different browsers).  If a drag began in another window (or browser), you have no way to tell the originating window how the content should be formatted for the target window.

With this capability, it is possible to drag and drop items between multiple browser windows.  So, let's say in one window you're simply enabling dragging of a link, http://www.example.com.  If I can detect, either the drop, the position of the caret as it moves, or the dragstart (in the same window as the drop), I can manipulate the link on-the-fly and transform it into HTML, <a href='http://www.example.com'>www.example.com</a>, for example, and insert that HTML into the precise position of that floating caret.

Hope that explains the problem better.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.