387894 - Wrong File Name on Download with "Save Link Target As"

Status: RESOLVED DUPLICATE of bug 426742

(SeaMonkey :: Download & File Handling, defect)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 Mnenhy/0.7.5.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 Mnenhy/0.7.5.0

Not only was the file name wrong, but the file extension was also wrong.  This happened while downloading the new PrefBar 3.4.1 from Mozdev.  

Reproducible: Always

Steps to Reproduce:
1.  In Mozdev, go to <http://prefbar.mozdev.org/installation.html> and right-click "install PrefBar" (which is the link indicated above in this bug report).  
2.  Select "Save Link Target As" from the pull-down menu.  
3.  Save the file.  
4.  Use the MD5 hash adjacent to "install PrefBar" to verify correct download.  
Actual Results:  
Downloaded file is named "installation.html".  

Expected Results:  
Downloaded file should be named "prefbar3.4.1.xpi".  

After downloading, I renamed the file from "installation.html" to "prefbar3.4.1.xpi".  I then successfully installed PrefBar 3.4.1 from the file.  That demonstrated that the correct file was downloaded but also that it had the wrong name.  

See also the thread "PrefBar 3.4.1 now available" at <news://news.mozilla.org:119/mozilla.support.seamonkey>, starting with my message dated 7/11/2007 7:39 AM.  Note especially the reply by Philip Chee dated 7/11/2007 6:08 PM.  While Chee indicates a Gecko issue, Bugzilla indicates that Download Manager is a Client Software component of individual browser products.

Comment 1

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008060902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

WorksForMe, with SM 2.0 trunk.

***

Can you reproduce with SeaMonkey v1.1.9 ?

Comment 3

[David E. Ross]

This appears to still be a problem in SeaMonkey 1.1.9.  However, finding a test case can be a problem when there are changes in the affected Web pages.  

The test case cited in <https://bugzilla.mozilla.org/show_bug.cgi?id=399824#c2> can be used if the browser Stop button is selected as soon as the page initially loads.  If the Stop button is not selected, another page then loads where the problem does not exist.  

At the present, I cannot otherwise find a download link that can cause the problem.  As noted in bug #399824, such a URI involves a query (indicated by ? in the URI).  The end of the path-file prior to the ? is used to name the local file.  Instead, the actual file-name should be used unless, of course, changed by the user in the Save As dialog window.