Closed Bug 115176 Opened 23 years ago Closed 22 years ago

<title> [or link text] is used as default filename when doing Save Page [or Save Link]

Categories

(Core Graveyard :: File Handling, defect, P4)

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.1alpha

People

(Reporter: bugzilla, Assigned: bugs)

References

()

Details

(Keywords: regression, Whiteboard: [DO NOT REOPEN])

Attachments

(1 file, 1 obsolete file)

the <title> or link text is used as default filename when doing Save Page or
Save Link, respectively. found using 2001.12.13.14 comm bits on linux and
2001.12.13.16 comm bits on winNT.

recipe A - Save Page:
1. go to http://www.mozilla.org/
2. hit accel+S or select File > Save Page As...
3. look at the filename in the resulting file picker.

result A: the suggested [default] filename is "mozilla.org.html"
expected A: well, preferably "index.html" --but that's blocked by bug 24817. so,
i guess reverting to the previous behavior of 'no suggested name' would be kinda
expected [tho' again not ideal].


recipe B - Save Link As:
1. in the same page, http://www.mozilla.org/, bring up the context menu for the
"At A Glance" link on the left side --which points to
http://www.mozilla.org/mozorg.html
2. select Save Link As from the context menu.
3. look at the filename in the resulting file picker.

result B: the suggested [default] filename is "At A Glance.html"
expected B: should be "mozorg.html"
Keywords: regression
*** Bug 115080 has been marked as a duplicate of this bug. ***
Here is my comment from bug 115080
------- Additional Comment #2 From Gilles Durys 2001-12-13 09:52 -------

I forgot to say that shift-clicking on a link shows the correct filename.

How does Mozilla know the default page served out for a dir is called
index.html? Does it come back in the HTTP info?

Other than that, the issue of the default filename is difficult to decide. While
most URL have sensible file names (e.g. foo.html), what name do you use if the
URL is something like this?

http://www.somewhere.com/sdfsd%20fsdf.dll?id=23423492%3008342930842394&a=3248723498273984237432

spoke with ben last night, and as it turns out this is intended behavior. he
implemented this mainly since this is IE's behavior on win32 [although
admittedly not what comm4.x had done].

recently checked IE5.1 on mac 10.1.1, which differs:

* Save Link used the filename --eg, resulted "mozorg.html" with case B: like
comm4.x and previous moz builds.

* Save Page used the <title> without an extension --eg, using case A, the saved
file was called "mozilla.org": like current moz builds.

not sure how the latest version of IE on mac 9.x behaves --if it's any different
from IE5.1 on X or IE on win32...

from email ben sent me on this, the default file name in mozilla is now
determined in the following order:

1. use the caller-provided name, if any (e.g. text under a link), or,
2. use the name suggested by the HTTP headers ("Content-Disposition"), or,
3. use the document title, or,
4. use the actual file name, if present, or,
5. use the host.

and this would be applicable when using:
* File > Save Page/Frame from the toplevel menu
* shift+click link saving
* context menu Save Page/Frame, Save Link, Save Image.
Keywords: 4xp
imo, the filename should be used first if present and  if the link points to
anything but a html file.
I'd hate having a here.zip file when saving a link that looks like this: 
download <a href="explicitfilename.zip">here</a> 
or a "click here to download.jpg" when saving a link like this:
<a href="mozilla.jpg">click here to download</a> 
I certainly hope Mozilla developers haven't gotten into the mindset of feeling
they have to duplicate every damn-fool thing that MSIE does, whether it makes
any sense or not.  There wouldn't be much point to Mozilla's existence at all if
it aimed to be a precise clone of MSIE.

Where save filenames are concerned, using the title or link text tends to
produce really grotesque filenames with spaces and punctuation in them, not in
any way what I'd like to save the file as.  Using the actual filename appearing
in the URL would be a more sensible solution.  If there is no filename in the
URL (e.g., it's a directory reference ending in a slash), then you might use
index.html (there's no way for the browser to actually know what the real
filename was on the server, as the HTTP protocol doesn't supply that, but
index.html is at least a decent guess).
*** Bug 115482 has been marked as a duplicate of this bug. ***
This is especially annoying at thumbnail galleries for porn movies.  The file
names are sequential, and the alt text is usually useless.  I thought I had
clicked "save image" instead of "save link" at
http://www.giantsexmovies.com/massivesexclips/asianteen/indexvdo.html, but it
turned out that the thumbnail had an alt text of "1.jpg".
Since 9/11, I've been saving a number of news articles. I think it would be
interesting to look at them again several years from now.

When I download a file I use a URI. When I save a file from the web to a local
drive, I expect the file to be named exactly as the URI was named. If I don't
like the HTML filename, I can change it before I save it locally. This bug
seriously depletes the functionality of Mozilla. It makes you retype the
filename every time you save the file. This bug is serious enough to drive me
back to Netscape 4.79.

It would be handy, I admit, to have a checkbox in the Save file dialog box to
use the Page title as a filename, especially for CGI generated pages. That
should NOT be the default option, however.

If I sound angry, it's because I am a little angry. This is one of those gut
level, instinctual responses. I was just beginning to trust Mozilla as an
application, and now it's mangling my data.
Proposing to mark this bug's severity as blocker, and add the "data loss" keyword. 

The data that this bug causes to be lost is the HTML filename, which must be
manually retyped by the user to prevent its loss. 
It's a "quibble-able" point whether this is actually a "data loss bug", or for
that matter even a bug at all, since the filename as shown in the URL isn't
actually part of the document's data (and, in fact, as purists will always note,
the URL doesn't necessarily contain any actual filename at all -- filenames and
URLs are two totally different things that only happen to be mostly congruent in
normal usage).

On the other hand, I agree wholeheartedly with all the people who say that this
needs to be fixed... the portion of the URL that resembles a filename (whether
or not it actually *is* the filename in which the document is stored on the
server) ought to be used as the default save filename, *not* something else
cobbled up from the TITLE or link text.
There is not data loss here, not even perceived.  This is a minor inconvenience,
and even that is questionable, since we could just leave the name blank.  Is
there an approved spec? If so this is invalid.  If not, does UE have any
objection to current behavior? If not, this is either WFM or *very* low
priority.  ->p4 for now.
Priority: -- → P4
Peter Trudelle: Browser is requesting via HTTP file with concrete name (as part
of URL), so save it with same name. Replacing original filename by text in
<TITLE> is very useful and cool feature, but it's not good as default. It should
be as checkbox in Save as dialog.

BTW text in <TITLE> should contains other chars than 7-bit ASCII (as national
chars) or should be pretty long -> on some systems is hard (or harder) manage
these filename. Futhrermore, many websites has same text in <TITLE> over
thousands pages.
The problem I see is that now saving link for anything but html is not consistent:
saving e.g. a zip file shows different filenames whether you save by clicking on
the link or using "save link as".

There should be a distinction between how html file and the rest are treated.
There seem to be some "dueling bugs" going on with regard to what default
filename to use... bug 67901 seems to be the exact inverse of this one,
objecting to the use of the URL filename as the default save file instead of the
title text.  The actual behavior seems to have varied greatly between different
Mozilla builds, and also has varied by whether you're using the Save As feature
in the File menu, or a right-click context menu for saving the contents of a
link, or a normal click on a link that produces data of a MIME type that is
saved rather than displayed.

I think there needs to be a preference setting for this, or else there will
always be warring camps between people who prefer use of the "true filename" and
those who prefer the page title (or link text if saved by right click).

