483429 - FF modifying html source code in download links - download manager hangs.

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Tim Francis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.20) Gecko/20081217 Firefox/2.0.0.20

correct download links in source code are not being translated correctly into Save As... links.

HTML Page code:
<div align="left"><a target="_blank" href="C:/Program Files/EasyPHP2/www/data/temp_files/test2009-03-14_2_r">test2009-03-14_2_r</a></div>
Save link as location = 
c:/Program Files/EasyPHP2/www/data/temp_files/test2009-03-14_2_r

Please note the lower case "c". - the original is C:/

Their is also an absence of "file://" which I am sure was in earlier versions.

BTW - the file has no extension - the data output from an animation camera ... needed to input into another program to create matched moves in 3D graphics: I'm the programmer having to write the data file interface - the files have to be exchanged over the internet, either by http or ftp.


Reproducible: Always

Steps to Reproduce:
1. Download the page
2. Save link as 
3. Download manager then hangs with an un-resolvable path.
Actual Results:  
Save Link as... launches download Manager which then hangs on the deadline.



Expected Results:  
be nice if you can save the file! 

If not a http:// address, the file:// should be substituted. 

At the very least, C:/ should not be downgraded to c:/

This bug highlights a big hate of mine - The Download mangaer is flaky in the extreme. On slow connections, it just doesn't do its job - it just jacks in the DL after completing 135Kb of a 2.3M file, with a cheerful message saying done. basic one-line maths will detect an incomplete download and warn the customer the file (critical for a vital meeting he is rushing to), is corrupt; Happened to me and its not funny.

Be good too if the properties were at least editable - then there s some chance of manually editing the bug.

As it stands, the download module of FF2 and 3 sucks big-time. With FDM not being supported by FF3, it really needs to be redesigned and made to:
1: report failed downloads... Definitely should not say done.
2: Downloads should be resumable.

FF2.0.0.20 is locking up on vista and task manager cannot close te program - requires a full reboot.

Comment 1

[Matthias Versen [:Matti]]

Your bug is a little bit unclear (at least for me).

>1. Download the page
How to download what kind of a page ?
Do you mean that Firefox asks you to save a url becuase the mime-type isn't internal handled or do you mean save page as "webpage complete" or "webpage, html only" or do you mean that you open a http:// html page ?

>2. Save link as 
If I understand you the link in the html file is "href="C:/Program..." ?
That is just an invalid link, every URL must start with a protocol.

A simple rule in bugzilla is one issue/bug report and you have to search before filing new bugs. Bugzilla is not for tracking your issues, it's for tracking bugs for the developers and different issues are handled by different developers.

The other cases should be already in bugzilla or are invalid like:
>FF2.0.0.20 is locking up on vista and task manager cannot close te program -
>requires a full reboot.

FF2.0.0.20 is at the end of life and no longer supported but in general it's never (!) for all applications (!) except applications that install kernel mode drivers the fault of the application if it looks up and can not be closed. That's either a driver issue (the buggy Zonealarm Firewall driver is known on vista to do that unless you uninstall ZA) or a system/OS issue.

Comment 2

[Tim Francis]

For clarification, the bug is 

In the supplied <div></div> example, the source code say C:/

FF2.0.0.20 is translating this as c:/ in 
1: copy link location
2: save link as...

If 'Download' tries to process the link, it hangs because the path is wrong.

If I manually correct the c:/ to C:/ in a new page FF browser URL, it displays the file contents, just as it should do, and does in other browsers/earlier versions of FF.

I have rewritten the code several times, to move/remove the 'target="_blank"' tag between the <a> and <href> in <a href> but still the path name is wrong. It's not a html issue.

The contents of $path_strings are being changed by FF..

Comment 3

[Matthias Versen [:Matti]]

Firefox never accepts such an invalid link without protocol except if you manually enter it in the URL bar. The URL bar corrects common errors, you can for example write mozilla.org instead of http://www.mozilla.org and it will be fixed or you can write C: and the URL bar fixes it to file:///C:/ (note the uppercase C:) but such errors will be of course not accepted in a HTML/XHTML whatever document.

The downloadmanager can't resolve the URL not because c or C ,the windows file system isn't case sensitive (it doesn't matter) and for every valid link it would also not matter because the protocol, which must be always in front of an URL, is also not case sensitive.

marking invalid (invalid URL without protocol)

Comment 4

[Tim Francis]

 Matthias "matti" Versen wrote:
The URL bar corrects common errors, you can
for example write mozilla.org instead of http://www.mozilla.org and it will be
fixed or you can write C: and the URL bar fixes it to file:///C:/ 

Granted: But in this case and for any copy and paste into other down-loaders, this won't self-correct because Firefox is corrupting the link: THAT IS THE POINT!

Firefox should NEVER be corrupting the true path.

Comment 5

[Matthias Versen [:Matti]]

Attachment: Example Htmlpage

Comment 6

[Matthias Versen [:Matti]]

Using this example page with FF3.0.7:
"Save link as" = nothing happens because the path is invalid
"copy link location" and you get c:/test/test.jpg in the clipboard (note the lower case c )