Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022923 Minefield/3.0b4pre ID:2008022923 1. New profile, start firefox 2. Visit http://hourly-archive.localgho.st/ 3. Right click on a .zip file and choose Save Link As Expected: - A file-picker where I can select my download dir, and then the file visible in the download manager window. Actual: - No file-picker. Download does not start, and no feedback is given. Nothing appears in the download manager and nothing is thrown in the error console. Works: 20080229_1506_firefox-3.0b4pre.en-US.win32 Fails: 20080229_1637_firefox-3.0b4pre.en-US.win32 Checkins to module PhoenixTinderbox between 2008-02-29 15:06 and 2008-02-29 16:37 : http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-29+15%3A06&maxdate=2008-02-29+16%3A37&cvsroot=%2Fcvsroot I suspect bug 299372, so CC'ng dmose.

I can confirm, at least partially. I'm using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030106 Minefield/3.0b4pre When I right-click and choose "save link as" - the download actually happens, as if I had just clicked the link. I don't get a file-picker but I do get the file downloaded to my default download folder.

On Mac, I see the same behavior as Mukunda, but (in my case, at least), the behavior is correct: the checkin for bug 299372 coincidentally fixed another bug: up until yesterday, the preference in Main/Downloads/"Save Files to" vs. "Always ask" was ignored when using "Save Link As...". That preference is now respected. Mukunda, Steve; it would be interesting to know how that preference is set for you guys.

The default setting in a new profile (as per comment 0) is "Show the Downloads windows when downloading a file" and the default location is "Save filed to" and "Desktop".

I can't reproduce this with the nightly. On XP with build 2008030106 and a fresh profile, "Save Link As..." does what I would expect: it doesn't pop up a filepicker, but immediately pops up the download manager and starts saving to the Desktop.

I've just tested with a new profile and the latest hourly Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030107 Minefield/3.0b4pre (20080301_0709_firefox-3.0b4pre.en-US.win32.zip) and Right Clicking > Save Link As still does nothing. So my question is what could possibly be different between our systems that could effect things in such a way? Do you run a virus-killer? (I do not.) Is there anything else which could possibly cause a difference in behaviour? FWIW I filed this with such flags at the request of mconnor because he said he saw the same issue on Mac.

I do not run any anti-virus software, no. It might have to do with latency to the server in question. For me, doing "ping hourly-archive.localgho.st" shows response times of 20 ms or less for all packets. What does it look like from where you're sitting?

Considerably higher. Reply from 63.245.210.141: bytes=32 time=170ms TTL=50 Reply from 63.245.210.141: bytes=32 time=167ms TTL=50 Reply from 63.245.210.141: bytes=32 time=165ms TTL=50 Reply from 63.245.210.141: bytes=32 time=165ms TTL=50 Ping statistics for 63.245.210.141: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 165ms, Maximum = 170ms, Average = 166ms

OK, we could be onto something here. What we really want to know is how long it takes from start-of-HTTP-connection to HTTP-GET-headers-have-been-returned. Still trying to figure out the easiest way to get this info. tcpdump would probably work. I need to AFK for a little while, though; more as I figure it out..

Something to try: use about:config to crank browser.download.saveLinkAsFilenameTimeout from the default of 1000 (ms) to something much higher, say 10000, and see if this fixes the problem for you. I tried the converse test, and cranked the timeout down to 5, and I still can't reproduce the problem. :-/

My pings are in between but it WFM even when lowering browser.download.saveLinkAsFilenameTimeout to 5. Minimum = 91ms, Maximum = 98ms, Average = 92ms Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030106 Minefield/3.0b4pre ID:2008030106

browser.download.saveLinkAsFilenameTimeout=10000 did not help my situation. Strange, Right click on an image and choosing Save Image As works, and pops the file picker..

(In reply to comment #11) > browser.download.saveLinkAsFilenameTimeout=10000 did not help my situation. > Strange, Right click on an image and choosing Save Image As works, and pops the > file picker.. > I would think that "save image as" is a little different because the image is already cached. (In reply to comment #4) > I can't reproduce this with the nightly. On XP with build 2008030106 and a > fresh profile, "Save Link As..." does what I would expect: it doesn't pop up a > filepicker, but immediately pops up the download manager and starts saving to > the Desktop. > Am I misunderstanding this comment? That doesn't sound to me like the expected behavior. Clicking a link to download a file should save it to the default location. Choosing "save link as" is different: I use "save as" when I want to specify a non-default location with a file-picker dialog, however, with this recent trunk build I usually don't get a chance to specify the location, it just downloads to the default location.

Save Image As... does indeed use a different code path. Re: expected behavior, you're right. I've added more info and discussion of this to the bottom of bug 299372.

Dan try doing a Save Link As on any of the .tpl links on this page: http://www.x-ways.net/winhex/templates/index.html That doesn't work for me. A big nod goes to Defenestration on mozillazine for reporting that site. I wonder if this has to do with the Applications tab in the options dialog. I do have an entry in there for application/zip which is set to Save File. Steve do you have an entry there for zip files?

This also happens to me with http://hourly-archive.localgho.st/ It also happens when I try to download more than 2 podcasts from http://www.1up.com/do/minisite?cId=3149993. The first 2 podcasts work fine, but the third doesn't. I have a feeling that this is because the site only allows two simultaneous downloads at once (I've tried this with IE and Firefox 2.x and Firefox 3 a few nightlies before). However, a couple of nightlies ago, whenever I try downloading a third podcast, it queues it up in the download manager, but it doesn't start downloading until the other two are finished. In the current nightly, it just doesn't queue at all, much less show the save as file dialog.

We should either back out 299372 for b4 or fix this today, this isn't an acceptable regression.

Dan, can you back out 299372 and make sure that it's got blocking marked or requested on it?

Backed out bug 299372.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008030301 Minefield/3.0b4pre ID:2008030301 Save Link As is now working for me, in that downloads now happen. (As a side-effect of the backout of bug 299372, the filepicker is now also being shown, but the main thing wrt this bug is that downloads now occur.) --> FIXED

WFM on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050707 Minefield/3.0pre. Reopen if you see otherwise.