Perhaps a new bug needs to be opened to discuss the general issue of how to
handle default filenames on save, as there are several different sub-issues
involved here.  As it now stands, the bugs I know of deal only with specific
narrow cases, and are all written from the standpoint of favoring one or another
position on them.  A "big-picture" bug would be more useful toward trying to
resolve the whole matter in a way that everybody can live with.
I disagree.  We have always been way too quick to settle design differences by
adding one or more prefs. As a result we get unwanted pref and code bloat,
myriad untested code paths, unnecessary UI complexity, and lots of extra
defects, most of which are hard to pin down due to pref permutations.  Typical
end users do not want prefs, they never even open the dialog.  What they want is
simple, consistent, predictable behavior.  If we can't give them that,
especially in this trivial case, then we should admit to being miserable failures.
This bug causes *data loss*. So far, no one has made a real argument why it
isn't data loss. The data that is lost is the filename.

Here's an example. You are working on some HTML files, about 200 of them. You
upload them to a web site. Then, your local copies of the files are lost when
your local hard drive crashes. At the same time, you lose ftp access to the web
site. Your only way to get those 100 files back is by manually downloading them.
So you download them all manually. Then, you look at the subdirectory where you
put them all. They are all named in the convention of 123.html, 124.html,
125.html, 126.html, etcetera. Back when you were creating the HTML files, you
hadn't settled on a convention for the HTML titles, so you just put numbers in
the titles. The numbers were never indexed. The numbers were assigned randomly,
in effect. You had been identifying the files by filename. Now, you are stuck
with a large amount of files that you must painstakingly, manually rename. Until
you do so, your access to the data is nil. 

This has the same practical effect as if Mozilla saved the file in a corrupt format.

There is another solution, of course. Just download the files with another web
browser. That is exactly my point. You shouldn't have to use another web
browser. Mozilla should not create data loss, not even in the filename.
Especially not in the filename.

Mozilla isn't a "typical end users"' browser... if it were, it would have more
than the fraction of one percent it typically gets in site access stats. 
Mozilla, as it now stands, is more of a browser for the geeks, power users, and
others not satisfied with the lead-the-dumb-user-by-the-nose style of Microsoft.
 These sorts of people are more likely to want to tweak their preferences, and
more likely to have quirky preferences of their own that can never be satisfied
by a one-size-fits-all mandatory setting.
The two camps here, between wanting save by original filename as inferred from
the URL vs. save by title or link text, seem to be a classic cultural divide
between traditional computerists brought up in command-line environments and
recent computer users who have known only graphical environments.

The old time computer people ("Geeks") want and expect filenames to be concise
things designed to be easy to type in and limited to "safe" characters that can
pass unscathed in transfers between different operating systems, applications,
and transfer protocols (basically just letters, numbers, dashes, and underscores). 

New computer users ("Weenies") are used to long, descriptive filenames that
might have spaces and punctuation, and which they never have to retype exactly
because they can just drag and drop the file wherever they want.  They're not
concerned with compatibility with other operating systems or software because
they're only vaguely aware (if at all) that operating systems or software exist
in the world beyond whatever was pre-installed on their machine.  So, whether
they're using Windows or MacOS, they expect the whole world is the same.

Microsoft is clearly favoring the latter camp in their development, so Mozilla
might be better off favoring the former in order to carve out its own niche,
though a preferenceable setting might let it support both.
I agree with that. If the Mozilla project ever gets a motto, it should be: "Our
users are intelligent and capable." 

IE's motto, OTOH, is: "We presume that our users are incompetent buffoons."



The file name is exactly where it was, on the server, completely intact, not lost. 
Most of the people working on this application are doing so with the expectation
that it will appeal to the masses, not just the geek elite.  We are not going to
carve out a tiny niche of a few thousand dwindling users, while leaving the
fast-growing billions to the competition.  That way lies failure.
Perhaps the best resolution of this could be a topic for usability testing that
we will do next month.
My vote is to keep the current behaviour for documents but not images, pdf files
etc. In documents, using the title increases the likelihood that the file name
is meaningful and unique.

