Where exactly do you drop the image? You say that it used to work with earlier versions; which version did work?

Do you get any output if you set the environment variable GIMP_LOG to "dnd" before starting GIMP?

(In reply to comment #1)
> Where exactly do you drop the image? You say that it used to work with earlier
> versions; which version did work?
> 
> Do you get any output if you set the environment variable GIMP_LOG to "dnd"
> before starting GIMP?
> 

I used to drop onto toolbox tool icons in 2.4. 

I can set an environment variable but what is "dnd" ? 

Dropping onto the toolbox should work. Have you tried to do this from the file manager (explorer)?

"dnd" is the value you should set the environment variable to. It tells GIMP to create extra debugging output for Drag-N-Drop (DND) actions.

FWIW: running Gimp 2.6.3 on Windows XP SP3 - drag-n-drop of an image from Firefox 3.0.4 does NOT work, but does from IE7. Fortunately, using Firefox addon IEView to switch to use the IE rendering engine DOES allow images to be dragged to GIMP (either creating a new layer if dragged onto an open image or a new image if dragged onto toolbox).

IIRC: I'd seen somewhere (wrt to an earlier 2.4 or 2.6 version) that dnd from IE7 worked but did not work from Firefox. I tried to find a bugzilla report about this w/o success so I guess it had never been filed before?

When attempting to drag from Firefox it shows the slashed-circle icon.

re: Gimp-log ...
I opened a command window and executed:
>set GIMP_LOG=dnd
>"D:\Program Files\GIMP-2.6\bin\gimp-2.6.exe"

and then dragged from the IEView tab in Firefox to the empty window display which worked but I can't find any file that GIMP is logging to. It doesn't appear in the command window.

Starting "gimp --help" shows an option -c for console window and I thought that might be where the gimp-log output would go to - apparently not!
All I get in that window is two lines (apparently irrelevant):
====
Skipping duplicate plug-in: 'D:\Program Files\GIMP-2.6\lib\gimp\2.0\plug-ins\gap
_plugins.exe'
Skipping duplicate plug-in: 'D:\Program Files\GIMP-2.6\lib\gimp\2.0\plug-ins\gap
_video_extract.exe'
=====
DND from IE-View tab in Firefox continues to work but fails from normal Firefox tab.

We need the debug output. Can anyone please tell this fellow how to get the debug output on Windows?

Inter-process drag-and-drop in general is not implemented in GTK+ on Windows. Only the totally different (API wise) drag and drop of files from Explorer (and apparently Internet Explorer) is implemented. This dnd uses so-called WM_DROPFILES message. 

The initial bug description failed to point out that when attempting to drag-and-drop an image from Firefox onto GIMP, the cursor is the "no drop allowed" one (with a "prohibited" symbol) while over GIMP's drop area, which is a clear indication that the receiving application is not willing to accept the kind of drop the source application is offering. Just saying that it "doesn't work" made it sound like it would *appear* to work but nothing happens, which is not the case. There is clear visual feedback that the drop is not accepted.

GTK+ applications can receive files dragged from Explorer. Internet Explorer and Explorer are closely related, so images dragged from Internet Explorer also work the same way (they turn up in the drop target as local filenames pointing to a temporary copy of the image).

The log output referred to above is not triggered by a GIMP_LOG environment variable, as far as I know, but GDK_DEBUG. Using the -c command-line option as above is correct, that way the logging is displayed. One can also redirect gimp's output to a file for a more permanent record of it, with the command line:

gimp-2.6 >gimp.log 2>&1

(Yes, that *is* correct cmd.exe syntax. It also is the syntax used in Unix shells, interestingly enough... Wonder who got the idea from who? (Just joking.))

Setting GDK_DEBUG to dnd and dropping an image from IE onto GIMP indeed shows that WM_DROPFILES is used:

gdk_window_register_dnd: 004A06C2
gdk_window_register_dnd: 00AC0CD8
gdk_window_register_dnd: 03CF150E
WM_DROPFILES: 004A06C2
... C:\Documents and Settings\tml\Local Settings\Temporary Internet Files\Content.IE5\DNHF7AF0\frontsplash[1].jpg: file:///C:/Documents%20and%20Settings/tml/Local%20Settings/Temporary%20Internet%20Files/Content.IE5/DNHF7AF0/frontsplash%5B1%5D.jpg
gdk_selection_owner_get: 0000C01F (DROPFILES_DND) = 00000000
gdk_selection_convert: 01371592 0000C01F (DROPFILES_DND) 0000C059 (text/uri-list)
gdk_drop_reply
gdk_selection_property_get: 01371592
gdk_drop_finishgdk_drop_finishgdk_drag_context_finalize
gdk_property_delete: 01371592 0000C030 (GDK_SELECTION)
_gdk_selection_property_delete: 01371592

The problem described here is nothing new. It has been a known fact all the time that GTK+ on Windows does not implement the OLE-based inter-process drag-and-drop in general. There is some stub code that is ifdeffed out in gdk/win32 that gives some idea of what needs to be done, but it's just a start, and likely wrong and buggy.

I thought there would be some old bug open against GTK+ on Windows about implementing more generic drag-and-drop that this could be marked as a duplicate of, but I couldn't find such now. So just retargeting this bug against gtk+/win32 then.

@Tor - actually Barney said originally: 
Steps to reproduce:
1. Drag an image from Firefox onto the UI.
2. A denied icon shows that dropping onto Gimp is not possible.

Thanks for the detailed explanation though. I learned quite a bit :-)

