New issue
Advanced search Search tips

Issue 501655 link

Starred by 4 users

Issue metadata

Status: Duplicate
Owner: ----
Closed: Oct 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

When drag-and-dropping, dropEffect not updated; allowedEffects incorrectly updated

Reported by teleclim...@gmail.com, Jun 18 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36

Example URL:
http://jsfiddle.net/teleclimber/hwvo4m3o/

Steps to reproduce the problem:
1. Visit http://jsfiddle.net/teleclimber/hwvo4m3o/ and open the console
2. select some of the text and click + drag
3. while dragging press the command or option modifier keys to trigger different dropEffects.

What is the expected behavior?
Console should show that event.dataTransfer.effectAllowed is always "copyMove" while event.dataTransfer.dropEffect should reflect the user's intent which is determined by the modifier keys.

What went wrong?
event.dataTransfer.dropEffect is "none" and stays that way. Meanwhile event.dataTransfer.effectAllowed changes value depending on what modifier keys are pressed.

The spec says dropEffect should be updated. The value depends on a while slew of things, but in this scenario it is not supposed to remain "none". 

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 43.0.2357.124  Channel: stable
OS Version: OS X 10.8.5
Flash Version: Shockwave Flash 18.0 r0

I've never seen dropEffect updated. It doesn't matter if you preventDefault() on various events. You can also add an event for "drop" and it too shows "none" for dropEffect while the allowedEffect seems to reflect the user's intent.

This also seems to be messing with my ability to actually perform a "Drop". But I might file a separate bug.

Firefox works as expected.
 

Comment 1 by b...@chromium.org, Jun 18 2015

Labels: Cr-Blink-JavaScript
 Issue 501983  has been merged into this issue.
Cc: haraken@chromium.org bashi@chromium.org
Labels: M-45
Status: Untriaged
Able to reproduce the issue on mac 10.10 chrome version 43.0.2357.124 and canary - Please find the screenshot for output

This is  a non regression issue existing since M26 builds
Working fin eon Firefox browser - "dragenter copyMove move" is displayed
Screen Shot 2015-06-19 at 3.48.40 PM.png
125 KB View Download

Comment 4 by sigbjo...@opera.com, Jun 19 2015

Labels: -Cr-Blink-JavaScript Cr-Blink-DataTransfer

Comment 5 by tkent@chromium.org, Jul 10 2015

Labels: -Cr-Content

Comment 6 by dpidcock@google.com, Oct 26 2015

Related : 
visit http://jsfiddle.net/1c5dnd3e/3/
Open the console.

Drag the rectangle into top target and drop. 

Note that the dropEffect of the event when it reaches the onDrop handler is reset to "none" even though the spec says it should be the "current drag operation".

Note that the "dragend" event dropEffect value has been set to the current drag operation (as expected), but the effectAllowed is reset to "uninitialized".

NOW -- drag the element into the bottom target.

Note -- the dropEffect does not change to "move" as expected (ondragover is set to preventDefault so this should not have changed from the dragEnter that set it to "move" -- it has instead reverted to "copy")






Comment 7 by dcheng@chromium.org, Oct 26 2015

Mergedinto: 39399
Status: Duplicate
We use some heuristics to guess at a dropEffect in dragend, but we don't want to guess a destructive dropEffect ("move") so we always select "copy".

We have to do this guessing, because we are unwilling to block the browser UI loop on the renderer dispatching the drop event. Without blocking the browser UI loop on the actual results of the drop event, it's impossible to resolve dragend correctly =/

Comment 8 by dpidcock@google.com, Oct 27 2015

I'm not sure how the behaviour observed is explained by your comment. 
Unless you mean that the heuristics are applied in dragover (which is compatible with my observations -- dropEffect set in drag-enter is "forgotten" in drag-over). 

According to the fiddle,  drag-end always gets the dropEffect that should be expected by drop (at least insofar as it is changed by the drag-over handlers).

the drop handler always gets "none" , regardless of the state of the drag event as it is when passed to drag-enter and drag-over and drag-end.

If I were to hazard a guess, it looks like the "dropEffect" logic for drag-end and drop has been swapped when compared to the spec.


Comment 9 by dcheng@chromium.org, Oct 27 2015

I wouldn't be entirely surprised if parts of this have regressed. The UI stack was converted to use Aura a few years ago, and we periodically find things that got missed in the adaptation.

That being said, dropEffect not being initialized correctly is largely still due to issue 39399: at the time, I didn't implement the spec, since the spec didn't match the behavior of any browser. It sounds like that may no longer be the case.

Sign in to add a comment