If someone really wants to they can type the name as it appears in the address
bar as they're saving it.
If this bug will be keeped in for more then a few days - i'm switching to IE - I
download about 100MB of video files a day and it's annoying to "copy link
address" go to my filemanager (which is also a simple download tool) and do a
"download url" in order to get a filename other then "download" for a video file :(
In build 2001121909, the "Save As" function (for saving the current document)
has returned to using a default name based on the filename (rather than
something taken from the title element as it was for a while), but the Save Link
function still uses the link text rather than the URL filename, even though link
text can very often be something really useless like "Click Here".  For utility
and consistency, that should use the URL filename as well.
While Mozilla should certainly aim to ultimately be a browser that's usable by
all and can someday expand out of its "niche" and become a mainstream browser
(or the basis of several mainstream browsers built from its code), it shouldn't
do this by dumbing itself down and losing the support of the "geek niche" it has
now.  It would be nice if it could have the "good stuff" that Microsoft would
never put in its browser, but still be usable by the masses.
*** Bug 116353 has been marked as a duplicate of this bug. ***
In commnent #4, it is mentioned that this change was made to be more consistent
with IE on Win32, but from what I can see, Mozilla now behave more differently
than IE on Win32.  If I take Mozilla trunk 2001-12-21-03 and compare it with IE6
on Windows 2000, it seems that Mozilla is much more aggressive about using the
link test when saving using "Save Link As..." off of the context menu than IE6
is when using "Save Target As..." off of its context menu.

As an example, go to http://www.codeweavers.com/technology/wine/download.php and
compare how Mozilla and IE6 behave.

Near the top of the page is a link called “Installable Package.”  It is an ftp
link to a .rpm file.  If you right click to save it in Mozilla, the name is
“Installable Package” with no extension.  In IE6, the name is
“codeweavers-wine-20011108-5.i386.rpm”.  In this case the IE6 behavior makes
much more sense than Mozilla’s.

Near the bottom of the page is a link called “CodeWeavers Wine Tour.”   Mozilla
wants to save this as “CodeWeavers Wine Tour.html.”  IE6 wants to save it as
“tour.php”.  In this case, the new Mozilla behavior might be nicer, but it is
not closer to what IE does.

Whatever the arguments for changing Mozilla’s behavior, I do not think “making
it behave more like IE on Win32” is one of them.
*** Bug 116506 has been marked as a duplicate of this bug. ***
Well, this bug seems to be fixed, at least as of the 0.9.7 milestone build.

There are no plans to change Mozilla's behavior back to "title saving" are there?
*** Bug 116557 has been marked as a duplicate of this bug. ***
The current behavior sometimes makes a file lose it's file extension, or worse,
having it changed to a wrong extension and rendering it useless.

See my reproduction notes in bug 116557, which was duped against this one.
>Well, this bug seems to be fixed, at least as of the 0.9.7 milestone build.

Broken for me, Mac OS X 0.9.7 2001122106.  In fact, that's what got me to do a
Bugzilla search, when it tried to save a .tgz file as "here.html" when I did a
ctrl-click/save-link-as with the context menu.  (Note that I also tried just
clicking on the link, but apparently the site didn't have mime types set up
right, and Mozilla tried to display it as text with obvious results.  I suspect
that's where the ".html" came from.)  Luckily, the directory containing the .tgz
didn't have an index.html and I was able to context menu save as properly from
the directory listing.

IMHO, this is completely stupid behavior.  I can understand when the link is
some CGI-generated crypto garbage, but not when you're trying to download an
archive via a link with a simple URL.
*** Bug 116671 has been marked as a duplicate of this bug. ***
'Save link as' copies a file from one machine to another. The filename should be
included in that save, regardless of the type. People put the weirdest
descriptions in their webpages, whilst filenames are usually more consistent. I
therefore strongly urge to restore the original functionality
There are really two distinct cases of this "bug" (or "feature") that are
sometimes getting confused in the commentary:  (1) the case of saving the
current document using "Save Page As", and (2) the case of saving a linked
document using "Save Link As".  (A third case, of following a normal link that
leads to a document of a MIME type that causes Mozilla to prompt the user to
save the file rather than displaying it directly or launching another
application or plug-in for it, is apparently out of the domain of this
particular bug, though consistency of behavior there might be desirable.)

The "Save Link As" option apparently generates its default filename before it
loads the linked document, and hence has no access to the document title (if
any) as an option for use in naming.  That's why the link text was chosen, but
this is often something meaningless like "Click Here", so it isn't that good a
choice.  (On the other hand, there *are* occasions where the link text actually
makes a better save filename than the name in the URL; for instance, links
within Bugzilla to other bugs have "show_bug.cgi" as the URL filename, which is
less meaningful than the typical link text of "bug 115176".)

I would suggest as a general rule using the filename found within the URL, both
in "Save Page As" (as is currently being done) and in "Save Link As".  Perhaps
some sort of special cases need to be considered for instances when there is no
filename (e.g., a URL of a directory or raw domain name) or the URL filename is
a CGI script with parameters -- it can be argued that the title and/or link text
may be more meaningful as a save name in these cases.  But where a clear
filename like "blahblah.html" or "somestuff.zip" exists in the URL, it should be
used.

However, if a "Content-Disposition" field is used which specifies a filename,
that ought to be the default, overriding everything else.  This isn't a
frequently used feature, as far as I know.
Hmmm.
Why is this bug a P4 when it's marked as "major severity?"
Who decided that save link as should behave like this?

Facts: 
* Comparing Explorer 5.5 "save target as" with mozilla 0.9.7 "save link as" 
reveals that they are now very different, confusing geeks and newbies.
* People's naming of links on the web makes mozilla unusable to me after this
change, however nice the idea was. Mozilla will not be able to evangelize this.
* People use the web largely to collect files and mozilla should not rename
those files. Who said that the link text is the filename?

I want "save link as" to behave exactly as shift+left mouse click does. I *need*
to have a menu to do this because my left hand is somewhat disabled and I don't
want to shift click a lot. This is an accessability issue for me.

I *completely* agree with comment 35!  This bug is a *major* PITA and renders
Mozilla completely unusable for me for downloading files.  While I sometimes
rename the files from foo.zip to something more meaningful, I always also keep
the original filename (foo.zip in this case) as the last part of the much longer
filename I chose.   Quite honestly, for zip type of files, I cannot remember if
I ever wanted to save the file exactly as the link title was.

So I'd like to get the old behaviour back!

For the case of doing a File->Save Page As or Right Click->Save Page As, I kinda
like the IE behaviour, ie. defaulting to the <title> of the page.  But that's
for sure not the case when I right-click on a link - even if that target turns
out to be a text/html file.
Perhaps an example a little closer to home will help:

"mozilla-win32-0.9.7-talkback.zip" is a *much* more informative filename than
"talkback enabled zipfile"  (http://mozilla.org/releases/)
Okay, my mistake, I have been persuaded this is bad. It is perhaps most
distressing to people using the HTML Editor to edit pages on their local web
site.  We now have no round trip for file names, so they can't easily edit their
site.  For example, after editing their 'index.html' file, they save the
changes, don't realize the changes are saved under the name "My Home Page", and
wonder why they don't show up when browsing the page.  Not real data loss, but
it can be apparent data loss, difficult to diagnose and recover.  P2.
Priority: P4 → P2
Looks good to me. As a Linux user, Mozilla remaining in the title (with a hidden
pref to disable even that), and buildid moved to the menubar is acceptable to me.

Since we SHOULD be removing Debug and QA during release builds I think the build
id disapearing during those builds is also appropriate, so this helps that too.

What about swaping Debug <-> QA, so the {buildid: XXXXXXXXXXXX} hangs off the end?

Just restore the space before checkin:
-         // Title will be: "Doc Title - Mozilla"
+         //Title will be "Doc Title"
            ^
*** Bug 116833 has been marked as a duplicate of this bug. ***
*** Bug 116869 has been marked as a duplicate of this bug. ***
I aggree with all the people that say that mozilla should use the filenames for
links.
IMHO the best way to do this is to have it so that mozilla uses the filename by
default (which is what most users want and its what IE does)
Then add a preference that can be turned on for the 0.0001% of users that
accually prefer the use of the link text.
You could have the preference like this
1.Use filename always
2.Use link text always
3.Use filename for most files and use link text for special case stuff like CGI
scripts
Option 3 would be the default.
A pref would be quite annoying. I usually want real file name. Sometimes a page
is poorly named, or has a long CGI path, and I type in a better name. What about
a button in the save dialog:

[ Use Title ]

That replaces e.g. index.html with e.g. Mozilla Homepage.html. This would also
replace the filename with the link text for "Save link as...". "Use title" could
use some better wording, admittedly, but I personally think this is the best of
both worlds, as long as it can be cleanly integrated into the dialog, without
confusing new users. Should be possible.
*** Bug 117282 has been marked as a duplicate of this bug. ***
*** Bug 117328 has been marked as a duplicate of this bug. ***
Oh, this makes saving auto-detected urls (eg from mail messages) a pain since 
the filename is the full url.
I'd like to put my vote down for keeping the filename. If the user wants to call
it something else, that's what the filename picker's for. The default should be
something that works when you hit OK.

- Try saving a set of news articles from e.g. http://www.theregister.co.uk,
where every page on the site is is just called "The Register". If you save more
than one you get a file already exists error.

- Any number of sites with exclamation marks, dashes, stars, stripes, star
spangled banners, or whathaveyou in the title and you end up with invalid
filename errors.

- Titles with Middle Eastern, Asian, or Oriental character sets don't look nice
when used as filenames on computers that doesn't have that character set or an
operating system that can cope with filenames in e.g. Japanese (you either get
rubbish or invalid filename errors). It's easier to keep it Western.
Blocks: 115634
Keywords: nsbeta1
It's quite simple.

The menu option is called save link as, the link is part of the URL, or URI,
which is a total different thing, often, than what is specified between the anchors.

Not to mention breaking a longstanding tradition with the original Netscape. 
Which is what, in FreeBSD terms, we call breaking POLA, the Principle Of Least
Astonishment.

The file dialog box is not presented for nothing, you can select the directory
to save to and, 'lo and behold, change the filename.

What is blocking this to be changed back to the way it was?
*** Bug 117661 has been marked as a duplicate of this bug. ***
This is very annoying when I accidentally hit enter (because I assume that it
will enter the filename) and then try to gunzip the file because I get a
filename extension error (that is, it doesn't say ".gz" on the end.)

Also, whenever it brings up the file save box, (with the link text as the
default filename) the file filter says "All files (*.*) (*.*)" when it should be
"All files (*)" (as it is on links whose link text is the same as the filename.)
So what's making this so hard to fix? When I left click on a link, it brings up
the file save box with the name of the file as the default, how hard would it be
to copy that functionality into the save-as menu? It's this kind of bug that
makes IE about 10 times as usable for me (except for the fact that I'm under
Linux most of the time =)
*** Bug 117935 has been marked as a duplicate of this bug. ***
We are now at 12 duplicate bugs and 19 votes. What is the status really? Are we
waiting for more complains or is it already planned to go back to the old (and
good) behavior?
Feel free to contribute a fix.  Also, please don't comment unless you can help
fix this bug. 
Isn't the obvious fix to go back to the way things where before?
You mean completely back out "save complete page"?  Sure, that would fix this 
bug....  Not a useful approach, though.

Right now, we call saveURL() with the suggested filename being the link text.  
Then saveURL passes the suggested name on to getDefaultFileName() in 
contentAreaUtils.js.

This function will use the caller-provided name before evn bothering to look at 
things like HTTP headers and the like... This seems wrong to me.  At the very 
least, there should be two caller-provided names -- a suggested name and an 
override name.  Right now we only have override, so if the caller wants to 
suggest a name that name is used, period.  In reality, the caller wants to 
suggest a name here, not force it.  This is the cause of the link text part of 
the bug.  Ben, are there any reasons callers would want to force a filename?

The <title> part is just us checking title before url, and this should be fairly 
simple to fix -- just rearrange the code in getDefaultFileName() a bit.
To all those complaining about this: Ben, the assignee for this bug, is on
vacation.  Please have a little patience.  If you're not willing to tolerate
bugs like this, you should be using a less recent shipping version or older
milestone build, not the bleeding edge.
*** Bug 118358 has been marked as a duplicate of this bug. ***
OK.  I'm going to take a stab at this come Monday...

One thing that bears discussion, though, is urls of the form:  
http://somewhere/file.cgi?query.  For these urls, should we use "file.cgi" as 
the filename?  Or should we not use the URL filename for urls that include a 
query string?  This would be a pretty simple refinement to make and may address 
some of the issues with the old behavior.

So my proposed order would be:

1. use the name suggested by the HTTP headers ("Content-Disposition"), or,
2. use the actual file name, if present and there is no query string, or,
3. use the caller-provided name, if any (e.g. text under a link), or,
4. use the document title, or,
5. use the hostname.

Thoughts?
I think comment 60 is fairly reasonable... though no automated sequence will
ever quite capture "common-sense" with regard to reasonable filenames.  There's
a whole range of sites using some dynamically-generated scheme or other, with or
without URL parameters, including documents generated by POST requests that have
no parameter string but still have an un-meaningful name in the URL, as well as
documents with meaningful URL filenames but with parameters appended (e.g., to
track sessions without requiring cookies).

If, for instance, the URL is
http://www.somesite.example/cgi-bin/do-something.pl
with a POSTed value actually indicating what the script does, then the URL
filename isn't very meaningful and ought to be replaced by something else as the
default save name.

On the other hand, a URL like
http://www.somesite.example/marketing/products.asp?session=abc123
has a meaningful name "products" in there, though the .asp extension might not
be the best thing to save it under.

This can get pretty tricky to untangle.  Usually, the presence of "cgi-bin",
".cgi", or ".pl" in the URL gives an indication that its name is probably not
worthy of saving, ".html" or ".htm" indicates a name that probably should be
preserved, and ".asp" (and a few others like that) indicate a possibly
meaningful name, but the extension should change to ".html" on saving (if the
MIME type is text/html).  Other extensions like .exe and .zip indicate filenames
that should be preserved if the data content type matches the extension, but
otherwise could just indicate CGI programs at the server side irrelevant upon
download.

Now it's getting pretty hairy...
In response to comment 60: I think for URIs with query strings, you should strip
off the query and save it with that filename (without the path and without the
query).

That's what other browsers seems to do. Otherwise I agree with your proposal;
thanks for looking into this bug.
It might be best to have a choice.  If I do File -> Save as on this bug
page, I get "show_bug.cgi.html" - not a bad default, but perhaps not the
most useful.  It would be cool to have a choice via a pull-down or
something between that, show_bug.cgi_id=115176.html (which might be
best), or even the <title> text as another choice.  

I would like to see this bug fixed first, in the simplest way, and 
then clever bits added afterwards.  The key issue is with "Save Link
as...", where the text of the link is very inappropriate.
I agree with Andrew. Right now we have a discussion about finding the perfect
solution. But there will never be a perfect solution for everybody. So this
discussion will last for weeks and months.
For me Mozilla is not usable with saving link-names like "Mirror.exe",
"Download.exe", "Server 2" or similar. I always have to retype the correct
names. Luckily I can copy the filename of such links by "Copy Link Adress" in my
download manager which saves the files with their names. Otherwise I would turn
to another browser as soon as possible as this behaviour of Mozilla makes it
almost unusable.
This bug (yes, it is a BUG, not a feature) must be removed!
If I have a direct link to a zip, exe or any kind of file I want its filename in
my "Save file as"-box. Might be worth discussing about guessing file-names in
case of a "show_bug.cgi" but please not, if the author of a website gives his
file a name!
So please stop discussing about the best solution for several cases, but find a
solution for direct links with a given filename!

Well, I would not try to go into some "magic" in discovering if the filename is
worth preserving or not, like comment #61 suggested.

If the user right clicks on a link and selects "Save Link As", Mozilla should
try to get the filename in the following order:

a) Use Content-Disposition header entry
b) If link does a redirect (like
http://digitalprojects.com/dl.php3?d=rpm&r=http%3A%2F%2Frpm.digitalprojects.com%2F&f=files%2Ficewm%2Ficewm-1.0.6-4.src.rpm
from http://rpm.digitalprojects.com/indexvar.php?dir=icewm does), restart at a)
c) Use "actual filename" (What's that anyway?).  With this, *I* mean, Mozilla
should strip everything before (and including) the last /.  Query string should
be preserved, if present.  Suppose there's a picture gallery with links
"picture.php?id=1", "picture.php?id=2"....  In this case, if the query string
(eg· everything after a ?) is stripped, saving is only possible for the very
first link.  Mozilla should *not* add any/change any file type suffixes.
d) If link points directly to a domain (e.g. http://mozilla.org), Mozilla should
use the hostname and append a .html

In comment #60, I'd delete case 3: "use the caller-provided name, if any (e.g.
text under a link)", because my cases c) & d) cover everything.  I'd also not do
#60's case 4: "use the document title".  This is appropriate when doing a
File->Save As, but not in the Right Click->Save Link As case.
No one is suggesting we use the document title for "save link as".  That only 
applies for "save as".  This bug covers both...
Boris, everyone: Please, this bug is for backing out using the text for save
link as. Make it work exactly as 'Save page as' and 'Save frame as' do, and THEN
we can file a bug to discuss what to do with the <title> or text (I like my
button in the save dialog idea), or with query strings (FWIW, wget saves the
whole file?query).

Whatever is done there, it must work for any save method. Shift click, main
menus, context menus, left click, frames, links, pages, everything.
"Save page as" and "save link as" and "save frame as" will all do similar things 
with my proposed patch.  The only way to get a _different_ save behavior will be 
to shift-click on a link and pick "save" from the helper app dialog.  That uses 
a completely different code path that's completely unrelated to this bug and to 
the changes Ben made.  Please file a separate bug on making it use the same code 
path....
If you're changing them all, then your order needs more discussion. 3 and 4
would never occur together. Using the link text/page title should be defered
until it's selectable behavior, ie, by a button in the save dialog. Here's what
I'd like to see. These are for Save page as, or saving a link, or anything else:

http://mozilla.org/access/foo.html
Default name: foo.html

http://mozilla.org/access/
Default name: access.html (so much more useful then index.html)

http://mozilla.org/
Default name: mozilla.org.html (again, much more useful then index.html) 

http://mozilla.org/show_bug.cgi?id=115176
Default name: show_bug.cgi?id=115176.html or show_bug.cgi.html (there's a case
for both, I don't really care one way or the other... I'll just be happy if save
is somewhat consistent finally, but I'll believe THAT when I see it.)

Your order is fairly dumb. No offense, as it's largely a cut&paste from Ben's
order, as transcribed by sairuh. Some of the elements don't apply to
pages/links/frames, so it's fairly useless to order link text above
content-disposition text, etc, as you never have both.

Links: all we know is the file name, so use the above examples... query -> file
-> directory -> host.

Page/Frame: these should be the save, technically, just a differant interface to
them. Use Content-disposition if we have it, otherwise name as in the above
examples.

Yes, this means link text/page title saving are completely gone. Until we can
give them proper UI, they shouldn't be used. No matter what "order" you use,
link text or page title in many cases is going to be VERY innapropriate, which
is why this bug was originally filed. Many domains with hundreds of pages have
the same generic <title> for every one. And lots of link text is poor
hyperlinking... 'download', 'mirror', etc, as discussed here.
> 3 and 4 would never occur together
Correct.  The two strings are never both set in the code.  Relevance?

> http://mozilla.org/access/
> Default name: access.html 
We don't currently (including before Ben's changes) do this and there is no way 
to do it easily...  Please file a separate bug on this.

> http://mozilla.org/
> Default name: mozilla.org.html
That's item #5.

> so it's fairly useless to order link text above content-disposition text 
Link text is below content-disposition, and you do get both, I think (see 
below).  If you don't get content-disposition, we just fall through to URI text. 
All I plan to touch is the getDefaultFileName() function.   This is a generic 
utility function that takes all the data we have and comes up with a filename.  
If some of the data is missing, that part of the ordering is irrelevant.

> Links: all we know is the file name
We grab the HTTP headers and sniff them, if I understand correctly.

So.  We seem to agree on items #1 and #2 (from my list).  You want a better item 
#5.  You want to punt items #3 and #4 because a better item #5 would make them 
pointless.  Fact is, until #5 is done the way you suggest it's better to have 
the title or link text than just the hostname for every url ending with a 
"/"....
Re comment 69, I'm against using filenames like "show_bug.cgi?id=115176.html",
as I don't like putting "problematic" characters like question marks into
filenames. Depending on the operating system, characters other than your basic
letters, numbers, dashes, and underscores may be delimiters, wildcard
characters, etc., and could cause problems when you try to use them.

And regarding sites using the same title on lots of pages, and using poor link
text (like "Click Here"), the "devil's advocate" side of me says that maybe
Mozilla *should* add features that use those things in ways that would make
sense if web developers used those elements cluefully, but would show off the
dumb-ass-ness of the thoughtless uses that are rampant these days, in order to
try to shame the developers into putting more care into their titles and link
text (the mindless replication of title attributes instead of using reasonable
ones for each page is a particular pet peeve of mine).  However, unfortunately,
Mozilla lacks sufficient clout at the moment to have that effect on developers,
and besides, titles and link text are full of the "funny characters" I object to
in filenames, so you're best off not using them anyway.

See my page trying to get developers to use more sensible titles:
http://www.dantobias.com/webtips/titles.html

Re: Comment #69

Don't forget to check the Content-type instead of blindly appending .html to the
filename. This is relevant in case of a CGI program that outputs an image.
Imagine your parents' surprise when they save it as HTML and try to view it
later with a browser that relies on the file extension...
Ok.  One more time.  This bug is for reverting the behavior to using the 
filename by default if it exists.  Please file separate bugs for the "no 
filename" behavior, for changes to handle POST and GET requests, to do 
correct extension handling (this one is already filed) and so forth.
These are the problems that I have: (build 2002010621) (linux)

1. Click on (non-renderable) link: (eg, .tar.gz)
   -> file save as dialog box
   -> correct file name, correct extension, correct content-type
   -> saves the file correctly (no uncompression, changing of extension, etc)

2. Shift+Click on a link
   -> file save as dialog box
   -> file type == (eg)
          Web Page, HTML only (*.htm,*.html)(*.htm,*.html)
      or  All files (*.*)(*.*)
   -> file name is correct as on server
   -> extension added based on content type  (should not be default)
      so, file.shtml becomes file.shtml.html
   -> if gzipped file is saved, it is ungzipped, but extension is still .gz

3. Right-Click, Save Link As
   -> file save as dialog box
   -> file name is text of link
   -> File type is as in Shift+Click case
   -> File extension is replaced
      file.shtml becomes file.html
   -> gzipped files are ungzipped, but extension isn't changed

4. File menu | Save Page As
   -> file save as dialog box
   -> file name from url
   -> file extension added (file.shtml becomes file.shtml.html)
   -> file type - two options
      Web Page, Complete (*.htm,*.html)(*.htm,*.html)
      Web Page, HTML only (*.htm,*.html)(*.htm,*.html)
   -> Regardless of which is selected, it always saves Web Page, Complete
   -> Even if I change the file extension in the save as dialog box, it still     
      saves with the extension it wants to save as.
   
*** Bug 118582 has been marked as a duplicate of this bug. ***
Attached patch Proposed patch (obsolete) — Splinter Review
Shunting to 1.1, P4. I'm not convinced this is a bug worth fixing, the current 
behaviour is as-intended. However, I'd be interested to see if usability 
testing proves it is a disadvantage.
Status: NEW → ASSIGNED
Priority: P2 → P4
Target Milestone: --- → mozilla1.1
24 votes, 14 duplicates, a zillion comments, and a patch, but "Shunting to 1.1,
P4. I'm not convinced this is a bug worth fixing"

Someone isn't listening to their users...
> the current behaviour is as-intended

The current behaviour is incredibly inconsistent. Why was that intended?

The spec was obviously scrapped, as "Save Page As..." used to use <title>, but
that was backed out. Back this out to, until there is a pref, or a button in the
save dialog to change the name to the link text or page title.

Shift+click should never give different results then 'Save Link As...' in the
link context menu. This applies to file names, and the gzip content encoding
issue NS4 suffered from for all those years, which Moz still runs into.

Haven't enough people complained here about the awful effects this is giving?
As far as I'm concerned, this is the #1 worst bug in Mozilla, and I will 
be using 0.9.6 until it is fixed.  The "Save page as, complete"
feature is quite clever, and I could imagine it coming in handy, but 
compared to "Save link as" being practically unusable I can live without
it for ever.
I'm not quite as extreme as comment 80, but the current behavior is rather
inconsistent and often annoying... I vote to fix it, too, perhaps with the
current proposed patch.
I think usability testing is mostly needed to demonstrate the desirability of
making a change to such a long-standing default behavior, not for changing it
back.    I also don't understand why we'd delay and deprioritize a bug that has
a patch.  Is the patch viable?  cc lori for UE input.  This bug is still
nominated for nsbeta1, and will be triaged again.
I completely agree with comments #78 and #80.  This bug makes Mozilla unusable
for everyday use.  Even if the current behaviour was intended, it was a *bad*
intension.

Honestly, with so many comments and votes, why not change it back to the way it
was before?  Anyway, what was added by this bug?  I frankly do not know, which
means that only something was added which *I* never use and thus could care less
if it got lost again.
Hi

I've just upgraded from a previous build without this Problem and ran into these
problems very quickly.
Imagine a page (In my case it was very much this case) with lets say 10 ZIP
files with learning material of a friend.
All links are displayed as  "link"  and the description not in the <a>-Tag.
Those files would all get saved as "link" and not as "file1.zip", "file2.zip"
etc how I would need it! Please, please go back to whatever it was before
because that worked and now it's unusable!

Thanks

Matti
Matti> Please, please go back to whatever it was before
Matti> because that worked and now it's unusable!

There's your usability testing!

Isn't it possible to have both the old way and the new way available in the
context menu?
This is a bug with "major" severity, a bug with data loss-like behavior, and yet
it must be put off until 1.1? Is there a simpler or more expasperating bug
anywhere to be found in Bugzilla?

Do not be fooled by all the irrelevant comments on this bug. This bug is only
one thing. Every other thing talked about in this bug should be moved to the
newsgroups or to other bugs.

Actual behavior: "Save Link As" offers, as the default filename to be saved, not
the linked-to filename, but some other filename.

Expected behavior: "Save Link As" offers, as the default filename to be saved,
the linked-to filename.

This should be fixed ASAP because it makes Mozilla difficult to use when
downloading files.
> Actual behavior: "Save Link As" offers, as the default filename to be saved, not
> the linked-to filename, but some other filename.
> 
> Expected behavior: "Save Link As" offers, as the default filename to be saved,
> the linked-to filename.
  ^^^^^^^^^^^^^^^^^^^^^^

The substring of the downloaded ressource's URI that follows the last string, if
this substring doesn't contain a query string (i.e. a question mark and some
parameters following it).

Question: Isn't there a MIME header to specify the filename
(Content-Disposition?)? If so, is it supported?
As a Perl and CGI programmer, I think it's a good idea for the
Content-disposition header (or another header that specifies a filename), to
override the default filename from the URI/URL. A CGI (or similar server-side)
program can then modify that header to include some details found in the query
string, like e.g.:

showthing.cgi?id=3 => Content-disposition: thing-3.html

This seems like a good idea to me, but I don't think it's in wide use at the moment.

This way, if someone sees an index page with lots of links to
showthing.cgi?id=[0-9]+, they can save all the links with sensible filenames.

In case the Content-type were to conflict with the extension given in the
Content-disposition header, Mozilla could append its own extension to the
filename, that would make sense.
> it's a good idea for the Content-disposition header

While it probably is a good idea to use it, for shift-click and "Save Link
As...", Mozilla (nor Netscape 4, nor IE) does not retrive the headers first.
Doing so creates a whole slew of other problems. If I create a link to a server
which is fairly lagged, or has slow DNS, Mozilla can't create the save dialog
(as it doesn't know what name to use) until:
  1: DNS lookup is complete (could take MINUTES)
  2: TCP connection established (more MINUTES)
  3: HTTP response recieved (HTTP timeout post TCP connect unknown to me,
     potentially more MINUTES)

Even if we don't approach the timeouts, for many sites, the above is still a few
seconds, which makes save appear very slow. High cost, small benefit
(content-disposition filename isn't exactly common, and the on-server filename
is /useable/, if not perfectly ideal).

The downside is of course, you get the save dialog immediatly, spend time
picking where to save the file, and it could turn out to not even be available.

The other way to do this is to not prompt for a filename until the download is
complete, which causes other, worse problems... mainly, where to store it in the
meantime. (No, don't bother suggesting places, it's not as easy as you might think).

May I propose netscape.public.mozilla.bug115176?
Ok.  Please stop commenting on this bug unless you have read my comments,
trudelle's comments, Ben's comments, and the attached patch.  The attached patch
just gives Content-Disposition and the server-side filename higher priority than
the other methods of finding a filename.  It fixes the regression aspect of this
bug.  Requests for enhancement past that (these would also be requests for
enhancement from the old behavior) should be taken to new bugs or better yet a
newsgroup discussion.
Comment on attachment 63884 [details] [diff] [review]
Proposed patch

r=hwaara
Attachment #63884 - Flags: review+
Regarding comment #89:
While this is surely true, I wonder why Opera doesn't have a problem doing this?
 Yes, different browser, but if they can do it, why can't Mozilla?
> > it's a good idea for the Content-disposition header
> 
> While it probably is a good idea to use it, for shift-click and "Save Link
> As...", Mozilla (nor Netscape 4, nor IE) does not retrive the headers first

Well, then redirect scripts which redirect to an URL containing a filename would
cause the name of the script to be taken.

Not a very good idea ...
Comment #89 is wrong. We do fetch the headers on save link and we do use the
Content-Disposition header for save link.

All of which is _not_relevant_to_this_bug_.
*** Bug 118826 has been marked as a duplicate of this bug. ***
*** Bug 118808 has been marked as a duplicate of this bug. ***
*** Bug 119028 has been marked as a duplicate of this bug. ***
Actually, it's even worse. What you see below actually happened, and is the
reason I just now created a bugzilla account. Using milestone 0.97 for Solaris,
by the way.

1. Do a 'save as' on the link to a perl-script or shell-script, e.g.
http://www.carumba.com/talk/imap/ and then the 'createIMAPDir' link.
2. The proposed file name is 'createIMAPDir.txt which is wrong. As I don't want
it to be a .txt file, I removed the .txt and pressed Enter.
3. Because mozilla decides that the file is a textfile, it didn't show me any
other files. Now it turns out that the file 'createIMAPDir' already happens to
exist, which I could not see earlier.
4. '/export/home/paul/createIMAPDIR: File already exists: Do you want to replace
it?' I clicked OK
5. The file that actually gets written to disk is createIMAPDir.txt, as shown in
the progress-indicator as well.

So while checking whether the file exists it does know I changed the filename,
and correctly detects that the filename is already in use. But then when writing
 it to disk, it adds on the extension once again.

Actually, in case the extension-less file ("createIMAPDir") does not exist, the
behaviour is even worse: because it checks for "createIMAPDir" and then
overwrites "createIMAPDir.txt", without asking whether to replace this existing
file.
This can cause unexpected DATA LOSS and I would like to suggest to change the
status and urgency of this bug to be adjusted to reflect this.

Apart from that I would like to say that tacking on extensions onto filenames
seems an utter microsoftism. To Unix systems, an extension is just another part
of the filename. 
And also, the 'save as' dialog will only show you the files that have the same
imagined 'extension', not the other files, and unlike MS products, does not even
allow you to change that selection to "show all files".
Please, note that bug 119028 has been marked as a duplicate of this bug, and the
description does not match. Bug 119028 is about mozilla having problems with the
ª I think.
Probably set-up a new bug for showing the "all files (*.*)" in the dialog?
the extension crap is bug 116951 combined with bug 117269.
*** Bug 119233 has been marked as a duplicate of this bug. ***
*** Bug 119422 has been marked as a duplicate of this bug. ***
The first time I seen this one, I could believe it.. I went to save a .pdf file,
and it wanted to download using the link name, which didn't have the file
extension .. it was really annoying.  Their should be 'save link as... filename'
 or 'save link as... link name' options in the context menus.  Saving the link
in the case of saving the webpage is very useful, just not when the link name is
a valid file extention other than .htm, .html, .shtml, and .other valid
webdocument extensions.
Any Reason this is targetted toware Mozilla 1.1 as apposed to 0.9.8 or 0.9.9
even ? This is a highly visable bug.
*** Bug 119943 has been marked as a duplicate of this bug. ***
21 duplicates in one month! May I propose adding the fixitnoworburninhellforever
keyword?
This has a patch, it has severity 'major', and it is really annoying. So why is
is marked for 1.1? It is also a data loss. If you don't think this is a data
loss bug, try heading over to comp.compression and explaining to them that you
have a compression algorithm that can compress arbitrary data to zero length by
storiing the data in base64 in the filename. This is perfect compression,
because the name of the file is not part of the data, right?
You could argue that the data isn't lost, because the user still has the name
available to him/her and can retype it. I guess that means that it is
accceptable to save text files by creating an empty file. This isn't data loss,
because the user can retype the contents of the file, right?
I never thought I would nominate a bug for the next milestone only two days
before the freeze, but adding mozilla0.9.8 keyword. I'm also going to mail
drivers@mozilla.org proposing this bug as a bug 115520 blocker.
Keywords: mozilla0.9.8
*** Bug 119971 has been marked as a duplicate of this bug. ***
Content-disposition should trump all else -- ben@netscape.com agrees, and this
regression will be fixed for 0.9.8.

I prefer that server filename trump title-with-suffix-magically-appended if
there is no content disposition.  Can we have that battle after 0.9.8?

/be
Attached patch patchSplinter Review
This is what I'm willing to take at this point ;)

a) this makes content-disposition win over everything, if its specified
b) for Save Page As, this continues to use the document title
c) for links, it uses the file name
Attachment #63884 - Attachment is obsolete: true
Comment on attachment 64921 [details] [diff] [review]
patch

