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

RESOLVED INACTIVE

Status

()

--
enhancement
RESOLVED INACTIVE
17 years ago
13 days ago

People

(Reporter: Suran, Unassigned)

Tracking

({parity-chrome, parity-ie})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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).

Comment 2

17 years ago
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.
(Reporter)

Comment 3

17 years ago
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.

Comment 4

16 years ago
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

Comment 5

15 years ago
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

Comment 7

7 years ago
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.
Comment hidden (advocacy)
* 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: → bug 752440, bug 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]

Comment 10

3 years ago
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.

Updated

3 years ago
Component: File Handling → File Handling
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]

Comment 12

16 days ago
> 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

Comment 14

13 days ago

(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)

Comment 16

13 days ago

(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.

Comment 17

13 days ago

(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
Last Resolved: 13 days ago
Flags: needinfo?(paolo.mozmail)
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.