Unable to drop a file on an embedded SWF

RESOLVED FIXED in mozilla9



6 years ago
3 years ago


(Reporter: james, Assigned: Neil Deakin (mostly unavailable until September))


(Depends on: 1 bug)

5 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(1 attachment, 1 obsolete attachment)



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

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


6 years ago
Version: unspecified → 5 Branch
Please update to FF5 and report back (bug 655541)

Comment 2

6 years ago
i can confirm that this issue still exists in 5.0
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
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
Ever confirmed: true
OS: Mac OS X → All
Hardware: x86_64 → All

Comment 4

6 years ago
Steven: The test case is simply detetcting the the HTML5 drag events on the div that flash is embedded in and then the data is being passed back to the SWF via Javascript. Non of the behaviour shown is native to Flash, it's merely using Javacript to pass the dragenter, dragover, dragleave and drop events of the div/HTML5 back to the swf so that it can display the result.

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.
So, James, you can use JavaScript to do what I suggest in the last paragraph of comment #3.

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).

Comment 6

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

Saying that, there are plenty of existing pure HTML5/Javascript 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.
> Saying that, there are plenty of existing pure HTML5/Javascript
> 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
Blocks: 501815

Comment 8

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

Comment 9

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

Comment 11

6 years ago
Neil, it's not actually possible to create the functionality i've shown in the example purely in flash, it's only possible with the help of Javascript. Which leads me to believe this is not actually a plugin based issue. This may be a slightly contentious statement (and i'm certainly not saying they're right), but the default behaviour for all other browsers that i've tested (Chrome, Safari and Opera), is to treat an embedded SWF in exactly the same way as any other HTML Element.

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.
Assignee: nobody → enndeakin
James, some debug builds are available here if you wish to try out this patch to see if it works for you.

Comment 14

6 years ago
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.
Attachment #544279 - Flags: review?(Olli.Pettay)
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
trusted events.
Attachment #544279 - Flags: review?(Olli.Pettay) → review-
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
Attachment #544279 - Attachment is obsolete: true
Attachment #554142 - Flags: review?(Olli.Pettay)


6 years ago
Attachment #554142 - Flags: review?(Olli.Pettay) → review+
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
and fixed for qt builds

Comment 22

3 years ago
This bug is back. I am running version 32.0.3.

Comment 23

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


3 years ago
Depends on: 1079226
You need to log in before you can comment on or make changes to this bug.