r=blake
Attachment #64921 - Flags: review+
Re attachment 64921 [details] [diff] [review] and comment 112: Wait a minute... you can't "continue to use
the document title" for Save Page As, since current builds, as far as I'm aware,
use the URL filename in preference to the document title -- that change was made
a while back, and was a good one as far as I'm concerned.  This patch would be a
reversion in that respect.
*** Bug 120140 has been marked as a duplicate of this bug. ***
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Definitely not fixed. I'm using 2002011508 - linux
Visit http://www.phial.com/angband/auto.html
Click File|Save Page As

Expected result:
File Name: auto.html

Actual result:
File Name: Angband -- Borg

Doesn't look fixed to me.
check the date of your build:

2002011508 - 15 January, 2002, 8am

compare that to the time I marked this bug fixed:

15 January, 2002, 11pm. 

*** Bug 120262 has been marked as a duplicate of this bug. ***
OS X 10.1.2/2002011608, "Save Link As" seems to work for me in the general case
of "Save Link As" with the "MacOS X" nightly download link on the mozilla.org
homepage.

But then I noticed that if I use Save Link As on the "Format For Printing" link
on this Bugzilla page (http://bugzilla.mozilla.org/show_bug.cgi?id=115176), it
wants to save with a file name of "filename=bugzilla_bug_list.html" (the .html
may have been added by OS X specific mime-type handling stuff).

Could the extra "filename=" be a problem with the implementation of
Content-dispostion handling?
*** Bug 120321 has been marked as a duplicate of this bug. ***
*** Bug 120399 has been marked as a duplicate of this bug. ***
bug 120409 filed (with patch) on the issue Bruce noted in comment #121.
*** Bug 120524 has been marked as a duplicate of this bug. ***
*** Bug 120772 has been marked as a duplicate of this bug. ***
*** Bug 121406 has been marked as a duplicate of this bug. ***
Remark to the additional comment #3 - filename for page generated by CGI:
Adam, it depends on CGI script/program. Most of the time they don't specify
filename, so the browser shall use the name of CGI application itself
( sdfsd%20fsdf.dll in your example ). However, it's possible to force a
filename for generated document by putting following string into HTTP-header :
Content-Displacement: filename="desired name.html"
For index files "index.html" is just fine for me...
> Content-Displacement: filename="desired name.html"

You mean 

Content-disposition: inline; filename="desired name.html"

right?  What you said is not only bogus, it's not valid HTTP header syntax.

tested using 2002.01.23.0x comm verif bits on linux rh7.2, win2k and mac 10.1.2
with the scenarios below:

a. Use document title:
Save Page As [eg, accel+S] for http://mozilla.org/ --note that this url doesn't
not specify the filename index.html. therefore the expected suggested filename
would be "mozilla.org.html", based on the page's title, "mozilla.org". and this
is the actual result i get.

b. Use actual filename, if present in url:
Save Link [context menu] for a link where a filename is specified. eg, the
"Roadmap" link on http://mozilla.org points to http://mozilla.org/roadmap.html.
the expected result would be to suggest the actual filename, "roadmap.html". the
actual result matches this as well.

c. Use caller-provided name, such as the link content:
Save Link [context menu] for a link where a filename is not specified. eg, the
"Developer Docs" link on http://mozilla.org, which points to the url
http://mozilla.org/docs/ . the expected suggested filename would be "Developer
Docs.html" --again, the actual results matches this.

d. Use the host name:
if there's no title, then the host name should be used. i tested this by
removing the title element for http://hopey.mcom.com/ . sure enough, when using
accel+S the actual [and expected] suggested filename was "hopey.mcom.com.html".

e. Use the name suggested by the HTTP headers. could someone pls send me a
sample URL that would use this? thanks!

bz, would a valid meta tag (for, say, a test file) be <meta
http-equiv="content-disposition" 
content="inline; filename='name_me_this_way.html'"> ? if yes, then my test
exposes a potential bug. if not...a good/valid sample url would be cool. :)
b is wrong. Expected is "mozilla.org.html", but based on the URL, not <title>.
c is awful. Expected is "docs.html".

