220180 - dragging image to tab creates temporary file

Status: NEW

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

Description

[A. Labbe]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916

When I drag an image to an empty space on the tab bar to create a new tab
containing that image, or even to an existing tab, a copy of the image is
created in Windows's temp folder (C:\Documents and Settings\<profile>\Local
Settings\Temp). If I drag an image that's a link, to open the linked page in a
tab, a copy of the image is also created. The tabs open fine, but these copies
of the image file are created. For example, if I drag the top logo from
mozilla.org to create a new tab with it, a file called header.gif is created in
the temp folder.

Reproducible: Always

Steps to Reproduce:
1. Drag an image or a link image to an open space in the tab bar
2. The tab is created OK, but a file of the image is left in the temp folder
mentioned above

Actual Results:  
A copy of the image file is created in C:\Documents and Settings\<profile>\Local
Settings\Temp

Expected Results:  
A copy shouldn't be created in the first place. It's OK to create a copy in the
mozilla profile's cache folder, but nowhere else.

Comment 1

[Matthias Versen [:Matti]]

This is because of the windows D&D code (AFAIK) and IT'S the right place to
store this temp file because you can also D&D to other non-Mozilla applications.

The cache folder is also the wrong place because it's a networking cache dir.

Now the questions: Is this temp file cleared if you close Mozilla ?

Comment 2

[Boris Zbarsky [:bzbarsky]]

.

Comment 3

[A. Labbe]

I'm not sure it's a Windows problem, because it didn't happen in Mozilla 1.4. I
first saw this when I moved to 1.5b, and it's still there in 1.5RC1.
And no, the files are not removed when Mozilla quits. But they shouldn't be
created in the first place, just as they weren't in previous versions. I haven't
checked, but shouldn't they already be in the cache directory?

Comment 4

[A. Labbe]

It looks like this could have something to do with 97413 and 203847...

Comment 5

[Jo Hermans]

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

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

(links to the bugs mentioned above: bug 97413 and bug 203847)

this does not happen when dragging between windows

Comment 7

[Richard Aspden]

Build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026
Firefox/1.0RC1

Surely this should just be going off the original URL when internal? It's still
occuring with my latest FF build I've installed. Of course, I don't know much
about the internals of cross-platform D&D, but it's just a thought.

It wouldn't be so bad, but the first time it's dragged, I get the "The image
“file:///C:/DOCUME~1/RICK/LOCALS~1/TEMP/gs18-3.gif” cannot be displayed, because
it contains errors." or equivalent, until I refresh. The temporary file is also
left in the temporary folder, and is not erased.

Does this need fixing / altering, or not? I have a feeling it's not as simple as
it looks...

Comment 8

[Matthias Versen [:Matti]]

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

Comment 9

[astromusic2007-bugzilla]

This is still a problem with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

If an image is dragged to another Windows program, then whose responsibility is it to delete the temporary file once it's finished with?  Is it Firefox's?  Or the other program's?  Does it depend on what type of DROPEFFECT (NONE/COPY/MOVE etc.) the other program returns from its COleDropTarget::OnDropEx() function?

Sometimes the temporary file seems to be empty, and only gets written to when the other program returns control to Firefox.  This might be bug 255686, and might explain the "contains errors" above.

Also, why does Firefox put 5 copies of the text/html information into the dropped object?

Comment 10

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.