Closed Bug 245861 Opened 16 years ago Closed 13 years ago
Firefox never delete temp files produced by drag and drop
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:
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
see discussion in bug 252479
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
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?
Same for Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20061205 BonEcho/22.214.171.124 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.
Assignee: bross2 → nobody
Summary: Firefox seems to never delete temp-files produced by drag_and_drop → Firefox never delete temp files produced by drag and drop
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...
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?)
Component: General → Drag and Drop
Product: Firefox → Core
QA Contact: general
Version: unspecified → 1.8 Branch
(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
Well, there is now a privacy issue to worry about, so maybe it should be reconsidered. So I'm requestiong blocking126.96.36.199 to see what drivers think of this.
Depends on: 203307
188.8.131.52 is done, moving Martijn's request to current release
Flags: blocking184.108.40.206? → blocking220.127.116.11?
Whiteboard: patch in 203307?
We need to get the patch in from 203307. Drivers will take a look and block that bug as well.
Flags: blocking18.104.22.168? → blocking22.214.171.124+
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?
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.
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: blocking126.96.36.199+ → blocking188.8.131.52-
Resolution: --- → FIXED
v. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070105 Minefield/3.0a2pre ID:2007010507 [cairo]
Status: RESOLVED → VERIFIED
Version: 1.8 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.