473763 - Choosing "Open with" when downloading a file clutters the desktop with temporary files.

Status: RESOLVED INVALID

(Core Graveyard :: File Handling, defect)

Description

[Till Korten]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; de; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5

If I have the action associated with the filetype PDF set to "open," when I
click on a link to any file (most prominent example: PDF files), Firefox will save the file to my desktop, and then open the file with my specified app.  When I quit, this file is still there, and cluttering up my desktop quickly.

The desktop is the worst possible folder to save temporary files.

I am aware that there have been several bugs filed for this problem and either been discarded as wontfix or are still open. However, while this bug may be a duplicate of an old bug I am filing this bug anew for two reasons:

1) In my opinion, the main argument for not fixing this was, that it was possible to change this folder using safari. Since Safari 3, this does not work any more, so there is no way to prevent Firefox from cluttering the desktop, except to install an old version of safari just to edit this preference, or manually hack the system preferences with a hex editor.

2) Bug 191385 comment 15

3) Bug 311292 has been open for over three years now. The reason for this being that apparently users can't agree on a solution that satisfies everyone.
However, in my opinion the problem is not satisfying everyone but resolving the issue, that Firefox clutters the Desktop as soon as possible.
Therefore I propose the following strategy: 
a) First and quickly resolve this bug by using NS_OS_TEMP_DIR  instead of the Desktop. This will make Firefox behave consistently across all platforms.
A patch for this was already posted by rahul abrol: Attachment 356833 [details] [diff] for bug 311292.
b) Resolve bug 311292 by adding a configure option in about:config that enables users to change the directory for files that are opened instead of downloaded.

Reproducible: Always

Steps to Reproduce:
1. Click on a link to a file that is set to "ask user" under Preferences -> Helper Applications. e.g. a PDF file.
2. In the following dialogue choose the first option: "Open with"
3. The file gets opened with the application you choose. Close this application
4. View your desktop -- voilà, a file you don't want there.

Actual Results:  
A file I chose to open instead of download was downloaded to the desktop.

Expected Results:  
A file I chose to open instead of download should go to a temporary folder instead of the desktop. ANY folder is better than the Desktop.

Comment 1

[Till Korten]

Another possible solution would be to use the download folder instead of the desktop. This would mimic Safaris behavior. A patch for this was posted in bug 311292 by Shawn Wilsher: Attachment 337082 [details] [diff].

However, I personally prefer to use NS_OS_TEMP_DIR for two reasons:
1) It actually _reduces_ the amount of code. This will make Firefox less error prone and enable an easy and quick implementation of the fix.
2) In my opinion being consistent across platforms is more important than mimicking Safari because if people want Safaris behavior, they will use Safari. From my experience most people that use Firefox on Mac are people that recently switched systems and not long-time Mac users who will use Safari anyways.

Comment 2

[Robert Strong (they/them - no direct email)]

Moving over to a component where the code that does this actually lives

Comment 3

[Nochum Sossonko [:Natch]]

Why is this not a dupe of bug 311292, the patch there addresses this issue, if the issue is more prominent now, the severity should be bumped on that bug with a comment explaining why it is more sever now.

Comment 4

[Rahul Abrol]

Attachment: unify platform code

puts "open with..." files in users' temp directory like on other platforms (but does not delete them on application quit).

shawn's patch (v2.0) mimics safari's behavior.  see also bug 311292 comment #104 for another reason to favor his patch.

i think one of these two patches is needed now (ideally for firefox 3.1), then bug 311292 can be patched at leisure.

Comment 5

[Nathaniel Virgo]

Please please please please apply the patch in attachment 357210 [details] [diff] [review], and not the other patch which mimics Safari's broken behaviour.  The arguments in bug 311292 comment
#104 apply to both patches -- both make it impossible to configure the temp dir -- but the problem is much worse if the non-configurable location for temporary files is chosen to be the downloads folder.  Cluttering the downloads folder is better than cluttering the desktop but would still be a serious problem, whereas cluttering NS_OS_TEMP_DIR is not a problem at all!

I read dozens of pdf files per day.  Clicking on each one brings up the "open file" dialogue.  If I want to keep the file, I click "save," which puts it in my downloads folder, as expected.  If I just want to read the file, I click "open."  On all other platforms this saves the file to an out-of-the-way location such as /tmp and opens the file in a pdf reader.  The patch in attachment 357210 [details] [diff] [review] would bring the behaviour on OS X into line with this.  However, the other patch would save the file into my download folder instead.  This is a terrible situation because if I want to go back to a file I had actually chosen to save, I will find it hidden among literally hundreds of other files which I never wanted to keep.

