The default bug view has changed. See this FAQ.

Firefox never delete temp files produced by drag and drop

VERIFIED FIXED

Status

()

Core
Drag and Drop
VERIFIED FIXED
13 years ago
8 years ago

People

(Reporter: Norbert, Unassigned)

Tracking

({privacy})

Trunk
x86
Windows 2000
privacy
Points:
---
Bug Flags:
blocking1.8.1.2 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: patch in 203307?)

(Reporter)

Description

13 years ago
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

Comment 2

12 years ago
see discussion in bug 252479

Comment 3

11 years ago
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

11 years ago
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: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.
Assignee: bross2 → nobody
Keywords: privacy
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

Comment 8

11 years ago
(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 blocking1.8.1.1 to see what drivers think of this.
Depends on: 203307
Flags: blocking1.8.1.1?
1.8.1.1 is done, moving Martijn's request to current release
Flags: blocking1.8.1.1? → blocking1.8.1.2?
Whiteboard: patch in 203307?

Comment 11

10 years ago
We need to get the patch in from 203307.  Drivers will take a look and block that bug as well.
Flags: blocking1.8.1.2? → blocking1.8.1.2+

Comment 12

10 years ago
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

10 years ago
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
Last Resolved: 10 years ago
Flags: blocking1.8.1.2+ → blocking1.8.1.2-
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.