[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 #5 from Richard York <richard at deadmarshes.com>  2011-08-18 17:06:27 PST ---
Then, I guess, a forth approach could be to transform the dropped item after the drop occurs, because again, the goal is to allow the user to drop an item to the position of the floating caret.  And this is what I am presently doing, but it is ugly and not as efficient or fluid as I'd like it to be.

Ideally, you'd be able to call an event when a drop occurs, but I can't attach a callback to the drop event, because I want the default action, the floating caret.  And since that's not possible, I tried the mouseup event, but that event, of course, doesn't fire when a drag and drop occurs.

What I'm stuck with is doing an event after the drop has occurred, such as a subsequent click on the contenteditable region.  This is not desirable, because you don't see the correctly formatted markup until you do something else with the editable element, so it appears to be buggy to the user.

Then, it's also not very efficient, because you have to continuously re-examine the editable content for things that have been dropped but need to be fixed.

So, with regards to webkit itself, I guess there turn out to be two bugs, at least in my opinion, though in pursuit of the functionality I describe, there are several things I think that could be improved in general.  1. The position of the floating caret cannot be detected as a drag is taking place, because the floating caret isn't considered to be the real selection caret.  2. There is no event (that I'm aware of, perhaps I'm wrong) that can be fired to detect that a drop has occurred while at the same time allowing the default behavior to commence, perhaps fixing that is as easy as letting the drop event fire without having canceled the default behavior.

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