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

Status: REOPENED

(Firefox :: File Handling, defect)

Description

[Henrik Gemal]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

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...

Comment 2

[Boris Zbarsky [:bzbarsky]]

Henrik, what did you expect the filename to be?

Comment 3

[Henrik Gemal]

"my.gemal.dk" would be just fine. It's musch better than the suggested one
"jdskadjhfaj"

Comment 4

[Boris Zbarsky [:bzbarsky]]

taking off Bill's plate

Comment 5

[Boris Zbarsky [:bzbarsky]]

1.1alpha is frozen.  Unsetting milestone and will retriage in a few days when I
can make a realistic assessment of the situation.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

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)

Comment 7

[Boris Zbarsky [:bzbarsky]]

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  :( )

Comment 8

[Boris Zbarsky [:bzbarsky]]

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.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

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...

Comment 10

[Atul Aggarwal]

Is this bug still valid? I cannot open the url specified.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Bug was valid last I checked.

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

Comment 12

[Atul Aggarwal]

If anybody came across such url, please add it to this bug. Also where should I look for fixing this issue?

Comment 13

[Boris Zbarsky [:bzbarsky]]

nsExternalHelperAppservice.cpp is what gets the filename here.

Comment 14

[Atul Aggarwal]

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?

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

[Mitesh Pathak [:mr_pathak]]

hey I would like to help
:)
can you assign me on dis?

Comment 17

[Boris Zbarsky [:bzbarsky]]

> can you assign me on dis?

Here you go.

Comment 18

[Mitesh Pathak [:mr_pathak]]

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

Thanx

Comment 19

[Wayne Mery (:wsmwk)]

(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?

Comment 20

[Mitesh Pathak [:mr_pathak]]

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

Comment 21

[Karla Merza [Away. Please needinfo? Brindusa Tot[:brindusat] ]]

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.

Comment 22

[Boris Zbarsky [:bzbarsky]]

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.

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 24

[:Gijs (he/him)]

bug 1746052 might fix this.