weird filename suggested when loading URL with no filename and Content-Disposition:attachment with no filename parameter

Assigned to



17 years ago
10 months ago


(Reporter: bugzilla, Assigned: mr_pathak)



Firefox Tracking Flags

(Not tracked)




17 years ago
if you go to:
and press Ok in the "Downloading" dialog some weird filename is suggested.

Properly due to the JavaScript error:
Error: [Exception... "'Failure' when calling method:
[nsIHelperAppLauncherDialog::promptForSaveToFile]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
file:///C:/Program%20Files/ ::
anonymous :: line 414"  data: no]
Source File:
Line: 414
The JS error is unrelated (it happens because you cancel the file save).

What would you expect the proposed filename to be?  Currently we just use the
randomized "temp" filename since the site does not provide any filename hints
via url or HTTP header or anything....

I suppose we could name the file "" by default...
OS: Windows 2000 → All
Hardware: PC → All
Henrik, what did you expect the filename to be?

Comment 3

17 years ago
"" would be just fine. It's musch better than the suggested one


17 years ago
Target Milestone: --- → Future
taking off Bill's plate
Assignee: law → bzbarsky
Priority: -- → P3
Target Milestone: Future → mozilla1.1
1.1alpha is frozen.  Unsetting milestone and will retriage in a few days when I
can make a realistic assessment of the situation.
Target Milestone: mozilla1.1alpha → ---
QA Contact: sairuh → petersen
Hmm, shouldn't this go through the getDefaultFilename function in
contentAreaUtils.js? Or is that only done for "Save link as"?

(if I shift+click on the URL here, I get a suggested filename of
"" which sounds fine to me)
All that JS only runs for save link as and such.  Clicking on a link directly
takes a completely different codepath (through the external helper app service).

What we should really do is to merge the codepaths a bit.... (been on my plate
for a while now  :( )
Target Milestone: --- → mozilla1.6beta
Ben, biesi, what do you think is the way to go here?  I'm tempted to push the
getDefaultFileName() method from contentAreaUtils (which is identical in Firefox
and SeaMonkey, by the way, except the SeaMonkey version has picked up a fix or
two since the fork) into the C++.  Or push it out into a component that all
three spots can call.  The C++ solution has the advantage that embeddors can get
all that logic for free.  I suppose we could push into a component and ship it
by default and embeddors can override the component if they want, though?

We should go one way or the other on this.  This whack-a-mole of patching 3
places every time we need to fix something is getting old.
hmm, originally I was considering a "AString getFilenameFromChannel(in
nsIChannel aChannel)" method somewhere...

then I realised that it doesn't work with file|save page as which doesn't have a
channel. hm... then again, that probably needs an entirely different algorithm
anyway, precisely because it doesn't have a channel. although it does have a uri...

I like the idea of putting such a method on an interface. I don't much care
about C++ vs JS, but as exthandler is using it, it should be part of gecko. I
don't think there's much use in letting embeddors override it...
QA Contact: chrispetersen → file-handling
Assignee: bzbarsky → nobody
Keywords: helpwanted, student-project
Priority: P3 → --
Target Milestone: mozilla1.6beta → ---

Comment 10

7 years ago
Is this bug still valid? I cannot open the url specified.
Bug was valid last I checked.

A test is any url with no filename that results in a file download.

Comment 12

7 years ago
If anybody came across such url, please add it to this bug. Also where should I look for fixing this issue?
nsExternalHelperAppservice.cpp is what gets the filename here.

Comment 14

7 years ago
bz, I don't think this problem exists anymore. I started apache server on my machine and browsed to http://localhost/ which gave me "<html><body><h1>It works!</h1></body></html>". When I try to save this page by Ctrl+S, it give me localhost.htm in the save dialogue box (same as in FF6). If I add title in the html page, it gives me title_name.htm in the save dialogue box.

Am I looking at something else or what is described as problem in this bug?
You need to set up a page at that URL that sends a MIME type we don't handle internally or sends "Content-Disposition: attachment".  If you're saving via a UI action, you are not following the steps or codepath this bug is about.

Comment 7 does mention that, but it's not very clear from it, sorry.

Comment 16

6 years ago
hey I would like to help
can you assign me on dis?


6 years ago
Flags: needinfo+
> can you assign me on dis?

Here you go.
Assignee: nobody → miteshpathak05
Flags: needinfo+

Comment 18

6 years ago
(In reply to Boris Zbarsky (:bz) from comment #17)
> > can you assign me on dis?
> Here you go.


Comment 19

5 years ago
(In reply to Mitesh Pathak [:mr_pathak] from comment #16)
> hey I would like to help
> :)
> can you assign me on dis?

Mitesh, Do you have a testcase URL that fails?
Flags: needinfo?(miteshpathak05)
Keywords: helpwanted → testcase-wanted

Comment 20

5 years ago
Hi Wayne 
The URL that was provided then was broken and so i stopped working on the bug.
Nope, I don't have a testcase URL.

Regards ,
Flags: needinfo?(miteshpathak05)
Keywords: student-project
User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID 	20160215030213

Tested on Windows 7 x64 with the Nightly 47.0a1 build. The website provided is not available anymore. Issue doesn't reproduce when saving images or url's from other websites. 
Please reopen the bug if you encounter this issue again.
Thank you.
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
Please read the bug before resolving it.  Comment 15 gives explicit steps to reproduce, which I am sure you did not actually follow, since they would totally reproduce the bug.
Resolution: WORKSFORME → ---
Summary: weird filename suggested when saving file → weird filename suggested when loading URL with no filename and Content-Disposition:attachment with no filename parameter


2 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.