[whatwg] Drop event on form controls

[Sebastian Markbåge]

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-0002.htm>