> actually Barney said originally [...] "A denied icon shows"

Ah, sorry for that, I should read more carefully.

Apparently Mozilla changed their drag-and-drop handling on Windows from Firefox 2 to FF 3, causing this regression. But people complained and the old protocol will be back in Firefox 3.1. More details: https://bugzilla.mozilla.org/show_bug.cgi?id=440911

It would still be nice if GTK supported both protocols, so it's probably worth keeping this bug open.

Hmm, is the CF_HDROP mentioned in the bugzilla bug related to the WM_DROPFILES style drag&drop then?

On Vista32, Gimp 2.6.7, Firefox 3.5.5:

Tried dragging image to taskbar and it worked about once out of 20 tries,,,
Most of the time errors like this:

Opening 'C:\Users\stu\AppData\Local\Temp\qmwqybja.bmp' failed:

Could not open 'C:\Users\stu\AppData\Local\Temp\qmwqybja.bmp' for reading: No such file or directory


One time this error:

Opening 'C:\Users\stu\AppData\Local\Temp\mxiq1xqt.bmp' failed:

Not a regular file



7zip and jedit behave weirdly with firefox too, the first time I open a file it often doesn't work saying the file isn't there, and on a subsequent go it does work... this suggests to me that something might have changed in Vista to break firefox - with those programs as well as gimp, opening/dragging from the filemanager seems to work ok.

Dragging image from where, and why to the taskbar? What it that supposed to achieve? And what happened the "about once" time it worked?

I honestly don't immediately see what it is that you are trying to say, and how it is relevant to this bug. More details please. (And if your comment is about dragging *files* from Explorer onto a GTK+ application like GIMP, that is then not relevant in this bug, as this bug is about all *other* kinds of DND. For instance, the kind of things that should ideally be supported is dragging a piece of text from Word to GIMP, or dragging a path from Inkscape to GIMP.)

Doh, should have proofread.  I meant the GIMP Toolbox window, had taskbar on the brain :)

What I was really doing was

"Steps to reproduce:
1. Drag an image from Firefox onto the UI.
2. A denied icon shows that dropping onto Gimp is not possible.
3". 



Most of the times I dragged from firefox to gimp it didn't work and said
 No such file or directory
One time it said
 Not a regular file
And once it actually worked
- In retrying I get similar results (image opened on 3rd try).


I followed the 'steps to reproduce', and was also noting in parsing that I get odd intermittent behaviour opening/dragging files from FF in unrelated apps, so possibly something is wrong on the FF end.


The dragging from explorer was checking that dragging an image file worked, as from the outside it looked like thats what the FF drag was doing.



I went down the garden path a bit on this one, your right the other kind of dragging doesn't work (quickly tested dragging text from pidgeon to gedit)

Ah OK. Yes, I can reproduce this. Might be a problem in Firefox... What happens on the GIMP side (in GTK+) is that it gets the WM_DROPFILES message that indicates a file drop, as if one was dragging a file from Explorer. But then the file name that the DragQueryFile() function returns is a nonexistent file, as the error messages show.

To the best of my knowledge, Microsoft doesn't document how to implement being a drag source for the WM_DROPFILES type drag-and-drop, so Mozilla has presumably had to try to figure it out themselves, and failed in some manner. Or then this has changed in Vista and later, I am using WS2008R2 (the server variant of Windows 7).

Note that it is equally easy to just use Right-click:Copy Image in Firefox, and then Shift+Ctrl+V (File:Create:From Clipboard) in GIMP.

Anyway, as what Firefox tries to do here is act as the source for the WM_DROPFILES mechanism, this problem you describe does not belong in this bug, which is about the other, generic, drag-and-drop mechanism.

Hmm, except that when I re-read the initial report and earlier comments in this bug, it is quite confusing what this bug is about... The summary "GTK+ on Windows lacks generic inter-process DND support" is clear and factual, but many of the comments, like Stuart's, are about dragging images from Firefox, which attempts to use the non-generic WM_DROPFILES method, at least in its current versions. Sigh. I probably should close this bug as INCOMPLETE and open a new one for just the lack of generic OLE-based DND support, and hope that that bug then doesn't get confused by WM_DROPFILES -related comments.

BTW, in IE8 I can't any longer drag images, wtf? Or is this because of the "enhanced security" mode it uses on Windows Server?

