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.
Steps to Reproduce:
1.drag a file from your desktop onto a Flash website
2.drop the file
The file animates back to it's original position on the desktop and does not drop onto the flash site
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:
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
Apologises if this is a slightly misleading example, but it's what i was working on when i came across this issue and seemed a good way to demonstrate it.
But I'm not sure how this could be handled from inside a plugin, except at a very low level (i.e. by using NPRuntime directly).
Thanks Steven. It appears that the default for most other browsers (i couldn't find them specified in the W3C specs) are dropEffect='none' and effectAllowed='all', where as in Firefox 3.6.18 they were dropEffect='move' and effectAllowed='move', but in Firefox 4.0.1 and 5.0 they're now dropEffect='move' and effectAllowed='none'.
The only point at which this value is writable is during the 'dragstart' event phase, which is only fired when dragging an element within the browser, not from your machine too the browser. So as far as i can tell, it's not actually possible to change this value.
> examples that work in Firefox 4 and 5 and having checked their
> source, none of them actually set 'effectAllowed' from it's default,
> so i'm not convinced this is what's causing this issue.
Could you reference an example or two? The simpler the example, the
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,
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
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
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.
Without the implementation of the DOM drag events, when you drag any image off your desktop onto either a html site or flash site, they react in exactly the same way and are simply replaced by the image.
And with the DOM drag events implemented, they also react exactly the same and there's no need to set any specific values in order for the flash version to work.
This is not the case with Firefox since version 4.0.1.
The reason for this change since that version appears to be the fallout of another issue that was fixed, as mentioned in comment #3's second paragraph.
Created attachment 544279 [details] [diff] [review]
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:
Comment on attachment 544279 [details] [diff] [review]
Note sure how to write a test for plugins.
Comment on attachment 544279 [details] [diff] [review]
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
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]
and fixed for qt builds
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.