New issue
Advanced search Search tips

Issue 499063 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocking:
issue 333943



Sign in to add a comment

Download pdf files by default from FTP sites instead of opening them in the browser's pdf viewer

Project Member Reported by roma@chromium.org, Jun 10 2015

Issue description

Reported by vint@ over email:
I was at an FTP site (no kidding  - Army Research Lab).
As I was downloading files, one by one, the .doc files simply landed in DOWNLOADS folder (on a mac running MAC OS X). But the .pdf files were opened and displayed rather than simply downloaded. Considering this was an FTP site, I would have thought Chrome would not open the file automatically. Obviously I must be missing something.

Ensuing discussion

>> glen@ - Sounds like an oversight on our part - seems like we should always download-by-default when using FTP.

>>darin@ - This is traditional browser behavior. Netscape w/ Acrobat reader plugin works the same way. We would treat .doc similarly if there were a MIME handler plugin (nacl module).That doesn't mean we couldn't change it...

>> roma@ - In the FTP case, since you often try to download/open multiple things in succession, it seems like a reasonable change to optimize for consistency and download them all by default.

If you ctrl+click to open a pdf in a new tab though, I would still expect it to open within the browser.
 
Labels: Cr-UI-Browser-Downloads
Roma: So what do we want to do here? If I open a .txt or .html file, which the browser can display inline, they do that don't download. e.g. ftp://ftp.de.netbsd.org/knoppix/CHANGELOG-ADRIANE-KNOPPIX-7.2.0f.txt and ftp://ftp.de.netbsd.org/debian/README.html
Labels: Needs-Feedback
Components: Internals>Network>FTP
Labels: -Type-Bug Type-Feature
This sounds like an FTP/Downloads policy decision, which would be Asanka for Downloads, and ? for FTP.

Having said that, I'm inclined to think we shouldn't change the behavior; this doesn't sound so much like ftp vs. http as doing repeated downloads versus single-visit a file.  If I click on a single file (ftp or web page) I generally want the browser to do the best it can with it, and download as a secondary option.  But if my usage pattern is repeated downloads I don't want to open those files that the browser happens to know how to open.

I wonder if this could be handled by changing the UI surface on the FTP view (and maybe the HTTP directory view as well) to include a single click option to signal downloading?

(Note for future triagers: I'm treating this bug as if it doesn't have the Needs-Feedback label on it, because as far as I'm concerned, it has all the information needed for diagnosing the problem.  Shifting over to feature request, though.)
I think only a very small portion of the user base has any expectation that downloads over FTP would behave differently than downloads of HTTP. That audience likely consists of users who used FTP before the Web came to prominence in the 1990s.

Relatively few users download PDFs via FTP at all. We know this because we regressed this scenario and broke it entirely in M54 stable ( Issue 656956 ).

I'd propose "Won't Fix" for this.

Comment 6 by eroman@chromium.org, Nov 18 2016

Agreed for WontFix.

Comments #2 and #5 summarize pretty well why I don't think change the policy makes sense or is consistent.

Comment 7 by eroman@chromium.org, Nov 18 2016

Note that we generate the HTML for the ftp listings pages in Chrome.

So another option could be to add a download icon beside files (pdf or otherwise), which forces a download when you click it.

So now you could click the download icon if you wanted to always force download. But the existing hyperlink (the filename) would continue behaving as it does today.

And navigating directly to an ftp:// URL would also continue working as it does today (and display the content in the browser).
Status: WontFix (was: Untriaged)
Agreed with #5 and #6. Let's open up a separate issue for #7 if we want to do that.
Blocking: 333943

Sign in to add a comment