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

Status: UNCONFIRMED

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)

Description

[Paul]

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:

https://bugzilla.mozilla.org/show_bug.cgi?id=1310287

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 gmail.com (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(....)
{
  HRESULT hr;
  MessageBox(hWnd,"test","",MB_OK);
  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 gmail.com 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

Comment 1

[Loic]

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.

Comment 2

[Paul]

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.

Thanks

Comment 3

[Loic]

Is it reproducible with a simple upload form like http://cgi-lib.berkeley.edu/ex/fup.html ?
Could you provide a upload form testcase, so I can test fastly.

Comment 4

[Paul]

Hi Loic,
I created a Gmail account for you:
user: [e-mail]
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 Gmail.com 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

Thanks

Comment 5

[Paul]

Hi!
Are there any feedback on this topic?

Thanks

Comment 6

[Loic]

Yeah, sorry, I'll test your issue today.

Comment 7

[Loic]

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.

Comment 8

[Paul]

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.

Comment 9

[Loic]

Sorry, I dont know.

Comment 10

[Firefox Bug Husbandry Bot]

https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Move_fix-optionals