UNCONFIRMED 108021
WebKit provides wrong dropEffect on dragend/drop events
https://bugs.webkit.org/show_bug.cgi?id=108021
Summary WebKit provides wrong dropEffect on dragend/drop events
danya.postfactum
Reported 2013-01-26 19:17:20 PST
At least while dragging from external application. So, I need to remember the drag operation on last dragover event. But external app get wrong dropEffect also, so it cannot properly handle dragging with 'move' operation, for example. Can it be fixed? I'm just web-developer, I don't know C++ ((
Attachments
Testcase for wrong dropEffect on drop event (881 bytes, text/html)
2013-01-27 02:05 PST, danya.postfactum
no flags
danya.postfactum
Comment 1 2013-01-26 19:18:33 PST
Alexey Proskuryakov
Comment 2 2013-01-26 23:18:11 PST
Please post detailed steps to reproduce this issue. This bug is not actionable in its current state.
danya.postfactum
Comment 3 2013-01-27 02:05:16 PST
Created attachment 184905 [details] Testcase for wrong dropEffect on drop event Open attachment, select the text you see in the document, drag and drop it in any place on document. Browser should output dropEffect: copy. Instead webkit-based browsers output dropEffect: none dragstart handler sets dataTransfer.effectAllowed to 'copyMove'. dragover handler sets dropEffect to 'copy'. According to http://dev.w3.org/html5/spec-preview/dnd.html#dom-dragevent-datatransfer , browser should set dropEffect attribute "to the value corresponding to the current drag operation if e is drop or dragend;" Since current drag operation is 'copy' (defined according to dropEffect), webkit provides 'none', what is the current issue. Firefox, Opera work as expected. IE also has this bug. Thanks for attention.
Tony R.
Comment 4 2015-01-07 16:29:19 PST
Almost 2 years later? Wow… I just discovered this bug. At first I set `event.dataTransfer.dropEffect` to `'move'` according to prescribed writings on the web. But when I checked the value in `drop` handler, the value was `'none'`. Out of frustration, I eventually started setting it in EVERY handler. But in `drop` handler, it is always `'none'`. Please consider this an enthusiastic +1 for this bug!
Lucas Forschler
Comment 5 2019-02-06 09:18:43 PST
Mass move bugs into the DOM component.
Ahmad Saleem
Comment 6 2024-02-07 21:58:15 PST
*** Safari Technology Preview 188 / WebKit ToT *** dropEffect: none *** Chrome Canary 123 *** dropEffect: none *** Firefox Nightly 124 *** dropEffect: copy ____ Just posting latest results. Thanks!
Note You need to log in before you can comment on or make changes to this bug.