Last Comment Bug 666256 - Unable to drop a file on an embedded SWF
: Unable to drop a file on an embedded SWF
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: 5 Branch
: All All
: -- major with 3 votes (vote)
: mozilla9
Assigned To: Neil Deakin
:
Mentors:
http://www.jamesrobb.com/lab/dnd/chrome
Depends on: 1079226
Blocks: 501815
  Show dependency treegraph
 
Reported: 2011-06-22 07:18 PDT by james
Modified: 2014-10-07 06:10 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch (1.46 KB, patch)
2011-07-06 10:03 PDT, Neil Deakin
bugs: review-
Details | Diff | Review
updated patch (1.47 KB, patch)
2011-08-18 10:55 PDT, Neil Deakin
bugs: review+
Details | Diff | Review

Description james 2011-06-22 07:18:38 PDT
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
Comment 1 Matthias Versen [:Matti] 2011-06-23 02:02:20 PDT
Please update to FF5 and report back (bug 655541)
Comment 2 james 2011-06-23 04:28:34 PDT
i can confirm that this issue still exists in 5.0
Comment 3 Steven Michaud [:smichaud] (Retired) 2011-06-23 13:35:45 PDT
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".
Comment 4 james 2011-06-23 14:12:07 PDT
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.
Comment 5 Steven Michaud [:smichaud] (Retired) 2011-06-23 14:25:24 PDT
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 james 2011-06-23 17:23:18 PDT
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.
Comment 7 Steven Michaud [:smichaud] (Retired) 2011-06-23 17:50:05 PDT
> 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
better.
Comment 8 james 2011-06-24 03:51:18 PDT
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.
Comment 9 james 2011-06-24 07:43:08 PDT
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?
Comment 10 Neil Deakin 2011-06-24 07:57:58 PDT
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 james 2011-06-24 08:17:26 PDT
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.
Comment 12 Neil Deakin 2011-07-06 10:03:41 PDT
Created attachment 544279 [details] [diff] [review]
patch

This patch removes the change to effectAllowed and instead just doesn't cancel the event.
Comment 13 Neil Deakin 2011-07-07 09:20:27 PDT
James, some debug builds are available here if you wish to try out this patch to see if it works for you.
Comment 14 james 2011-07-07 09:45:12 PDT
Thanks a lot Neil, whereabouts would i find the build?
Comment 16 Neil Deakin 2011-07-18 08:21:51 PDT
Comment on attachment 544279 [details] [diff] [review]
patch

Note sure how to write a test for plugins.
Comment 17 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2011-07-22 05:43:48 PDT
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.
Comment 18 Neil Deakin 2011-07-22 09:39:21 PDT
I think I had intended to use || not && there.

Or, should I just remove the untrusted event check entirely?
Comment 19 Neil Deakin 2011-08-18 10:55:56 PDT
Created attachment 554142 [details] [diff] [review]
updated patch
Comment 20 Marco Bonardo [::mak] 2011-08-24 01:28:45 PDT
http://hg.mozilla.org/mozilla-central/rev/566f15cb9c5b
Comment 22 Andy Dufilie 2014-10-03 13:41:41 PDT
This bug is back. I am running version 32.0.3.
Comment 23 Andy Dufilie 2014-10-03 18:35:46 PDT
(In reply to Andy Dufilie from comment #22)
> This bug is back. I am running version 32.0.3.

Running under Windows 7.
Comment 24 Georg Fritzsche [:gfritzsche] [away Jun 24 - Jul 3] 2014-10-07 03:51:00 PDT
Please file a new bug with more details on your specific issue.

Note You need to log in before you can comment on or make changes to this bug.