Many sites use:

www.foo.com/bar/

as a matter of nicer style over:

www.foo.com/bar.html

Both of these very similar URLs should use the file name. Currently, they use
***COMPLETELY*** seperate mechanisms, which is ***NOT*** expected. Most
definately not.

There is also another major problem. On a directory listing on my site, eg:
http://turbogeek.org/code/

Save Page As tries to name the file 'turbogeek.org.html'. 4.x would name it
index.html. What's expected is code.html.
jeremy, your comment confuses me. are my tests wrong or are the behaviors wrong
or both?

as the QA here, i'd like a clearer understanding of testing this issue. if your
comments are already covered by other bugs, that's cool. but i just don't want
to waste time testing things the wrong way!
ah, i see bug 118621 for the http://foo.com/bar/ -> save as bar.html case.
[correct me if i'm looking at the wrong bug.]

chatted w/ben. other than trying to find a site that would serve up content
covering case (e), i'm marking this verified. [i'll still welcome a sample for
that test, however :)]
Status: RESOLVED → VERIFIED
thanks to tever and jrgm, i have a test for (e) at
http://hopey.mcom.com/tests/content-disp.html --and Save As works!
Good question about the <meta> tag... if we're saving the doc, we don't really
parse it so we have no knowledge of HTTP headers set via <meta> tags.  One of
the many weaknesses of the <meta http-equiv=""> setup.  That should be a
separate bug, one that will likely involve painful architecture changes...
Attempting to add support for META information contained within the HTML markup,
rather than or in addtion to the HTTP response headers, is both completely
unneccessary and  highly problematic. 

