161102 - Downloading dialog shouldn't use same directory for saving files and choosing apps

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Jonathan Wakely]

When downloading a file and prompted to open it using an application or save it
to disk, the same "last used" directory is shown, whether you're saving the file
or launching an app. I can't imagine many situations where this is useful - I've
never saved a downloaded file to the same directory as the binaries I might open
the file with.
For example, on windows (where I've observed this, not sure if it's the same at
home on linux) I might save the file in C:/MyDocuments or C:/temp, but launch
apps from C:/ProgramFiles/.../
On unix I might save in /tmp or ~/tmp and launch from /usr/bin/ - but
*certainly* wouldn't be saving anything to /usr/bin - or running apps from /tmp
(apologies if it doesn't act like this on unix.)
The current scenario means I have to traverse several directories to find the
app to launch, then next time I save a file i must traverse the dirs again to my
downloads folder, then back again next time I want to launch an app, and back
again etc etc.
The last used dir is great if you save several files to one place, or launch
several files in the same app, but mixing the two actions is incredibly annoying.
I'd prefer it if there was one "last used" directory for saving and a separate
one for launching apps.
I'm using 1.1b on win98

Comment 1

[alge]

using a cvs build from 20020805 on linux, it seems to use the 'last used' path
for saving files, and $HOME for running apps (last used for apps seems to be
lost at browser restart).
So, no, it does not act "like this" on unix. (= (change os!)

Comment 2

[Jonathan Wakely]

It's not broken on Linux, that's good news. It's still (IMO hideously) broken in
1.1 for Windows. Finding an executable to launch is a totally different action
from saving a file, and the last directory used for one action should not affect
the last directory used for the other.

Comment 3

[John Levon]

No dupe found, valid request. Variant of bug 27493 (and is mentioned there).

Comment 4

[Jonathan Wakely]

It most emphatically _does_ work like this on linux (redhat 72)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203

I've added an URL to this bug, pointing to a patch in the SourceForge patch
manager. Load that URL, you get a response with Content-type
application/octet-stream and Content-disposition attachment.
When mozilla prompts you to open or save, choose save, and save it somewhere
such as /tmp. Now _immediately_ load the URL again, and this time select "open
using an application" and hit the "choose" button to pick an app. The dialogue
that opens starts in the directory you saved in, /tmp in my case.

Sometimes, if you do something between saving and choosing the app, such as
loading a new page,  the dialog starts in $HOME, but not always. I haven't
worked out the exact behaviour yet.

The same thing appears to happen if you upload a file from /tmp using an <input
type="file"> and then download a binary, the choose app dialog starts in /tmp.
The sourceforge patch manager is a good place to test this, as you the
"download" link for attached files return application/octet-stream and there is
a file upload on the same page.

The "choose app" dialog never affects the other dialogs, but the save and upload
dialogs affect the "choose app" one.

I now longer have a windows box to test, but I believe this might be OS all. If
not, there are very similar bugs in windows and linux.

Comment 5

[Jonathan Wakely]

I have created a test-case for this bug and changed the URL field to refer to
it. Please see http://www.compsoc.man.ac.uk/~cow/mozilla/161102.html

Note: The previous value of the URL field was
https://sourceforge.net/tracker/download.php?group_id=32758&atid=406422&file_id=42918&aid=689621

Comment 6

[Mad Max]

I'm glad that with some delay everybody confirmed by bug report,
and all seem to agree that it should be fixed,
but there are no news here since over 2 years.

I recall the odd behaviour :

1) the "Open it with..." browser in the "Download binary file" dialog box starts
in the directory used for the last "Save as..." operation

I recall the suggested behaviour :
2) It should default to a system directory like "/usr/bin" resp: "c:Program
Files", which could be fetched from the PATH environmen veriable.

Further improvements suggested :
3) Provide for this dialog field a "Recent choices" list (programs and/or
directories), this list could be initialized to all the components listed in PATH.

4) the same for the (attachment)"Save as..." and "Attach file..." dialog boxes
(which are strangely not correlated concerning the default location, while the
"Save as..." dialog uses the same directory as the "Choose program to open..."
dialog.)

5) the (mail attachment)"Save as..." and (menu bar)"File -> Save page as..."
dialog could default to the same directory, currently it uses yet another
default. (For the latter also the (same) "recent locations" list would be useful.)

PS: I wanted to change OS to LINUX (my case) and Hardware to "All" but this was
now refused to me.

Comment 7

[Jonathan Wakely]

Wouldn't changing OS to All make more sense, since I originally reported it
against Windows98 and later confirmed it on Linux?

Comment 8

[Mad Max]

I agree completely: OS = "All"
(I myself confirm it for linux, but cannot say anything about WinXX.)

(and sorry, for some reason I took myself for the original author, and
"remembered"(???) quite well what I wrote ("recalls" above) - maybe I submitted
it as a duplicate, or noticed before posting it that it already existed...)