Created attachment 147470 [details]
Screenshot of problem with error message

Here's the current behaviour from FF 355 to Gimp 267 - see above attachement. Windows XP SP3 Home Edition.

Yes, I know, as I said I can reproduce the problem. And the output from running with GDK_DEBUG=dnd gimp-2.6 --verbose is much more interesting anyway. (Yes, I can do it myself.)

Although good to hear that it happens also on XP. Anyway, the problem with Firefox is most likely in Firefox. I am changing the summary of this bug to match what actually has been discussed, and resolving this bug now, and opening a fresh one for the generic DND issue.

New bug is bug #601534.

BTW, see recent discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=440911#c40

As is explained there, Firefox intentionally deletes the temporary file to which it has copied the image being dragged after the drop has completed (i.e. after the receiving app has called DragFinish()). Firefox's intent is that the receiving app handles the file before finishing handling the drop. (Hmm, actually, debugging this it seems that even if I set a breakpoint at the DragFinish() call, the file doesn't exist even then any more, wtf?)

From a user point of view, how should this *ideally* work? After an image from Firefox has bee draggen and dropped on GIMP, what file should GIMP think the image is? A temporary file with a random name like C:\\Users\\Your Name Here\\AppData\\Local\\Temp\\5ayoom01.bmp ? If the user then edits the file and without checking just saves the file, he might have a hard time later finding the file. Or should GIMP consider images drag-and-dropped to be without file name, so that if/when they are saved, a location and file name would have to be decided by the user at that point?

Re-opening. From now on, let's in this bug discuss this drag-and-drop of images from Firefox onto GTK+ apps (GIMP in particular) case. (Yeah, that is contrary to what I tried earlier to do in this bug, but oh well...)

From a user point of view the ideal interaction would probably be:


Drag file from FF into program
Manipulate file in program
If the user goes to exit, they will be prompted to save
If they go to save they the 'save as' dialogue will appear

In both cases:
  The name should be from the remote file (e.g. 'robots.txt' if you dragged that file).
  The folder shown should be wherever the program would be normally expected to save a new file.

Hmm, we are not talking about dragging random files (like 'robots.txt') (from a web browser showing a ftp server, or a link ina web page, or something) in this bug, but specifically *images* on web pages. (And *if* this bug would be about dragging "files", then please note that what is actually dragged is the URL, not the "file".) 

At least Firefox, when acting as a drag source for images, in the CF_HDROP format (which Windows then apparently automatically translates into the WM_DROPFILES mechanism that GTK+ actually takes part itn) uses a random local temporary file name. There is no indication of what the name for the image file used on the web page is.

If GTK+ would implement generic DND (for which feature there is the new separate bug mentioned above), then one would hope that Firefox would also offer just the URI of the image being dragged, and that could then be inspected by the drop target to construct a tentative file name for the image file if it is saved.

Ah, k in that case I would still go with the above if you were dragging 'windmill.jpg'.  

I realise that getting the filename that was in the URI may not be possible IRL (the suggestion being idealised.
  If the only information present is the temporary filename, then it would be best to have no tentative name and just prompt the user for it in save-as dialogue.
The folder should probably be the default location the program would save things to, and not the temporary folder.

Not sure if Linux experience is relevant to what Windows users expect, but the behavior on Linux (where it drags a URL, not a temp file) seems sensible: remember the name of the image, but not have any local path associated with it, so if you save it prompts for a filename. That seems better than remembering the temp file path (which risks users hitting ^S then not being able to find the saved image).

Yup, accepting a URL drop would be preferrable, even if that then means that GIMP (or whatever app) would need to re-download the image that Firefox already has downloaded. The user experience would ten probably be as you describe on Linux. 

Drag-and-dropping URLs is certainly possible in Windows, too, in general. But until we have generic OLE-based DND support working in GTK+, accepting drops of actual local file names (of temporary files, in this case) is all we can do.

Created attachment 147707 [details] [review]
Test patch

This patch makes GTK+ open the file as soon as possible, and makes it clearly more reliable to receive images dragged from Firefox in GIMP. As GTK+ keeps the file open for a while, Firefox won't be able to delete it. GTK+ closes the file after a second. GTK+ opens the file just so that Firefox won't be able to close it; this opening is not related to what the GTK+-using app then does with the dropped temporary file name. In GIMP's case, the relevant file loading plug-in eventually opens it. 

But as I say in the comment in the patch, I don't think I will actually enable this code. It is such an awful hack, and there are privacy issues too.

*** Bug 595819 has been marked as a duplicate of this bug. ***

I can't reproduce this with gimp-2-6 running on GTK+ 2.20. Has anything changed there?

The "awful hack" in comment #28 is still not enabled, if that is what you mean. Maybe Firefox has changed their behaviour, maybe they now delete the temporary file containing the dragged image much later?

We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.