According to the W3:

<http://www.w3.org/TR/html4/struct/global.html#meta-data>

"User agents are not required to support meta data mechanisms. For those that
choose to support meta data, this specification does not define how meta data
should be interpreted."

Further: 

"The META element : Attribute definitions

http-equiv = name [CI]
This attribute may be used in place of the name attribute. HTTP servers use this
attribute to gather information for HTTP response message headers."

In other words, if the HTTP server is configured to do so, it may choose to
honor the "META http-equiv" attribute when forming proper HTTP response headers.
 Control over this is (properly) in the hands of the document author and the web
server admin.  The user agent is then expected to act on the basis of these HTTP
headers, not the information embedded in the HTML markup. 

Additionally, even if it were judged as desirable to examine and act upon HTML
META information, there are huge problems with actually doing so.  In order for
this to work, the user-agent would have to retrieve and parse the entire HTML
document, rather than simply the HTTP repsonse headers.  In the case of using
this information for file naming, this retrieve and parse action would have to
occur *before* the File Save dialogue box was popped.  

I would conclude that file naming based on HTML META information is unneccesary,
unwise and unworkable.  



A test for (e) is right here on this bugzilla page.  The "Format For Printing"
link uses the Content-Disposition header, as I found out very quickly when I
randomly clicked on it for no logical reason and found bug 120409.
*** Bug 122368 has been marked as a duplicate of this bug. ***
Just checked with Google Pictures.  Behaviour is as expected, but could be better.

