Open
Bug 220180
Opened 22 years ago
Updated 3 years ago
dragging image to tab creates temporary file
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)
Tracking
()
NEW
People
(Reporter: ajlabbe, Unassigned)
References
Details
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•22 years ago
|
||
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 ?
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?
It looks like this could have something to do with 97413 and 203847...
Comment 5•21 years ago
|
||
*** Bug 229475 has been marked as a duplicate of this bug. ***
Comment 6•21 years ago
|
||
(links to the bugs mentioned above: bug 97413 and bug 203847)
this does not happen when dragging between windows
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 7•21 years ago
|
||
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•20 years ago
|
||
*** Bug 292901 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Assignee: bross2 → nobody
QA Contact: pmac
Comment 9•18 years ago
|
||
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?
Updated•16 years ago
|
QA Contact: drag-drop
Comment 10•4 years ago
|
||
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.
Severity: normal → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•