Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

RESOLVED FIXED

Status

()

Core
General
--
major
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: jpvincent, Assigned: Neil Deakin (not available until Aug 9))

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
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
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.

Updated

7 years ago
Component: General → General
Keywords: testcase-wanted
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
(Reporter)

Comment 2

7 years ago
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
(Reporter)

Comment 3

7 years ago
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
Created attachment 489251 [details] [diff] [review]
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.
Assignee: nobody → enndeakin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Created attachment 489253 [details]
testcase

Updated

7 years ago
Keywords: testcase-wanted
It would be good to fix this to allow drop effects to be more useful and compatibility with other browsers.
Attachment #489251 - Flags: review?(Olli.Pettay)

Updated

7 years ago
Attachment #489251 - Flags: review?(Olli.Pettay) → review+
Attachment #489251 - Flags: approval2.0?
(Reporter)

Comment 7

7 years ago
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 ?
OS: Windows 7 → All
Attachment #489251 - Flags: approval2.0? → approval2.0+
There's no way to test this using mochitest? What about mozmill?
No, drag and drop tests that require the native api to be called cannot currently be tested automatically.
http://hg.mozilla.org/mozilla-central/rev/1bb96fbc54f8
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

7 years ago
that means I can test the fix in a FF4 nightly release ?
You can.
You need to log in before you can comment on or make changes to this bug.