Go to google image search.  Enter anything.
Right click on one of the images.  In the context menu, a link that says Save
Image (xxxx.gif)   or whatever the correct file name is.

Click on that menu item.  File Save As dialog box.  Filename image.jpeg.  File
type: jpeg.

There are no other file types offered for selection.  If the filename was picked
correctly for the context menu, why can it not be picked correctly for the save as?

Should this be reopened for this?
ok, I guess that was my mistake.  The image is a jpeg.  This is really a bug
with the right-click context menu that shows the wrong filename (whatever is
after the last / in the url, even if it is part of the query string).
*** Bug 123298 has been marked as a duplicate of this bug. ***
Philip, not sure but here is a url for what you are talking about:

http://www.shacknews.com/screens.x/halo/Halo/3/thumbs/031201_halo_1.jpg

Anyone know if that problem is filed: save image context menu item, still pulls
up the script, and not the filename that is suggested in the context menu itself?
That would be because the context menu uses a different algorithm for parsing
the url to get the filename...  

Please file a new bug, cc me.
The site cited in comment 143 is a bit of a "degenerate case" for parsing
filenames out of URLs... they have some odd naming systems there.  For instance,
the URL cited ends in ".jpg" but is actually an HTML page -- fortunately, their
server has the sense to serve it with the correct MIME type, but it still
wouldn't surprise me all that much if MSIE had a cow about it given its infamous
MIME second-guessing.

