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

Status: RESOLVED INCOMPLETE

(Firefox :: Untriaged, defect)

Description

[Paul]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2486.0 Safari/537.36 Edge/13.10586

Steps to reproduce:

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;
  Sleep(3000); //Sleeps 3 seconds
  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:

Nothing was attached


Expected results:

A file should be attached

Comment 1

[Loic]

Hard to say without possibility to test.

As you are able to reproduce the issue, you can download the tool mozregression to narrow down a regression range. See http://mozilla.github.io/mozregression/ for details to use it.
Run the command "mozregression --good=48 (or older like 37)" then copy here the final pushlog.

Comment 2

[Paul]

Attachment: files.zip

This .zip file contains two 32 bits files inside. A .exe that injects the .dll in the Firefox.exe process. So just run the .exe and you will see it in memory (task manager). Then each time you start Firefox.exe, the .dll will be injected in Firefox.exe. Every time you drop a file inside a Gmail new message a message box will appear. This message box is display just in the IDropTarget->Drop() COM method. The fact that this message box is displayed, prevents (in most cases) the drop from getting successfully processed (that is, no file is attached). I was always able to reproduce it in Windows 10, but not in Windows 8.1.

Comment 3

[Paul]

I tested what you suggested.
I started from version 49 (where it did not work) and getting back until finding a version that was working fine.
In version 40.0a1 (2015-03-30) the drag&drop into a gmail message did not work (this was without our program installed). The forbid cursor was shown. The same happened in hotmail.com for example. So here it seems that you detected a bug that was finally fixed in 41.0a1.
In version 39.0a1 the same issue happend (forbid cursor was shown while trying to do a drag&drop of a file into a gmail message).
In version 38.0a1 the bug was the initial but I reported (the file drag&drop was "allowed" but nothing was finally dropped when using my program). 
In 37.0.a1 there was no problem, everything was working OK. So it seems the issue started at version 38.0.a1.

I coded a little .exe and .dll that will help you to reproduce the issue and added it as an attachment to this post:

This .zip file contains two 32 bits files inside. A .exe that injects the .dll in the Firefox.exe process. So just run the .exe and you will see it in memory (task manager). Then each time you start Firefox.exe, the .dll will be injected in Firefox.exe. Every time you drop a file inside a Gmail new message a message box will appear. This message box is display just in the IDropTarget->Drop() COM method. The fact that this message box is displayed, prevents (in most cases) the drop from getting successfully processed (that is, no file is attached). I was always able to reproduce it in Windows 10, but not in Windows 8.1.

Comment 4

[Kanchan Kumari QA]

Hello Paul, Thanks for reporting the issue. 
I tried to reproduce the issue with your test case with following steps:
1. Save/extracted the zip file
2. Run InjectFirefox.exe file
3. Ensure InjectFirefox.exe in task manager
4. Opened Firefox 
5. Drag and drop file in new composed Gmail

I was able to drop file and attach it to my mail  without any message box. Let me know if I am missing anything.

If you use mozregreesion https://mozilla.github.io/mozregression/, this will give you a pushlog which will help in finding the changeset/bug that regressed this issue.
You can start with --good 41 and --bad 49

Comment 5

[Paul]

Hi again,
Did you extract the .zip file .dll and .exe in the exact same folder?
I just extracted the TestFFXBug.dll and InjectFirefox.exe in the same folder, launched InjectFirefox.exe, then Launched Firefox and when composing a new Gmail message I get a "Inside Drop Event" message box.
The Firefox.exe must be 32 bits.
Do you have a way to confirm that TestFFXBug.dll got injected in Firefox.exe (e.g. using Process Explorer from sysinternals)?

Best regards,
Paul

Comment 6

[u554753]

Hi Paul,

I can reproduce this with the following specs: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0

Comment 7

[Kaartic Sivaraam]

I am able to reproduce this in Windows 7 using Firefox version 49.0.2 

My user agent is Mozilla/5.0 (Windows NT 6.1; rv:49.0) Gecko/20100101 Firefox/49.

Comment 8

[Paul]

Several persons were able to reproduce it with the binaries I sent.
Is there any news about fixing it?
Thanks

Comment 9

[u554753]

Hi Paul, 

Are you able to do a MozRegression on this issue? With the info from that, we can pinpoint exactly what version of Firefox this issue began occurring? 

You can set it up per Comment 1 and Comment 4.

Comment 10

[u554753]

Closing due to lack of response. If you feel this issue is still pertinent, please provide the info requested. Thanks!

Comment 11

[Paul]

Hi Grover,
I am still trying to get this issue solved.
You asked:
Are you able to do a MozRegression on this issue? With the info from that, we can pinpoint exactly what version of Firefox this issue began occurring?

In one of my previous posts I already answered it:

I started from version 49 (where it did not work) and getting back until finding a version that was working fine.
In version 40.0a1 (2015-03-30) the drag&drop into a gmail message did not work (this was without our program installed). The forbid cursor was shown. The same happened in hotmail.com for example. So here it seems that you detected a bug that was finally fixed in 41.0a1.
In version 39.0a1 the same issue happend (forbid cursor was shown while trying to do a drag&drop of a file into a gmail message).
In version 38.0a1 the bug was the initial but I reported (the file drag&drop was "allowed" but nothing was finally dropped when using my program). 
In 37.0.a1 there was no problem, everything was working OK. So it seems the issue started at version 38.0.a1.

I coded a little .exe and .dll that will help you to reproduce the issue and added it as an attachment to this post:

This .zip file contains two 32 bits files inside. A .exe that injects the .dll in the Firefox.exe process. So just run the .exe and you will see it in memory (task manager). Then each time you start Firefox.exe, the .dll will be injected in Firefox.exe. Every time you drop a file inside a Gmail new message a message box will appear. This message box is display just in the IDropTarget->Drop() COM method. The fact that this message box is displayed, prevents (in most cases) the drop from getting successfully processed (that is, no file is attached). I was always able to reproduce it in Windows 10, but not in Windows 8.1.

I tested and the newer version 51.0.1 still have the problem.

Several persons were able to reproduce it (see the posts)

Thanks