Wait longer to get correct filename for "save link as"

RESOLVED FIXED in Firefox 9

Status

()

Firefox
File Handling
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: jduell, Assigned: jduell)

Tracking

unspecified
Firefox 9
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Created attachment 556190 [details] [diff] [review]
Wait for 4 seconds instead of 1 second for download filename.

I run into this everyday on Bugzilla, and I bet you do too.  I right-click an attachment and click "save link as", and about 1/3rd of the time I get "attachment.cgi" as the filename, instead of whatever the patch/filename actually is (from the content-disposition header).

A little poking (and help from biesi on IRC) reveals that we wait 1 second for the reply from the webserver (to get the content-dispostion filename), and if we haven't heard back, we use the URI basename as the filename:

  https://bugzilla.mozilla.org/show_bug.cgi?id=299372#c184

1 second is not long enough.  I understand there is some concern with popping up a dialog in a "reasonable" timeframe, but a perusal of our telemetry data (yay!  A decision based on actual data!) reveals that only around half of HTTP requests are getting their 1st byte back in less than 1 second:

   https://metrics.mozilla.com/pentaho/content/pentaho-cdf-dd/Render?solution=metrics&path=telemetry/&file=TelemetryHistogram.wcdf

(page takes a while to load: select the HTTP_PAGE_OPEN_TO_FIRST_RECEIVED metric.)

This means we're losing the correct filename a lot of the time (especially for HTTPS sites like Bugzilla, users on low-latency connections, etc.).

The attached patch bumps our default wait time from 1 to 4 seconds.  I pulled that number out of a hat, and I suggest we give our UI experts the final say.  We pay them to paint the sheds...

I've created the following page where you can both verify the behavior here, and try out different timeout values (by setting the browser.download.saveLinkAsFilenameTimeout pref):

    http://people.mozilla.org/~jduell/slowCgiScript.cgi

Parity issues: 

Chrome doesn't set a timeout at all--they simply wait for the content-disposition header for as long as it takes (I tried the 60 second link on my CGI page, nothing longer).  That seems dumb.

IE: according to 

    https://bugzilla.mozilla.org/show_bug.cgi?id=299372#c12

IE pops the download window right away in the "Getting file information" state, and once that completes the file picker shows up with the "proper" filename.  (Also seems dumb if it takes 60 seconds?).  I haven't verified this, and the comment is from 2005.

I think our UI is actually good here, as long as we use a longer timeout.
Attachment #556190 - Flags: review?(limi)

Updated

6 years ago
Duplicate of this bug: 649925
> The attached patch bumps our default wait time from 1 to 4 seconds.  I
> pulled that number out of a hat, and I suggest we give our UI experts the
> final say.  We pay them to paint the sheds...

You want the ui-review flag for this. 'review' is for code reviews.
(Assignee)

Updated

6 years ago
Attachment #556190 - Flags: review?(limi) → ui-review?(limi)
Duplicate of this bug: 645328
(Assignee)

Comment 4

6 years ago
review ping:  limi, if you can't get to this, can you reassign?  Thanks.
Comment on attachment 556190 [details] [diff] [review]
Wait for 4 seconds instead of 1 second for download filename.

Makes sense to me!
Attachment #556190 - Flags: ui-review?(limi) → ui-review+
(Assignee)

Comment 6

6 years ago
Not sure if docs are needed here.  A User UI change, not a developer API change.

https://hg.mozilla.org/integration/mozilla-inbound/rev/d2330354d3fb
Keywords: dev-doc-needed
Whiteboard: [inbound]
Target Milestone: --- → Firefox 9
It's a pref change and MDN doesn't know about the pref, so nothing needs to be updated.
Assignee: nobody → jduell.mcbugs
Keywords: dev-doc-needed
https://hg.mozilla.org/mozilla-central/rev/d2330354d3fb
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]

Comment 9

6 years ago
Mozilla/5.0 (X11; Linux i686; rv:9.0a1) Gecko/20110915 Firefox/9.0a1

I get "goggles.jpg" as the filename if I click on the 1/2 second link or the 10 seconds link. Is that expected? I can see that the pref is set to 4000. When clicking the 10 seconds link, the dialogue takes 10 seconds to appear.

What is the source code for slowCgiScript.cgi ?
(Assignee)

Comment 10

6 years ago
Created attachment 560422 [details]
CGI script for testing

Daniel,

Attached is the CGI script.

> I get "goggles.jpg" as the filename if I click on the 1/2 second link or 
> the 10 seconds link

Did you just click on 10 seconds, or right-click and select "save link as"?  If the latter, that's weird--please let me know.  If the former, then there's no surprise:  we've always waited indefinitely (well, for a much longer HTTP timeout, to be precise) for links that you click, and if the response shows up with a "content-diposition: attachment" header, we only then know that we need to download, and pop up the dialog (with the correct name, also from the dispo header).

Comment 11

6 years ago
(In reply to Jason Duell (:jduell) from comment #10)
> Created attachment 560422 [details]
> CGI script for testing
> 
> Daniel,
> 
> Attached is the CGI script.
> 
> > I get "goggles.jpg" as the filename if I click on the 1/2 second link or 
> > the 10 seconds link
> 
> Did you just click on 10 seconds, or right-click and select "save link as"? 
> If the latter, that's weird--please let me know.  If the former, then
> there's no surprise:  we've always waited indefinitely (well, for a much
> longer HTTP timeout, to be precise) for links that you click, and if the
> response shows up with a "content-diposition: attachment" header, we only
> then know that we need to download, and pop up the dialog (with the correct
> name, also from the dispo header).

I didn't pay attention was just clicking the link. Save Link As... works as expected. The 3 second link shows "goggles.jpg" and the 5 second link shows "slowCgiScript.cgi". Sorry for the confusion.
You need to log in before you can comment on or make changes to this bug.