The image in question does indeed have a script name as its filename, with the
image name being a parameter to it.  One can forgive a browser if it tries to
save the resulting file by the script name instead of the parameter.  However,
the behavior of showing one name in the context menu and another when you
actually save it is rather bizarre and ought to be made consistent (even if, on
some sites, that might result in it being consistently wrong).
When doing a "Save Page" or "Save Image" (not from the context menu)
when displaying URL
http://www.shacknews.com/images/image-o-matic.x?halo/031201_halo_3.jpg
it shows "image-o-matic.x" as the proposed filename. So its not just the
differemt algorithm of the context menu then?
Yes. It is.

The context menu shows "031201_halo_3.jpg".  Everything else shows
"image-o-matic.x" (all the save methods do).  That would be "just the
differemt [sic] algorithm of the context menu".
/me files bug 124680 about context menu using different parsing.. for comment
#143 thru comment #147.
*** Bug 134461 has been marked as a duplicate of this bug. ***
You may check this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=23207 
and assign it to this bug #115176.

As I described in my last comment in bug #23207, the solution would be very easy.
It's unnecessary to argue if we need <title> or original file name or other kind
of formats.
Let the user choose, which one he/she want as Save as... filename.

Solution:
We just need a downdrop menu in Save as window, where we list those file name
variants, what users would like. 

Example: on following page after clicking Save as:
http://www.codeweavers.com/technology/wine/download.php
In the downdrop menu, we could have the following names:
1) download.php.html
2) CodeWeavers - Technology - Wine - Download

The default file naming option should be configured in the Preferences.

If we think furthermore, we will see, we would be need something like a template
system for the filenames. I would recommend ASP-like template tags, like
<%this_is_a_tag%>. In the Preferences we could create filename templates, 
and we could add as many filename templates as we would like.

Some interesting predefined template tags could be added, like:
<%original%> - original file name (without extension)
<%Page_Title%> - full Page Title of the page we want to save (chars must be
converted to allowed filename chars)
<%ext%> - extension of original file name
<%yyyy%> - year (liek 2002)
<%mm%> - month (like 04)
<%dd%> - day (like 21)
<%TT%> - time hour (like 08)
<%MM%> - time minute (like 53)
For the time related tags, we could also use the standard C time formatting
characters like <%Y%> (like in strftime), to represent the year as decimal
number (for example: 1989), etc.

Some template format of the most common types, which was discussed in comments:
1) <%original%>.<%ext%>   => original file name format, what is used in Netscape
v4.x
2) <%Page_Title%>.html   => format used to save using page title in Internet
Explorer (CodeWeavers - Technology - Wine - Download.html if we use the example
URL used above)
3) <%Link_Text%>.html   => get text of link, if was clicked using Save Link
Target As...
4) <%Path_translated%>.html   => so saving from URL
http://www.codeweavers.com/technology/wine/download.php, would be translated to
www_codeweavers_com_technology_wine_download_php.html filename. The full URL, in
one name, but incorrect characters are converted to valid characters.
5) <%original%>_<%yyyy%>-<%mm%>-<%dd%>_<%HH%>-<%MM%>.html   => this will result
the format: filename_2002-06-12_16-46.html

Templates above can be added, deleted, modified in Preferences menu. One type of
them can be selected as default type by the user.
Now we have 5 file name types, so the user could select one of them in the Save
as... window, from the downdrop menu.

I hope this solution would solve the problem & will satisfy everybody's need.

Webmaster33
*** Bug 155997 has been marked as a duplicate of this bug. ***
Blocks: 158006
I have found MS-IE's behavior (of using page titles as the default filenames 
and embedding the page URLs in the saved files as a comment line) to be rather 
useful -- I often use it instead of bookmarking pages now, if the page is 
important (bookmarks don't work if the webpage disappears).  The original page 
filename is quite useless when saving pages, from say, eBay...

I *NEED* to have the page saving feature behave like it does in MS-IE.  
Because of this (and ONLY because of this), I am *FORCED* to continue using MS-
IE.  Can't you folks make any sort of option to toggle this?  Even just a line 
in prefs.js !!!

Thanks in advance...

Alex
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
It seems that there are always situations where any of the choices that might
have been preset yield undesirable results. So the only way to deal with this
in a flexible and user friendly way would be to let the user switch the 
presented default filename at the time the filepicker is shown.
This would probably be possible with the XP filepicker but I doubt it to work
with native filepickers like for windows. 
A UI element I could imagine for this would be a small icon in  front of the
filename entry box that explains its function as a tooltip: switching between
different default filenames for the object to be saved.
Per Comment #90 From Boris Zbarsky  2002-01-08 10:46
Requests for enhancement past the original bug should be taken to new bugs or
better yet a newsgroup discussion.

ben@netscape.com  2002-01-15 23:08:57
Status  ASSIGNED  RESOLVED
Resolution   FIXED
Status: REOPENED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
Comment #134 sairuh@netscape.com  2002-01-23 17:44:53
Status  RESOLVED  VERIFIED
Status: RESOLVED → VERIFIED
Whiteboard: [DO NOT REOPEN]
I posted to the netscape.public.mozilla.ui newsgroup long ago, see:

news://news.mozilla.org:119/ale6bb$rd43@ripley.netscape.com

...it was ignored.


It is NOT an enhancement really, because apparently an earlier version was 
saving the pages with page titles as filenames -- can't someone just made an 
option to toggle between both types of code, and have it stick the URL in the 
file as a comment when saving with the page title as the filename?  ...it 
SEEMS easy enough.
Please take discussion and bug fixes :) to bug 173982 which I have opened for
this kind of enhancement.
> and have it stick the URL in the file as a comment

Totally unrelated to this bug (totally separate code).

> it SEEMS easy enough.

Perhaps the fact that no one has done it while people (like yourself) want it
done should be an indicator that that may not be true?  ;)
Most of the arguments here seem focused on saved *links* and links to *files*. I agree that saved links should have the URL's name (e.g., ferrari.com.testarossa.specs.html - not just "specs.html"!) and files should have the file's name (Firefox3_win_en.exe). 

However, many "mainstream" users often just want to save a web page to their computer (e.g., print view of recipes at http://www.foodnetwork.com). For these common cases, Firefox fails miserably. Instead of offering the sensible and useful "Food Network: Chicken Piccata.html", Firefox offers the useless "0,1946,FOOD_9936_73748_PRINT-RECIPE-FULL-PAGE,00.html".

Fortunately, there is an add-on for those savvy enough, called "File Title", but most users will never find it, let alone bother installing something that should be there anyhow - especially since IE does this right already. I lost a potential convert yesterday for exactly this deficiency in Firefox.

Please back out the changes for "Save Page As" = <title>.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: