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)
Core Graveyard
File Handling
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)
1.49 KB,
patch
|
bugzilla
:
review+
brendan
:
superreview+
|
Details | Diff | Splinter Review |
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"
Reporter | ||
Updated•23 years ago
|
Keywords: regression
Comment 1•23 years ago
|
||
*** Bug 115080 has been marked as a duplicate of this bug. ***
Comment 2•23 years ago
|
||
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
Reporter | ||
Comment 4•23 years ago
|
||
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
Comment 5•23 years ago
|
||
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>
Comment 6•23 years ago
|
||
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. ***
Comment 8•23 years ago
|
||
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".
Comment 9•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
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.
Comment 11•23 years ago
|
||
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.
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
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.
Comment 14•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
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.
Comment 16•23 years ago
|
||
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.
Comment 17•23 years ago
|
||
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.
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
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.
Comment 20•23 years ago
|
||
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."
Comment 21•23 years ago
|
||
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.
Comment 22•23 years ago
|
||
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.
Comment 23•23 years ago
|
||
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 :(
Comment 24•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
*** Bug 116353 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
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.
Comment 28•23 years ago
|
||
*** Bug 116506 has been marked as a duplicate of this bug. ***
Comment 29•23 years ago
|
||
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?
Comment 30•23 years ago
|
||
*** Bug 116557 has been marked as a duplicate of this bug. ***
Comment 31•23 years ago
|
||
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.
Comment 32•23 years ago
|
||
>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.
Comment 33•23 years ago
|
||
*** Bug 116671 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
'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
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
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.
Comment 37•23 years ago
|
||
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.
Comment 38•23 years ago
|
||
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/)
Comment 39•23 years ago
|
||
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
Comment 40•23 years ago
|
||
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" ^
Comment 41•23 years ago
|
||
*** Bug 116833 has been marked as a duplicate of this bug. ***
Comment 42•23 years ago
|
||
*** Bug 116869 has been marked as a duplicate of this bug. ***
Comment 43•23 years ago
|
||
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.
Comment 44•23 years ago
|
||
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.
Comment 45•23 years ago
|
||
*** Bug 117282 has been marked as a duplicate of this bug. ***
Comment 46•23 years ago
|
||
*** Bug 117328 has been marked as a duplicate of this bug. ***
Comment 47•23 years ago
|
||
Oh, this makes saving auto-detected urls (eg from mail messages) a pain since the filename is the full url.
Comment 48•23 years ago
|
||
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.
Reporter | ||
Updated•23 years ago
|
Comment 49•23 years ago
|
||
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?
Comment 50•23 years ago
|
||
*** Bug 117661 has been marked as a duplicate of this bug. ***
Comment 51•23 years ago
|
||
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.)
Comment 52•23 years ago
|
||
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 =)
Comment 53•23 years ago
|
||
*** Bug 117935 has been marked as a duplicate of this bug. ***
Comment 54•23 years ago
|
||
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?
Comment 55•23 years ago
|
||
Feel free to contribute a fix. Also, please don't comment unless you can help fix this bug.
Comment 56•23 years ago
|
||
Isn't the obvious fix to go back to the way things where before?
Comment 57•23 years ago
|
||
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.
Comment 58•23 years ago
|
||
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.
Comment 59•23 years ago
|
||
*** Bug 118358 has been marked as a duplicate of this bug. ***
Comment 60•23 years ago
|
||
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?
Comment 61•23 years ago
|
||
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...
Comment 62•23 years ago
|
||
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.
Comment 63•23 years ago
|
||
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.
Comment 64•23 years ago
|
||
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!
Comment 65•23 years ago
|
||
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.
Comment 66•23 years ago
|
||
No one is suggesting we use the document title for "save link as". That only applies for "save as". This bug covers both...
Comment 67•23 years ago
|
||
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.
Comment 68•23 years ago
|
||
"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....
Comment 69•23 years ago
|
||
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.
Comment 70•23 years ago
|
||
> 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 "/"....
Comment 71•23 years ago
|
||
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
Comment 72•23 years ago
|
||
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...
Comment 73•23 years ago
|
||
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.
Comment 74•23 years ago
|
||
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.
Comment 75•23 years ago
|
||
*** Bug 118582 has been marked as a duplicate of this bug. ***
Comment 76•23 years ago
|
||
Assignee | ||
Comment 77•23 years ago
|
||
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
Comment 78•23 years ago
|
||
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...
Comment 79•23 years ago
|
||
> 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?
Comment 80•23 years ago
|
||
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.
Comment 81•23 years ago
|
||
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.
Comment 82•23 years ago
|
||
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.
Comment 83•23 years ago
|
||
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.
Comment 84•23 years ago
|
||
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
Comment 85•23 years ago
|
||
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?
Comment 86•23 years ago
|
||
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.
Comment 87•23 years ago
|
||
> 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?
Comment 88•23 years ago
|
||
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.
Comment 89•23 years ago
|
||
> 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?
Comment 90•23 years ago
|
||
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 91•23 years ago
|
||
Comment on attachment 63884 [details] [diff] [review] Proposed patch r=hwaara
Attachment #63884 -
Flags: review+
Comment 92•23 years ago
|
||
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?
Comment 93•23 years ago
|
||
> > 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 94•23 years ago
|
||
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_.
Comment 95•23 years ago
|
||
*** Bug 118826 has been marked as a duplicate of this bug. ***
Comment 96•23 years ago
|
||
*** Bug 118808 has been marked as a duplicate of this bug. ***
Comment 97•23 years ago
|
||
*** Bug 119028 has been marked as a duplicate of this bug. ***
Comment 98•23 years ago
|
||
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".
Comment 99•23 years ago
|
||
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.
Comment 100•23 years ago
|
||
Probably set-up a new bug for showing the "all files (*.*)" in the dialog?
Comment 101•23 years ago
|
||
the extension crap is bug 116951 combined with bug 117269.
Comment 102•23 years ago
|
||
*** Bug 119233 has been marked as a duplicate of this bug. ***
Comment 103•23 years ago
|
||
*** Bug 119422 has been marked as a duplicate of this bug. ***
Comment 104•23 years ago
|
||
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.
Comment 105•23 years ago
|
||
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.
Comment 106•23 years ago
|
||
*** Bug 119943 has been marked as a duplicate of this bug. ***
Comment 107•23 years ago
|
||
21 duplicates in one month! May I propose adding the fixitnoworburninhellforever keyword?
Comment 108•23 years ago
|
||
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?
Comment 109•23 years ago
|
||
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
Comment 110•23 years ago
|
||
*** Bug 119971 has been marked as a duplicate of this bug. ***
Comment 111•23 years ago
|
||
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
Assignee | ||
Comment 112•23 years ago
|
||
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 113•23 years ago
|
||
Comment on attachment 64921 [details] [diff] [review] patch sr=brendan@mozilla.org
Attachment #64921 -
Flags: superreview+
Comment 114•23 years ago
|
||
Comment on attachment 64921 [details] [diff] [review] patch r=blake
Attachment #64921 -
Flags: review+
Comment 115•23 years ago
|
||
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.
Comment 116•23 years ago
|
||
*** Bug 120140 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 117•23 years ago
|
||
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 118•23 years ago
|
||
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.
Assignee | ||
Comment 119•23 years ago
|
||
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.
Comment 120•23 years ago
|
||
*** Bug 120262 has been marked as a duplicate of this bug. ***
Comment 121•23 years ago
|
||
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. ***
Comment 123•23 years ago
|
||
*** Bug 120399 has been marked as a duplicate of this bug. ***
Comment 124•23 years ago
|
||
bug 120409 filed (with patch) on the issue Bruce noted in comment #121.
Comment 125•23 years ago
|
||
*** Bug 120524 has been marked as a duplicate of this bug. ***
Comment 126•23 years ago
|
||
*** Bug 120772 has been marked as a duplicate of this bug. ***
Comment 127•23 years ago
|
||
*** Bug 121406 has been marked as a duplicate of this bug. ***
Comment 128•23 years ago
|
||
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...
Comment 129•23 years ago
|
||
> 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.
Reporter | ||
Comment 130•23 years ago
|
||
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!
Reporter | ||
Comment 131•23 years ago
|
||
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. :)
Comment 132•23 years ago
|
||
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.
Reporter | ||
Comment 133•23 years ago
|
||
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!
Reporter | ||
Comment 134•23 years ago
|
||
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
Reporter | ||
Comment 135•23 years ago
|
||
thanks to tever and jrgm, i have a test for (e) at http://hopey.mcom.com/tests/content-disp.html --and Save As works!
Comment 136•23 years ago
|
||
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...
Comment 137•23 years ago
|
||
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.
Comment 138•23 years ago
|
||
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.
Comment 139•23 years ago
|
||
*** Bug 122368 has been marked as a duplicate of this bug. ***
Comment 140•23 years ago
|
||
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?
Comment 141•23 years ago
|
||
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).
Comment 142•23 years ago
|
||
*** Bug 123298 has been marked as a duplicate of this bug. ***
Comment 143•22 years ago
|
||
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?
Comment 144•22 years ago
|
||
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.
Comment 145•22 years ago
|
||
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).
Comment 146•22 years ago
|
||
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?
Comment 147•22 years ago
|
||
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".
Comment 148•22 years ago
|
||
/me files bug 124680 about context menu using different parsing.. for comment #143 thru comment #147.
Comment 149•22 years ago
|
||
*** Bug 134461 has been marked as a duplicate of this bug. ***
Comment 150•22 years ago
|
||
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
Comment 151•22 years ago
|
||
*** Bug 155997 has been marked as a duplicate of this bug. ***
Comment 152•22 years ago
|
||
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 → ---
Comment 153•22 years ago
|
||
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.
Comment 154•22 years ago
|
||
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 ago → 22 years ago
Resolution: --- → FIXED
Comment 155•22 years ago
|
||
Comment #134 sairuh@netscape.com 2002-01-23 17:44:53 Status RESOLVED VERIFIED
Status: RESOLVED → VERIFIED
Whiteboard: [DO NOT REOPEN]
Comment 156•22 years ago
|
||
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.
Comment 157•22 years ago
|
||
Please take discussion and bug fixes :) to bug 173982 which I have opened for this kind of enhancement.
Comment 158•22 years ago
|
||
> 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? ;)
Comment 159•16 years ago
|
||
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>.
Updated•8 years ago
|
Product: Core → Core Graveyard
Comment hidden (spam) |
You need to log in
before you can comment on or make changes to this bug.
Description
•