Bug 37012 – dropEffect not set to correct default values in dragenter / dragover

• Status: NEW
• Component: UI Events

[Daniel Cheng]

Per the section on the initialization of event.dataTransfer.dropEffect, dropEffect's initial value should not be "none" during dragenter / dragover.

[Daniel Cheng]

Created attachment 52380 [details]
Testcase

[Daniel Cheng]

Created attachment 52381 [details]
Patch

[Daniel Cheng]

Created attachment 52383 [details]
Patch

[Daniel Cheng]

Created attachment 52384 [details]
Patch

[Daniel Cheng]

Created attachment 52399 [details]
Patch

[Daniel Cheng]

Created attachment 52506 [details]
Patch

[Tony Chang]

Adding bweinstein who I think originally set these values in http://trac.webkit.org/changeset/53287

[Daniel Cheng]

Created attachment 52580 [details]
Patch

Fix incorrect initialization, remove unnecessary contentEditable handling.

[Oliver Hunt]

Can you please compare the test results with that produced by mozilla?

[Daniel Cheng]

Firefox's behavior differs slightly from the spec:
From DOM-initiated drags, if effectAllowed is "all", "copyMove", "linkMove", or "uninitialized", the default dropEffect is "move".

Firefox doesn't seem to set effectAllowed to "uninitialized" for drags from text boxes. When dragging links, effectAllowed is set to "uninitialized" but default dropEffect is set to "move".

[Daniel Cheng]

From IRC:

< dcheng> olliej: just curious if you're interested in reviewing https://bugs.webkit.org/show_bug.cgi?id=37012 since you commented on it a few days ago.
< olliej> dcheng: does the new behaviour match ie?
< olliej> dcheng: matching the spec comes secondary to matching what implementations do -- the spec for dnd is mostly an attempt to reverse engineer what browser already did
< dcheng> I'll check.

Results can be found at http://spreadsheets.google.com/pub?key=tPZ1c0LEi4RBJ2CG4jV13Fw&output=html

What's the proper approach here? If you don't mind, I'll update the patch to follow IE behavior and email whatwg@ for clarification on why the spec differs from IE in that respect.

[Daniel Cheng]

Created attachment 53910 [details]
Expanded test page

[Daniel Cheng]

Updated the page with information for Firefox and Safari. I also found some interesting issues that seem to be specific to Safari.

[Oliver Hunt]

Created attachment 53997 [details]
drag/drop testcase

[Ojan Vafai]

Ian, can you comment on the specced behavior for dropEffect? It seems what's currently specced doesn't match any browser, assuming dcheng's testing was correct of course. Was that intentional?

I looked, but couldn't find any relevant discussion on whatwg@ about dropEffect.

dcheng, maybe it's worth writing an email to whatwg@ with your data?

[Adam Barth]

Comment on attachment 52580 [details]
Patch

It looks like this change is blocked on interacting with the whatwg.  Ideally, we'd get the spec updated to the desired behavior and the change all the implementations to match.  Feel free to re-nominate for review (or to post a new patch) once we've got the spec onboard.

What is the current status of this bug report ?

On reviewing this case, it appears that if the value of datatransfer.effectAllowed is set in dragstart, it is supposed to be retained during the drag, but it's being reset to "all" sometime before the dragenter event. This means that drag sources can't specify that they only allow copying, moving or linking from their data. 

You may need to solve both of these to actually "fix" this bug.