Closed Bug 149526 Opened 23 years ago Closed 6 years ago

save-as-and-open In the "open"-"save as"-"cancel" download dialog

Categories

(Firefox :: File Handling, enhancement)

Product:
Firefox
Component:
File Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INACTIVE

People

(Reporter: Suran, Unassigned)

References

Details

(Keywords: parity-chrome, parity-ie)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 BuildID: In the open-save as-cancel dialog when clicking on a non-html link there should be an opion "save as and open" to have a permanent local copy and open that copy w/o having to leave the browser and look for that file. Reproducible: Always Steps to Reproduce: 1.click on a non-html-link 2. 3.
If you just save, you can use the "launch" functionality from either download manager or the download dialog to launch a helper on the file... (except on Unix).
Boris: This RFE should be really enhancement for users, which do this action many times. But it will be UI complication for common user IMHO.
Sorry, I am using mozilla just on *ix so I never noticed that is is available on Windows. Anyway, the window for download closes after the download anyway and you will not click to make it stay unless you know that a button for luncch will apear afterwards. Mr Hauner: if it is good for some and confises many then make it optional.
Part of this bug (launching from Download Manager) has just recently landed. It's on the trunk, and will be in 1.4, I believe. We do not allow users to simply click a single button and download and open a file. That's what gets IE users into a plenty of trouble. They must take at least two steps in mozilla to launch .exe files, and that's by design. Please mark as WONTFIX
Recommending wontfix if we can get a UI czar to evaluate this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is in the wrong component...
Assignee: samir_bugzilla → file-handling
Component: XP Apps → File Handling
QA Contact: pawyskoczka → ian
Assignee: file-handling → nobody
QA Contact: ian → file-handling
A pet peeve in Thunderbird is the routine double-processing of file attachments that I go through whenever a colleague sends me a file via e-mail. I want to save the file alongside related files on my file server and I also want to open the file immediately. There are two different options, but they both boil down to frustrating additional clicking: 1. Click the attachment; elect to save a permanent copy in a location I store related documents. 2. Click the attachment again; elect to open in Word, Excel, or whatever. Note that in this model, I need to be careful not to just use Word's "File > Save" function because I'll be saving my changes to a temporary file. -or- 1. Click the attachment; elect to open immediately in Word, Excel, or whatever. 2. Use Word, Excel, or whatever's "File > Save As" dialog to save a permanent copy in the location where I store related documents. Notwithstanding the root user interface failure of file system context mismatch inherent in all "File > Save As" dialogs (which is not Mozilla's responsibility at all), Thunderbird can nevertheless alleviate user pain by offering a "Save and Open Immediately" option for handling file attachments as suggested by this enhancement. Workarounds cited in earlier comments are specific to Firefox, which shows a Download Manager window, but are not applicable for Thunderbird file attachments. I don't think this enhancement is super easy, however. Despite being easily described as just adding "Save and Open," there is some complexity: the dialog in question has a dependent UI control associated with the current "Open" option. Namely, the helper-application menu. Changing the dialog to feature a three-state radio-button choice between Open, Save & Open Immediately, and plain Save would beg the question: do you repeat the helper-application menu? Probably not. But regardless of how it may be solved in the UI, I would greatly appreciate the ability to streamline the save-and-open use-case that I deal with every day.
* IE has "Save and run" in the dropdown of the split "Save" button. * Chrome has "Open when done" in their download manager (which is similar but different enough that I left bug 752440 open for it)
See Also: → 752440, 587485
Summary: save-as-and-open In the "open"-"save as"-"cancel" dialog → save-as-and-open In the "open"-"save as"-"cancel" download dialog
Whiteboard: [parity-ie][parity-chrome]
I'd argue that "open when done" is more generally applicable because you can change your mind and enable it part-way through a long download, while "save and run" requires you to make that decision upfront.
Product: Core → Firefox
Version: Trunk → unspecified
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome, parity-ie
Whiteboard: [parity-ie][parity-chrome]
> We do not allow users to simply click a single button and download and open a > file. That's what gets IE users into a plenty of trouble. They must take at > least two steps in mozilla to launch .exe files, and that's by design. It's already possible to open a file with a single click, so saving that file to `~/Downloads` (or other hard drive location) instead of `/tmp` isn't going to impact security. Or am I missing something?

(In reply to Matthew Davis from comment #12)

We do not allow users to simply click a single button and download and open a
file. That's what gets IE users into a plenty of trouble. They must take at
least two steps in mozilla to launch .exe files, and that's by design.

It's already possible to open a file with a single click, so saving that
file to ~/Downloads (or other hard drive location) instead of /tmp isn't
going to impact security.

Or am I missing something?

You're missing the fact that we disable the "Open" option for executable file types, such as .exe on Windows: https://cl.ly/4f40979560a5 and https://searchfox.org/mozilla-central/rev/5053031ba7621fa8f63f42de4c204ab3561e4e59/toolkit/mozapps/downloads/nsHelperAppDlg.js#662-663,667

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #13)

You're missing the fact that we disable the "Open" option for executable file types, such as .exe on Windows: https://cl.ly/4f40979560a5 and https://searchfox.org/mozilla-central/rev/5053031ba7621fa8f63f42de4c204ab3561e4e59/toolkit/mozapps/downloads/nsHelperAppDlg.js#662-663,667

Ok, so can't we add a "save and open" button and disable it for executables?

I would be in favour of that but I'll defer to Paolo who knows more about recent UX thoughts on Downloads. The risk I see is adding clutter in the UI since we already supporting opening the files immediately after download from a temp. folder.

Flags: needinfo?(paolo.mozmail)

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #15)

The risk I see is adding clutter in the UI since we already supporting opening the files immediately after download from a temp. folder.

The original request specifically refers to saving a permanent local copy and not having to involve the file manager, which would rule out downloading to a temporary folder.

Given the specific request for a single save-as-and-open option, I get the impression that the two key features Marcus is looking for are:

  1. Save to a user-defined non-temporary folder, like the Save option and unlike the Open option.
  2. A convenient way to pre-emptively request that the downloaded file be opened, like the Open option and unlike the Save option.

...in which case, this could be solved by replicating Chrome's support for clicking on an in-progress download's button in the download bar to toggle whether it will be automatically opened once it completes.

I'm not on Developer Edition at the moment, but I know Firefox didn't support that last I checked and I don't remember seeing any indication that Firefox has added it recently.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #15)

I would be in favour of that but I'll defer to Paolo who knows more about recent UX thoughts on Downloads.

I think there's some similarity between some of the thoughts on this bug and the latest UX thinking. You can see a larger plan in the dependency tree of bug 1270405. Most of these plans are immediately blocked by bug 1306334 and its dependencies, but we do eventually plan to remove the interstitial dialog entirely for executables and other file types in bug 1306341.

Unfortunately we don't have a team assigned to work on any of these bugs, so the user experience of downloads is basically frozen until we can get some momentum on the bugs I mentioned above.

Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(paolo.mozmail)
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.