- From: Sebastian Markbåge <sebastian@calyptus.eu>
- Date: Thu, 22 Oct 2009 01:21:34 +0200
I agree, IE and Firefox dispatches the drop event for both form controls and contentEditable even if dragover isn't canceled. They insert the dropped data unless drop event is canceled. WebKit (Windows) inserts the dropped data but doesn't fire the drop event. If dragover is canceled, then WebKit doesn't insert the dropped data but it does fire the drop event. I tend to agree with the IE and Firefox model. That's more useful. If the default operation is to allow a drop, then you shouldn't have to "prevent default" it to get the drop event. If the default operation isn't to allow a drop, then it shouldn't. Also, the inserted text should be inserted unless the drop event is canceled. But not if preventDefault is called. On Wed, Oct 21, 2009 at 5:07 PM, Olli Pettay <Olli.Pettay at helsinki.fi>wrote: > contentEditable may need special handling too. > Haven't tested how IE (or other browsers) handles that. > > > -Olli > > > On 10/21/09 3:15 PM, Olli Pettay wrote: > >> Hi all, >> >> seems like the draft doesn't specify properly what should happen when >> dropping something to a (text) form control. >> >> The draft says that if dragover isn't canceled, then drag operation >> becomes none, and then later "if the current drag operation is none... >> then the drag operation failed." >> >> Seems like dragover needs to have some default handling when dispatched >> to form controls. >> IE does dispatch a drop event when dragging something to a form control. >> >> br, >> >> -Olli >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091022/9464ff9c/attachment.htm>
Received on Wednesday, 21 October 2009 16:21:34 UTC