Open Bug 1345492 Opened 4 years ago Updated 3 years ago

Very strange problem in recent version of Firefox with the drag and drop


(Core :: DOM: Drag & Drop, defect, P5)

52 Branch



Tracking Status
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- ?


(Reporter: glombovsky, Unassigned)


User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; InfoPath.3; rv:11.0) like Gecko

Steps to reproduce:

I've put a bug few month ago and the ticket was closed but the bug is still there:

I have a very strange issue with Firefox 49.0.1 (it was not present in previous versions like 37.x)
I am a C++ developer and I must code a third party product that (between other things) has to tansform uploaded files into other files. My program is an external program. It is basically a .dll library that is injected into Firefox.exe and I intercept (using hooking mechanisms) the RegisterDragDrop API. Once Firefox.exe calls (my) RegisterDragDrop, instead of returning the Firefox IDropTarget COM interface I return my own IDropTarget COM interface. So when a user drags a file into Firefox my IDropTarget COM interface is called instead.
At this point my logic is "very simple" since I create a kind of wrapper: I have my own IDropTarget COM interface. When the user drags a file to (to add an attachment) then my IDropTarget::DragEnter, IDropTarget::DragOver, and IDropTarget::Drop methods are called.
What I do in them is to directly call the Firefox original IDropTarget (that's why I say it's a pretty straightforward implementation). 
However in the Drop method I do:
HRESULT Drop(....)
  return OriginalIDropTarget->Drop();

I really need these 3 seconds because what I do is to do some transformations to the file that will take time.

It works pretty nice in hotmail, yahoo, facebook... that is, the user drops a file and the drop action takes 3 seconds and then the file is finally dropped OK.
However in it does not work: Most of the times nothing is attached. If I reduce this sleep to 500 or 600 milliseconds then it works.

See that the only difference is this sleep of 3 seconds before calling the original IDropTarget.Drop event.

Has something changed in the recent releases?

Thanks in advance.

Actual results:

no attachment was shown

Expected results:

an attachment should be shown
Component: Untriaged → Drag and Drop
Product: Firefox → Core
I don't have Gmail, does your DLL works for another webmail like Yahoo Mail?

If yes, I can test myself and try to find a regression range.
Flags: needinfo?(glombovsky)
Hi Loic,
Thanks for your answer.
Actually my .dll works on any upload form. However in Gmail (specially in Windows 10) I can always reproduce this issue. In other webmails I cannot reproduce it. I guess it depends on the way the upload control is used, in Gmail there is something special.

Is it reproducible with a simple upload form like ?
Could you provide a upload form testcase, so I can test fastly.
Hi Loic,
I created a Gmail account for you:
password: mypassword17

Steps to reproduce:
1+ Copy InjectFirefox.exe and TestFFXBug.dll in any folder
2+ Launch InjectFirefox.exe (at this point it will be loaded in memory, you can see it by opening the task manager)
3+ Open Firefox (32 bits, Windows 10 better)
4+ Go to and log in using the above user and password
5+ Create a new memo
6+ Open a folder in Windows Explorer and drop a file inside the new email
7+ You will get the "Inside drop event" message box and after that nothing will be attached

Are there any feedback on this topic?

Yeah, sorry, I'll test your issue today.
Flags: needinfo?(glombovsky)
I tested with FF52, and I think the issue is due to incompatibility with e10s (multiprocess) and accessibility.
If I disable e10s (about:config > browser.tabs.remote.autostart=false and browser.tabs.remote.autostart.2=false, restart Firefox), it works fine.

Could you confirm?

NB: to be sure e10s is disabled (by you, by add-ons or by accessibility tools), check the line "multiprocess windows" in the page about:support.
Flags: needinfo?(glombovsky)
sorry but it is still not working.... I switched the values to false (one of the was already set to false) but after restarting FF it does not work.
Flags: needinfo?(glombovsky)
Sorry, I dont know.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.