Closed Bug 301328 Opened 19 years ago Closed 14 years ago

Download Manager opens the wrong file

Categories

(Toolkit :: Downloads API, defect, P3)

Product:
Toolkit
Component:
Downloads API
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 593815
Milestone:
mozilla1.9.2a1
Tracking Flags:
Tracking Status
status1.9.1 --- wanted

People

(Reporter: lucisandor, Unassigned)

References

(
URL
)

Details

(Keywords: dataloss)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050711 Firefox/1.0.5 The file is launched through the META HTTP-EQUIV="refresh" mechanism (not sure if it has any impact). According to my settings, PDF files should be opened in Acrobat Reader, outside the browser. That means that the PDF is saved to the Temp folder. If I already have a 28.pdf file, Firefox renames the file to 28-2.pdf, although Download Manager displays its name as 28.pdf, as on the server. Irregularly it fails to open the downloaded file, although it is completed. Then, when I click on the 28.pdf "Open" link of the Download Manager, I open the real 28.pdf, not the recently downloaded 28-2.pdf. Reproducible: Always Steps to Reproduce: 1.Set Acrobat Reader not to open PDF inside the browser. 2.Set Firefox to automatically open PDF files in Acrobat. 3.Navigate to a PDF file called 28.pdf. The file is saved on Temp and it is opened from that location in an external application. 4.Close Acrobat.No handle should prevent Firefox from cleaning its Temp. 5.Navigate to another 28.pdf (tested when loaded with META refresh). 6.Open it from the Download Manager. Actual Results: Instead of the newly downloaded file, called 28-2.pdf on disk, you get 28.pdf, the old file. Expected Results: Open the newly downloaded file.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 When downloading 'scripts.log' for the nth time, the files scripts-12.log is opened in notepad. But clicking "Open" in download manager will open the old file "scripts.log", not "scripts-12.log". Even though scripts-12.log triggered the addition of scripts.log to the download manager. Looks like the same bug to me..
*** Bug 348902 has been marked as a duplicate of this bug. ***
I have the same problem with a rar file. If i chose to open it with winrar..winrar shows me a recent version (which I downloaded earlier), not the new file! I tried to delete all files from the wxp temp directory but it still didn't work...
After you cleared the cache it works (I think until u get another two files with the same name...and so on)
WFM with zzz.t on my local server and gedit. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070605 Minefield/3.0a6pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 The files are not deleted, but the correct file is opened.
Sorry, was reproducing incorrectly (see comment #1). Confirmed with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070610 Minefield/3.0a6pre
OS: Windows XP → All
Whiteboard: DUPEME?
Looks confirmed, can't find other dupes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-firefox3?
Whiteboard: DUPEME?
not a regression, not a blocker, afaict this has been an issue for every Firefox release.
Flags: blocking-firefox3? → blocking-firefox3-
A couple datapoints: [1] https://bugzilla.mozilla.org/attachment.cgi?id=289648 is a nice screenshot that gives an instant overview of the problem [2] From https://bugzilla.mozilla.org/show_bug.cgi?id=404745#c3: Edward Lee wrote, "The file gets renamed by nsExternalAppHandler::ExecuteDesiredAction which then immediately calls OpenWithApplication followed by nsDownload's OnStateChange. Seems like the nsDownload has no idea that the file gets renamed and doesn't have a way to get to the new name."
Flags: wanted-firefox3.1?
Product: Firefox → Toolkit
Nice to have, wanted+
Flags: wanted1.9.1? → wanted1.9.1+
Please fix! A reputable website has unfortunately taken the boneheaded step of delivering all of their downloadable pdfs as MergePDFs.pdf rather than a unique name, & the download manager displays MergePDFs.pdf for all of them rather than MergePDFs.pdf, MergePDFs-1.pdf, MergePDFs-2.pdf etc.
Seconded on the please fix. This is causing MAJOR problems for some websites and their users.
Why isn't this bug a blocker?
(In reply to comment #28) > Why isn't this bug a blocker? Because it's been around since at least Firefox 1 and is not a regression.
Flags: wanted1.9.2+
Priority: -- → P3
Target Milestone: --- → mozilla1.9.2a1
Maybe I'm missing something. If this bug has been around since Firefox 1 per Comment #29, why is it not fixed? Considering the new download manager and all the other changes under the hood, I find it odd that this bug has not been researched and fixed.
This behavior is enough to cause dataloss.
nominating due to number of dupes, dataloss, and leading to results like bug 514823
Blocks: CVE-2009-3274
blocking1.9.1: --- → ?
status1.9.1: --- → wanted
Flags: blocking1.9.2?
Keywords: dataloss
No longer blocks: CVE-2009-3274
blocking1.9.1: ? → ---
I don't see us fixing this yet. -'ing for 1.9.2
Flags: blocking1.9.2? → blocking1.9.2-
This bug has been around for about five years now. I'm not really familiar with the inner workings of the download manager, but is this particularly complicated to fix? Is "it's been around since the beginning" really a good reason not to fix a bug?
(In reply to comment #37) > This bug has been around for about five years now. I'm not really familiar with > the inner workings of the download manager, but is this particularly > complicated to fix? Is "it's been around since the beginning" really a good > reason not to fix a bug? Yes, it is complicated to fix. This is why it hasn't been fixed yet.
5 years and no fix? Ok let me demonstrate lateral thinking - the fix is easier than you think - just change download manager to prompt you for the filename to save. Done - finished. This is SEVERE. We hit this bug about once a month and feel bad for the untold thousands of users are unable to figure it out, and who embarrass themselves by insisting the have the latest file but its not updated! Its sabotage for browser downloads! If this isn't fixed in 30 days I'm filing a bug that the bugfix system isn't working.
Followup - got an etiquette warning, sorry if I let my frustration show. If you hit this bug, you'd say ARRrrrgh! too. But changing the download manager behavior to require user input is a GREAT idea, rather than to continue with the current 'automated but completely evil result' approach. And filing a top level bug, i.e. widening the bug out of toolkit to the main development queue is another good idea, so I'll file a mozilla main queue bug now, as well as voting up the severity here.
The reason this hasn't been fixed after five years is because it requires refactoring a large chunk of this code and would take quite some time (not to mention be regression-prone, as I don't think we have much in the way of automated testing for this code). I'd love to fix (almost) all of the bugs in bugzilla right now, but we have limited developer time and so bugs that are deemed less important get pushed off into the future.
fwiw: workaround 1) change option preferences..general..downloads to either 'close window after download' (to force you to look for the correct file) or 'ask me where to save' to force manual file naming (avoiding the auto naming failure). 2) avoid using download manager: right click a websites file link and choose "Save Link As..."
Did the patch in bug 593815 fix this?
(In reply to comment #46) > Did the patch in bug 593815 fix this? Possibly. That code is difficult to follow and that patch had no test with it so I can't say for sure without spending some time verifying it.
(In reply to comment #46) > Did the patch in bug 593815 fix this? Yes it should.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.