Open Bug 125086 Opened 23 years ago Updated 2 years ago

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

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: testcase-wanted)

if you go to: http://my.gemal.dk/ 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/mozilla.org/Mozilla/components/nsHelperAppDlg.js :: anonymous :: line 414" data: no] Source File: file:///C:/Program%20Files/mozilla.org/Mozilla/components/nsHelperAppDlg.js 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 "my.gemal.dk" by default...
OS: Windows 2000 → All
Hardware: PC → All
Henrik, what did you expect the filename to be?
"my.gemal.dk" would be just fine. It's musch better than the suggested one "jdskadjhfaj"
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 "my.gemal.dk.wml" 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
Blocks: 185335
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 → ---
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.
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.
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.
hey I would like to help :) can you assign me on dis?
Flags: needinfo+
> can you assign me on dis? Here you go.
Assignee: nobody → miteshpathak05
Flags: needinfo+
(In reply to Boris Zbarsky (:bz) from comment #17) > > can you assign me on dis? > > Here you go. Thanx
(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?
URL: http://my.gemal.dk/ → NA http://my.gemal.dk/
Flags: needinfo?(miteshpathak05)
Keywords: helpwanted → testcase-wanted
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 , Mitesh
Flags: needinfo?(miteshpathak05)
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.
Status: NEW → RESOLVED
Closed: 9 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.
Status: RESOLVED → REOPENED
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
Product: Core → Firefox
Version: Trunk → unspecified

The bug assignee didn't login in Bugzilla in the last 7 months.
:Gijs, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: miteshpathak05 → nobody
Flags: needinfo?(gijskruitbosch+bugs)

bug 1746052 might fix this.

Depends on: 1746052
Flags: needinfo?(gijskruitbosch+bugs)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.