For this reason I think the patch in attachment 357210 [details] [diff] [review] is definitely the way to go.

Comment 7

[Nathaniel Virgo]

What is the appropriate way to appeal against a bug being closed?

Comment 8

[Matthias Versen [:Matti]]

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html (point 2.2)

Comment 9

[Till Korten]

Shawn, with all due respect are you deliberately trying to prevent this bug from being fixed?

You even wrote a patch that would fix this issue, so I don't get why you think this should be a duplicate of a wontfix.

I am strongly against marking this a duplicate for the following reason:

Bug 191385 and any other bug that could be a duplicate is several years old. Sinnce then the following things have changed:
1)The preference to define the system download folder moved from system prefefences to safari preferences.
2) The same preference was removed from Safari

Therefore it is ludicrous for firefox to use this preference to save temporary files!

From the discussion in 311292 it is clearly evident, that there won't be an agreement about how that issue should be fixed any time soon much less somebody writing a patch for it. Therefore I suggested this bug as a solution that can actually be applied soon and resolves the most prominent issue of the desktop cluttering.

In my institute I know 14 people who do not use firefox because of the cluttering desktop issue and 5 mor who use firefox but are annoyed by it so please don't tell me it is not important!

Comment 10

[Nochum Sossonko [:Natch]]

Please continue the discussion (including your appeal to reopen) in bug 191385. If circumstances have changes, that may well be a reason to reopen it, however making duplicates is not the way to go. This bug has not been marked WONTFIX, it has been marked DUPLICATE and been verified as a dupe, please petition the closer of the original bug.

Comment 11

[Shawn Wilsher :sdwilsh]

Actually, I was wrong to mark this bug as a duplicate - for 3.0 it is, but for 3.1 and later, it's INVALID.  Bug 454242 made it so the files end up in the same location as your download preference.  If that happens to be the desktop, they'll still end up there, but you can change it.

Comment 12

[Till Korten]

(In reply to comment #11)
> Actually, I was wrong to mark this bug as a duplicate - for 3.0 it is, but for
> 3.1 and later, it's INVALID.  Bug 454242 made it so the files end up in the
> same location as your download preference.  If that happens to be the desktop,
> they'll still end up there, but you can change it.


Are you saying that from Version 3.1 The files I open will end up in my Download folder?

If that is the case then I apologize for my earlier comment and want to say thank you, Shawn, for fixing this. (If I got bug 454242 correctly, you wrote the patch that fixes this.)

Comment 13

[Shawn Wilsher :sdwilsh]

(In reply to comment #12)
> Are you saying that from Version 3.1 The files I open will end up in my
> Download folder?
That is correct.

Comment 14

[andreas.fischlin]

This bug is not resolved, is quite valid and should actually be marked as a duplicate of bug
#311292

Comment 15

[Shawn Wilsher :sdwilsh]

(In reply to comment #14)
> This bug is not resolved, is quite valid and should actually be marked as a
> duplicate of bug
> #311292
No, that's incorrect.  You've posted this same comment in a few bugs, and I think you didn't actually read them.  Please see comment 11 (but replace Firefox 3.1 with Firefox 3.5).

Comment 16

[andreas.fischlin]

Yes I posted this in several bugs, because I concluded from reading these bugs that this was the appropriate thing to do.

Comment 11 is not very clear. You state that you erroneously mark this bug as a duplicate. A duplicate of what? I guess you mean a duplicate of bug 454242. I do not argue about this. What I argue about is the following: I suggest to close this bug after having marked it as a duplicate of  bug 311292. Reason being that the actual problem described in this bug 473763 is actually still not resolved as of this writing in the latest TB I work with daily. Since FF and TB share code, this matters IMHO and your reference to FF 3.1 and 3.5 are not relevant in the context in which I suggest to put the issue of this bug 473763. Moreover, I checked FF 3.5 and AFAI can see it is still missing a preference to control where temporary downloads should go, the very same problem described here. BTW, several comments here, e.g. comment 3, comment 4, comment 5, appear to be quite in line with what I say here.

To sum up I repeat:  This bug is not resolved, its issue is valid and should actually be marked as a
duplicate of bug #311292.

Comment 17

[Shawn Wilsher :sdwilsh]

Comment on attachment 357210 [details] [diff] [review]
unify platform code

clearing review request from a closed invalid bug