244961 - add a pref to change the behaviour of Save Link As to not ask for the download location

Status: NEW

(Toolkit :: Downloads API, enhancement)

Description

[Samir L. Boulema]

The behaviour for the context menu-item "Save Link As..." changed from not
asking and just saving to the default download folder, it changed to asking for
every file where you want to save it.

I know that the "..." specifies that there is an extra dialog that will be
presented to the user, but i liked the old behaviour, and i hope that its
possible to have a pref added to switch between the two different behaviours.

Comment 1

[Ali Ebrahim]

What was the time window in which this changed, and on branch or trunk?

Comment 2

[Samir L. Boulema]

It had the old behaviour on the trunk (2004-04-08)
I saw the new behaviour on the trunk (2004-05-21)

Its changed for the trunk and the branch, this is the bug that changed the
behaviour: bug 232702

So i guess (2004-05-21) was the first build with the new behaviour.
I know how to change it back to the old behaviour by changing the browser.js
file in the browser.jar file.
This is the diff:
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/browser/base/content&command=DIFF_FRAMESET&root=/cvsroot&file=browser.js&rev1=1.296.2.3.2.2&rev2=1.296.2.3.2.3

But a pref would be easier...

Comment 3

[Ben Fowler]

This comment may be too late in the sense that there is no longer
time for discussion, but there are two behaviours required here:

1) 'Download Link'; either from a context menu, by Option-clicking
or dragging to the Desktop/a folder
2) 'Save As...'; from a contect menu.

The second should ask - the As in Save As implies thay you might want 
to inspect/alter the target name (and logically also its directory) -
but the first should never ask, just download to the specified directory
(mangling names on clashes). Click and forget, click and you are done.

If we are only allowed one, then as a user I prefer (1), but as a 
developer I might prefer (2) in that it is safer. Is there also a dog food
issue. Do developers use Firefo]x to download, if so, how does each
like it to be configured.

It is possible that (1) should also honour the Save to Disk/Open With settings
but (2) should not. As a user I prefer to always Save to Disk, but as
a developer Open With seems more logical.

This is one those many areas in HCI where the Principle of Least Surprise
trumps more high falutin', and perhaps fuller, analysis.

If memory serves, iCab gets this right. I also think that Quicktime
movies, Flash and other content should be draggable/downloadable, but
I seem to be in a minority of one in that I don't know of a browser
that does it.
 

Comment 4

[Stian Jordet]

I really, really miss the old behaviour. What's the point of the option "Save
all files to this folder" in the Download settings, if it asks where to put it
anyway? Shouldn't it be removed?

Comment 5

[Ivan Ičin]

I agree with Stian. This new behaviour is not logical, and it is hard to find
any argument for it. Much better is to say we were wrong, we will fix this when
we have time.

Comment 6

[Stian Jordet]

I just read at http://www.mozillazine.org/talkback.html?article=4824#182 that I
can press alt while clicking on a link to get the old behaviour. That's just
perfect :) But wouldn't it be better keep the old default, and use the alt key
for the new behaviour?

Comment 7

[Samir L. Boulema]

Until the option is there, you can use this extension:
http://www.extensionsmirror.nl/index.php?showtopic=356

Comment 8

[Steffen Wilberg]

tweaking summary.

Comment 9

[Jesse Ruderman]

The workaround (alt+leftclick) is very hard to do with only one hand.

Comment 10

[Jesse Ruderman]

*** Bug 249046 has been marked as a duplicate of this bug. ***

Comment 11

[Jesse Ruderman]

Possibilities:

1. Only have "Save Link As...".  (What we have now.  Makes the "Save all files
to this folder" option much less useful and more confusing than it should be.)

2. If you have "Save all files to this folder" checked, replace "Save Link
As..." with "Save Link to Desktop".  (What we had before, but with better
labels.  "Desktop" would be replaced with the name of your download directory.)

3. If you have "Save all files to this folder" checked, add "Save link to
Desktop" to the context menu, next to "Save link as...".

I prefer #2.  We should do the same thing for "Save link as" (this bug) and
"Save image as" (bug 229547).

Comment 12

[Jesse Ruderman]

Btw, I think adding a context menu item ("Save Link to Desktop") would be better
than adding a pref ("Save all files to this folder... including files downloaded
by right-clicking a link and selecting Save").

Comment 13

[Francois Ingelrest]

Having two entries was just fine, I often want to save files to the default
download directory, but sometimes I want another one. Having keyboard shortcuts
(such as ALT+click) is a good thing, but they should only be *shortcuts* to
functionnalities accessible by other means (such as the contextual menu). I
don't see why there should be only one entry for saving files in the contextual
menu...

Comment 14

[Jesse Ruderman]

*** Bug 255083 has been marked as a duplicate of this bug. ***

Comment 15

[Jeoffrey Stiernon]

(In reply to comment #14)
> *** Bug 255083 has been marked as a duplicate of this bug. ***

I think both of them are usefull. they should appear in the context R_click_Menu

An automatically handled "Save link to disk"
--------------------------------------------
Perfect when "pecking" data. 

The behaviour of the 0.8.0 "save link to disk" was very good :

No prompt
suffix to avoid conflict with already existing filename
option to choose a default dir 

A manualy handled "Save link as ..."
----------------- 
Seems to me obvious

 I guess we can say just "Save" and "Save As" because it's a R_Click context menu 
Very easy, both option are already well kown...    

Comment 16

[Jesse Ruderman]

*** Bug 255632 has been marked as a duplicate of this bug. ***

Comment 17

[Nickolay_Ponomarev]

*** Bug 259592 has been marked as a duplicate of this bug. ***