245861 - Firefox never delete temp files produced by drag and drop

Status: VERIFIED FIXED

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

Description

[Norbert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.6) Gecko/20040210 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.6) Gecko/20040210 Firefox/0.8

- delete all files within the temp-dir (the system temp, not the firefox cache)

- open a site that contains at least one picture (a non-link picture)

- open a new tab and switch back to site whith the picture

- drag&drop this picture to the new tab

- close Firefox:

The picture-file still is in temp-dir. It seems that Firefox never deletes it's
temp-files.
Some programms delete their temp-files when closing them.
Or other programs I know (WinRAR) delete old temp-files when starting a new session.

Please make sure Firefox deletes it's temp-files to avoid overflow of the system
temp-dir.
Some unexperienced users don't know that they have to delete their temp-dir
sometimes!

Reproducible: 
Steps to Reproduce:

Comment 1

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041017 Firefox/1.0

confirming->New

or preferably use the Firefox cache dir to place it in

Comment 2

[Jo Hermans]

see discussion in bug 252479

Comment 3

[Lee_Dailey]

howdy y'all,

this problem still exists in ff150. my ff info ...
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 - Build ID: 2005111116

take care,
lee

Comment 4

[softskiller]

Hello,
I have the same problem.
If you use drag and drop with porno thumbnails (laugh or not)
you have your whole temp folder full of porn.
You think you are safe when you clik "delete private files/data".
But the stuff in the tempfolder stays there until you delete it yourself.
Which is only possible, if you have no other applications that use the tempfolder,
or you select the small pics yourself.
Why is the tempfolder needed for drag and drop in the tabbar?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Same for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061205 BonEcho/2.0.0.1

This issue should be fixed ASAP. It's always laying around for a couple of time without attention. We shouldn't use the system temp folder for storing images which are moved between tabs via drag and drop.

Comment 6

[Boris Zbarsky [:bzbarsky]]

For what it's worth, if you really feel this should be fixed you should put it in the right product/component (I can guarantee that General is not it), cc someone who knows the code, and request blocking for some upcoming release...

Comment 7

[Martijn Wargers (dead)]

I can see this with the latest Firefox2 build, but I'm not seeing this with trunk builds.
This seems to have been fixed between 2006-02-19 and 2006-02-25:
I guess this has been fixed by https://bugzilla.mozilla.org/attachment.cgi?id=210987&action=view from bug 267426.
It seems like bug 203307 contains a patch for the 1.8.1 branch that could potentially fix this? (Yuri?)

Comment 8

[Yuri Kovalchuk]

(In reply to comment #7)
> It seems like bug 203307 contains a patch for the 1.8.1 branch that could
> potentially fix this? (Yuri?)
> 
This patch does not create any temp files during drag and drop at all. So it fixes the issue.
Tried to get it into 1.8 branch but to no avail

Comment 9

[Martijn Wargers (dead)]

Well, there is now a privacy issue to worry about, so maybe it should be reconsidered.
So I'm requestiong blocking1.8.1.1 to see what drivers think of this.

Comment 10

[Daniel Veditz [:dveditz]]

1.8.1.1 is done, moving Martijn's request to current release

Comment 11

[Jay Patel [:jay]]

We need to get the patch in from 203307.  Drivers will take a look and block that bug as well.

Comment 12

[Jay Patel [:jay]]

Actually, the patch in bug 203307 looks a bit risky for the 1.8 branch, so we need an alternative patch to just fix this issue with temp files.  Any takers?

Comment 13

[Jay Patel [:jay]]

Not blocking on this bug, but if we can get a safe patch for the branches, please renominate for a future release.

Also marking this FIXED since it was fixed on the Trunk in bug 203307.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

v.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070105 Minefield/3.0a2pre ID:2007010507 [cairo]