Closed Bug 16043 Opened 25 years ago Closed 25 years ago

Saving downloads does not suggest a file name

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: smartin, Assigned: law)

References

(
URL
)

Details

(Whiteboard: Fixed - waiting to verify (blocked by 26607)) 

If you click on a link that is something other than html, you get a popup
that asks you what you want to do with it. One of the options is to save
it. If you select this you get a file system browser that lets you select
where you want to put it. This browser should have the name of the file to
save filled in, it does not. Therefore you have to go back and examine the URL
to figure out what it should be.
*** Bug 16057 has been marked as a duplicate of this bug. ***
E-mailing Don to request bug assignation.
Component: Browser-General → XPApps
Assignee: don → law
Target Milestone: M13
Bill, should this go to you?
Status: NEW → ASSIGNED
Yes, but I just replied to somebody out on the 'net that maybe was stepping up
bat on this one.
Updating QA Contact.
QA Contact: paulmac → sairuh
*** Bug 18228 has been marked as a duplicate of this bug. ***
Summary: Saving downloads does not suggest a file name → [PP] Mac, Linux: Saving downloads does not suggest a file name
doesn't seem to be a problem on windows (tested with 1999121609), but
definitely still an issue with linux (1999121608) and mac (1999121609). updated
summary.
*** Bug 21883 has been marked as a duplicate of this bug. ***
*** Bug 21551 has been marked as a duplicate of this bug. ***
Priority: P3 → P2
Target Milestone: M13 → M14
Do we need to fix this for beta 1?
*** Bug 20583 has been marked as a duplicate of this bug. ***
*** Bug 22861 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
Summary: [PP] Mac, Linux: Saving downloads does not suggest a file name → Saving downloads does not suggest a file name
This appears to happen on all platforms.  See bug #22861.
Blocks: 22861
*** Bug 23468 has been marked as a duplicate of this bug. ***
This isn't cross platform for me. 2000010908 WinNT build always suggests a
filename - and has for some time. Originally this was posted as a Linux bug. I
don't know if it's happening on win9x or Mac though.

bug 22861 is a different bug than this (Although they might be fixed by the same
code). I'm adding notes to that bug; basically bug 22861 says Mozilla is
suggesting the *Wrong* filename - rather than none.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Linux and Mac now properly transfer the suggested file name to the file picker
dialog.
*** Bug 19518 has been marked as a duplicate of this bug. ***
*** Bug 19518 has been marked as a duplicate of this bug. ***
REOPENing: no filename is showing up on Linux, although it is working fine on
NT. Sorry if this turns out to be just a build issue... 2 days have gone by, 
the changes /should/ be in the nightlies by now.

Tested with: 
2000-01-22-09-M14 nightly binary on Linux custom Slackware 4.0, fvwm2.
2000-01-22-08-M14 nightly binary on Windows NT 4.0sp3.
Status: RESOLVED → REOPENED
Clearing FIXED resolution due to reopen.
Resolution: FIXED → ---
From what I remember on Linux, the filename is suggested. However, if you change 
directories the suggestion goes away. It might be a regression that they are no 
longer suggested in the first place...
*** Bug 25218 has been marked as a duplicate of this bug. ***
Working for me, still (or again).  Could this be a window manager thing? I'm 
adding pavlov since he wrote the code that made it work for me (I think).

Note that there are still corner cases that don't work (results of cgi scripts, 
default index pages, etc.).  Put the URL you're downloading in the URL portion 
of this report if you think that makes a difference.
*** Bug 26203 has been marked as a duplicate of this bug. ***
Looks fixed to me in M13, the GTK+ file selector is clearing the filename when

you change directory, but that's not a Mozilla issue and should probably be a

seperate bug if someone wants to track it. Anyone still get a blank filename

when they first do "Save..." ?


If the issue with the filename suggestion being lost will not be addressed
in this bug, then bug 26203, "filename forgotten when choosing 'save link as...' 
from context menu", marked a DUP of this bug, should probably be REOPENed
to cover that issue, as that is its one focus.

Hmmm... it turns out that bug 26203 is actually a DUP of bug 3025, "file 
selection dialog forgets filenames on chdir", M16, ASSIGNED, pp - UNIX,
so that issue need not concern this bug anymore at all.
Whiteboard: Fixed - waiting to verify (blocked by 26607)
*** Bug 28524 has been marked as a duplicate of this bug. ***
added dependency.
Depends on: 26607
hokay, marking as res. fixed as per law...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
hokay, round 2: i'm might've mistakenly/prematurely resolved this bug (my
apologies). this is what i did in order to verify this bug (opt comm bits
2000022308 on linux, mac and winNT):

1. went to http://www.mozilla.org/
2. selected File > Save Page As
result: native Save File dialog appears, but the filename field is blank.
expected: to see index.html in the filename field.

*however* pls do lemme know if what i've done is due to another bug --it might
be since what i did above is just an html page! if that is the case --and i did
test Save As on an *.exe file (ie, Save Link As via context menu), and the
filename did appear properly-- i'll happily resolve this bug. thanks!
URL: http://www.mozilla.org/
Keywords: verifyme
OK, here's the deal.

At one time, nobody ever suggested a file name.  I fixed that XP-wise, but then 
Linux didn't support it properly at the point it interfaced with the file 
picker.  Then, that was fixed, more or less.

I think this bug referred to the original, widespread problem.  Which is fixed, 
more or less.

There are (at least) three remaining problems, however:

1. On Linux, switching directories in the file picker loses the file name.  I 
think there's a bug open on this (and it may even be mentioned above).

2. On all platforms, the suggested name is not correct if it's a cgi script.  I 
have a bug on that, I think (or it was at least mentioned in one of the myriad 
of bugs on this topic).

3. On all platforms, if the url is of the form "http://www.xxxx.com/" then we 
don't suggest "index.html" (when such a url resolves to ".../index.html").  I 
think I have a bug on that one, too: 24817. 
thanks, bill!

so, am gonna verif this puppy --all other issues should go under separate bugs
from now on.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.