User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Up to version 3.6.18 (i've tested this in 3.5.19 and 3.6.18) the default behaviour when dragging a file from the desktop on to an embedded SWF within Firefox, was for the file to be dropped onto the SWF. Nothing actually happens at this point, but it did allow you to drop the file. Since 4.0.1 (also in 5) if you do this, it will no longer allow you to drop the file onto the SWF, but instead animates it back to where it was dragged from. For this reason, in 3.6.19 it was possible to use HTML5 drag and drop with flash, but in 4.0.1 this is no longer possible, as the 'drop' event is never fired, as it will no allow you to drop the file on the embedded SWF. If you test the supplied URL in 3.6 you'll see that you can drop files onto the SWF and it will actually load the file into the SWF. This example is using HTML5 drag and drop to facilitate this action. If you go to any normal flash website (that doesn't implement HTML5 drag and drop) and attempt to do the same, you'll see the old default behaviour in action. But if you try the same in 4 or 5, you'll see that this is no longer the case. Reproducible: Always Steps to Reproduce: 1.drag a file from your desktop onto a Flash website 2.drop the file 3. Actual Results: The file animates back to it's original position on the desktop and does not drop onto the flash site Expected Results: the dragged file icon should drop onto the flash site and disappear
Please update to FF5 and report back (bug 655541)
i can confirm that this issue still exists in 5.0
I can reproduce this on OS X 10.5.8, and something similar on Windows XP. I see it with all plugins -- not just Flash. This behavior seems to have started with the firefox-2009-08-27-03-mozilla-central nightly, and is almost certainly fallout from the patch for bug 501815: http://hg.mozilla.org/mozilla-central/rev/4ee238eba089 The patch's comment seems to indicate that it's up to the plugin to change this behavior (or not). But I frankly don't know how plugin support for drag-and-drop is supposed to work, so I don't know how the plugin can do this. There isn't any explicit support for drag-and-drop in the NPAPI. Since nsPluginInstanceOwner::HandleEvent() is called (indirectly) from nsEventListenerManager::HandleEvent(), maybe the plugin is supposed to use the NPRuntime to install an event listener for drag events (which are DOM events). But I don't know how this would work. James: Judging by the fact that your testcase plugin can tell when it receives what it calls drag-enter and drag-leave events, maybe the Flash plugin already has high-level support for what I describe in the previous paragraph (installing an event listener for drag events). And so maybe it also provides high-level support for setting the nsIDOMDataTransfer's effectAllowed attribute to something other than "none".
I've tested two examples locally and in 4.0.1 and 5.0 dropEffect='move' and affectAllowed='uninitialized'. The source can be found here, http://www.thecssninja.com/demo/drag-drop_upload/v2/ http://www.smilingsouls.net/Blog/20110413023355.html http://www.smilingsouls.net/dnd.html It appears that, as you suggest above, the value for effectAllowed has been changed to 'none' for plugins, to fix another issue. Which has subsequently created this bug.
Thanks Steven, i now have it up and running after checking the MDN and W3C docs https://developer.mozilla.org/En/DragDrop/DataTransfer http://dev.w3.org/html5/spec/Overview.html#drag-data-store-allowed-effects-state Setting it in the dragenter event handler as suggested in the docs appears to make no difference, as it's reset to the original value of 'none' in the dragover event phase. However, if it's continually set to the required value in the dragover handler - event.dataTransfer.effectAllowed='all' in my case - then the drop is allowed to occur and completes successfully. This can be seen in action below and works in 3.6.18, 4.0.1 and 5.0 http://www.jamesrobb.com/lab/dnd/ I'm curious as to whether or not this would still be considered an issue, as the default behaviour appears to have been modified in the case of plugins, purely to fix another bug?
Are you saying that dropping files doesn't get received by a flash object when a it used directly in a page with no other script in it? Your example is using dataTransfer, so it's unclear to me if you're referring to some issue with dataTransfer or not. A simpler testcase would help here.
Created attachment 544279 [details] [diff] [review] patch This patch removes the change to effectAllowed and instead just doesn't cancel the event.
James, some debug builds are available here if you wish to try out this patch to see if it works for you.
Thanks a lot Neil, whereabouts would i find the build?
Whoops, forgot the link: http://email@example.com/
Comment on attachment 544279 [details] [diff] [review] patch Note sure how to write a test for plugins.
Comment on attachment 544279 [details] [diff] [review] patch Could you explain the patch? Why do we want to call PreventDefault on certain untrusted events? That looks wrong to me, especially because ::HandleEvent should receive only trusted events.
I think I had intended to use || not && there. Or, should I just remove the untrusted event check entirely?
Created attachment 554142 [details] [diff] [review] updated patch
This bug is back. I am running version 32.0.3.
(In reply to Andy Dufilie from comment #22) > This bug is back. I am running version 32.0.3. Running under Windows 7.
Please file a new bug with more details on your specific issue.