New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 5 users

Issue metadata

Status: Verified
Last visit > 30 days ago
Closed: Jul 2010
EstimatedDays: ----
NextAction: ----
OS: All , Mac
Pri: 2
Type: Bug

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Option-clicking a link should bypass "Save As" dialog

Reported by, Feb 25 2010 Back to list

Issue description

Chrome Version: 5.0.335.0 dev
OS version: OS X 10.6.2

Behavior in Safari 3.x/4.x (if applicable):
Option-clicking a link downloads the resource without opening up a save-as dialog

Behavior in Firefox 3.x (if applicable):
Firefox also downloads an option-clicked link without a save-as dialog.

What steps will reproduce the problem?
1. Click on a link with the option key activated.

What is the expected result?
On other OS X browsers, pressing option when clicking a link forces download of the resource 
with no confirmation, enabling the user to quickly download lists of resources.

What happens instead?
On Google Chrome, option-clicking a link brings up a "Save as" dialog, which is extremely slow, 
and also duplicates the function of the "Save Link As..." contextual menu item.


Comment 1 by, Feb 25 2010

Google Chrome doesn't have a default download folder until you set one, so I'm not sure 
how you would expect this to work. :P

Once you set one, it skips the Save As dialog all the time, no need for an Option 

Comment 2 by, Feb 25 2010


Chrome downloads a resource if it, or a plugin, has not registered itself as a handler for that MIME type.

If Chrome does know how to open a resource, like the attached picture, it does not download the resource, but 
in fact opens it. If you want to download the picture then, on OS X you typically either:

a) Right click, and choose "Save Link As..."
b) option-click the picture
this is mah job.jpeg
34.7 KB View Download
Status: Untriaged
5.0.338.0 (Official Build 40104) dev

Mac Safari works as mentioned in the bug.
Status: Assigned
Is this cross plat? thanks

Comment 5 by, Feb 26 2010

Alt-click on Firefox also bypasses the save dialog on Windows 7. I don't know about Safari on windows, but I 
would assume so.

Comment 6 by, Feb 26 2010

Labels: -Area-Undefined Area-UI OS-All
Repeatable on 
Google Chrome	5.0.365.0 (Official Build 43016) unknown
WebKit	533.3
V8	2.2.0

Comment 8 by, May 18 2010

Retested on TOT
Chrome version: 6.0.401.1 r47052  <<<Release>>>


Comment 9 by, May 18 2010

Status: Untriaged
 Issue 44422  has been merged into this issue.
Status: WontFix

Comment 12 by, May 18 2010

>No comment was entered for this change.)
>Status: WontFix

That's disappointing. This along with having no means to close the download bar with the keyboard makes 
downloading a very clunky experience on Chrome.

Comment 13 by, Jun 7 2010

Status: Untriaged
I suspect closing this might have been a misclick.  Perhaps a Mac expert has an 
opinion on UI consistency (see comment #2).  Especially if this bypasses the download 
dialog on browsers that normally prompt, it seems reasonable to me to match that.
Labels: Mstone-6 HelpWanted
Status: Available
was a mis-click
Status: Started
Status: Fixed
Status: Started
(Whoops, patch is lgtmed but hasn't landed yet, reseting status till patch does land)
The following revision refers to this bug: 

r52848 | | 2010-07-18 03:45:28 -0700 (Sun, 18 Jul 2010) | 18 lines
Changed paths:

Option-click to download should not display "Save As" UI.

The download manager has a concept of a request originating from the "Save As..." contextual menu v.s. a direct download request from the renderer, however this was't hooked up.

The Download Manager uses boolean variables named "save_as" in various locations to track whether a download originated via a contextual menu selection (in which case the save panel should be displayed) or via a renderer request (in which case no UI should be displayed).

This CL contains 3 distinct changes:

1. DownloadFileManager::OnDownloadURL() is where downloads originating from the contextual menu are dispatched, set save_as to true if the download starts here.

2. ResourceMessageFilter::OnDownloadURL() is where downloads originating from the renderer are dispatched (e.g. option-click), don't display UI for these.

3. The "save_as" variable in the DownloadCreateInfo structure doesn't really reflect the origin of the request but whether the Save panel should be displayed. This can happen for example on a name collision or if the default download location isn't writeable regardless of the action that initiated the download.  Renamed the variable and added documentation to this effect.

BUG= 36775 
TEST=Option-click an image, the image should be saved without prompting the user for a download locate.  Save an image via the "Save As..." context menu, you should be prompted for the save location.

Review URL:

Status: Fixed

Comment 22 by, Jul 18 2010

Huzzah. Thanks for patching this in jeremy.
Status: Verified
Chrome version: 6.0.471.0 r52878

Comment 24 Deleted

I hope Google fixes this problem:
Project Member

Comment 26 by, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 27 by, Mar 10 2013

Labels: -Area-UI -Mstone-6 M-6 Cr-UI
Project Member

Comment 28 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment