610378 - drop event is not fired when trying to set a value to dataTransfer.dropEffect other than 'move'

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[jpvincent]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b5pre) Gecko/20100822 Minefield/4.0b5pre

when defining a drag&drop operation, in FF4 only, if I try to modify the dataTransfer.dropEffect property in the 'dragover' callback method, the final 'drop' event is never fired

Reproducible: Always

Steps to Reproduce:
on('dropthere', 'dragover', function(e) {
	e.dataTransfer.effectAllowed = 'copy';
});

"on", being a cross-browser method to set a listener, 'dropthere' being a DIV id. If we remove the effectAllowed assignment, the 'drop' is fired.
Actual Results:  
the 'drop' callback is never called

Expected Results:  
the 'drop' callback should be called

I tested Minefield with Windows Seven only
assigning the dataTransfer.effectAllowed to  'copy' works in a lot of other browsers / OS : 
- IE6 to IE9 on XP, Vista and Seven
- FF 3.6 Mac
- Chrome and Safari on Mac and Windows

the cursor is modified and the 'drop' event is called

Comment 1

[Neil Deakin]

Actaully no, since you haven't cancelled the event, the drop event should not be fired. Setting effectAllowed shouldn't have any effect.

Hard to tell though without a proper testcase.

Comment 2

[jpvincent]

Yes I'm cancelling the dragover event

here is a test page, with 2 drop areas, sharing exactly the same callback functions for the each event, except the dragover

- open http://sandbox.timeofmylife.com/sandbox/upload.php
- open the console of the browser (even IE7-9 developer tools)
- take a file on the desktop, drag it over the FIRST target area, you should see a bigger font and logs in the console for each key events : 1 dragenter,  lots of dragover
- you should see the cursor being modified
- drop the file, you should see DROP in the console (then the upload starts and fails, but it's not the point here)

FF4b6 is the only browser not to throw the DROP event.

now do the same on the SECOND drop area, the DROP event is throwned even in FF4b6, because I commented this line in the callback method :
e.dataTransfer.dropEffect = 'copy';
consequently there is no cursor when hovering this area with a file

Comment 3

[jpvincent]

more insights : FF3.6.6 on Mac and XP and Seven behave the same way : when defining the dropEffect to 'copy' or 'move' or even 'link', the DROP event is never fired. In addition, on Seven the cursor is always some kind of "forbidden" sign, so the behaviour seems consistent here : 
on all versions and platforms Firefox indicates he refuses to drop something when in the dragover callback we set dropEffect to any value

However it seems that this behaviour is wrong as the HTML5 drop specifications have been copied from the IE implementation and that IE6-9 + Chrome and Safari behave the same way for this case

Comment 4

[Neil Deakin]

Attachment: Patch

I'd actually discovered the bug a while ago but hadn't ever fixed it.

This patch fixes the initialization of effectAllowed to be 'uninitialized' when an external drag is used. Without the patch, it was set to 'move' and preventing 'copy' from being a valid drop effect.

Note that you should be able to workaround the bug by explicitly setting effectAllowed to 'copy' or 'all' during the dragover event.

Comment 5

[Neil Deakin]

Attachment: testcase

Comment 6

[Neil Deakin]

It would be good to fix this to allow drop effects to be more useful and compatibility with other browsers.

Comment 7

[jpvincent]

thanks for the workaround, it let it work on FF4b6 Vista + Seven, FF3.6 XP and FF3.6 Mac OS, but :

- IE8 throws an exception (unexpected access to property or method ...), so I cant use it without browser sniffing
- the displayed cursor is not the good one on FF3.6 on Seven : it's move, instead of copy. The cursor is correct with IE8 and Chrome on this OS
- there is still no cursor at all on FF3.6 Mac OS X, but maybe should I raise another bug for that ?

Comment 8

[Benjamin Smedberg]

There's no way to test this using mochitest? What about mozmill?

Comment 9

[Neil Deakin]

No, drag and drop tests that require the native api to be called cannot currently be tested automatically.

Comment 10

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/1bb96fbc54f8

Comment 11

[jpvincent]

that means I can test the fix in a FF4 nightly release ?

Comment 12

[Neil Deakin]

You can.