Open Bug 1345492 Opened 7 years ago Updated 2 years ago

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

Categories

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

52 Branch
defect

Tracking

()

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

People

(Reporter: glombovsky, Unassigned)

Details

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

Thanks
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.
Hi Loic,
I created a Gmail account for you:
user: FirefoxTest2017@gmail.com
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
Hi!
Are there any feedback on this topic?

Thanks
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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.