Closed Bug 173982 Opened 23 years ago Closed 13 years ago

Allow different default file names when saving

Categories

(Core Graveyard :: File Handling, enhancement)

Product:
Core Graveyard
Component:
File Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: johann.petrak, Unassigned)

References

Details

Opened for the enhancement requests discussed in closed bug 115176: There should be a way in to switch between the different possible default filenames in the filepicker. The different default names are the title of the page, the file name in the link, the content-disposition filename of the HTTP header, and possibly others. The solution proposed here would be to have a small icon in front of the filename entry field that will switch between the different default names - the source of the default file name would be remembered for later saves.
This issue has been the subject of "holy wars" here... in one corner, there are people who are adamant that the one true correct filename to save as is the filename from the URL (generally, seasoned "computer geeks" favor this); in the other corner are those who think the obvious save filename is the page title (generally, newcomers more at home in a drag-and-drop graphical environment than a command line favor this). But whenever anybody suggests adding some sort of preference setting to allow both groups to get what they want, it gets roundly flamed by those who are dead-set against adding more settings and preferences to Mozilla, because it adds to the bloat of the program, increases difficulty in learning how to use it, and makes debugging harder. So it ends up with Mozilla having only one choice of default filename, which must be the One True Correct Choice according to whichever camp is dominant at the moment. I don't know how this logjam can ever be cleared up, but I for one favor Mozilla having a robust set of options and choices to allow it to be the browser that supports all different tastes and preferences, not a dumbed-down browser dragging everybody down to a lowest common denominator.
I agree - there are several ways how to pick the default filename and there are supporters for all of them. Since different browser use different methods, there are sites where one or the other method makes more sense. It also depends on the type of info and the structure of the site which method yields more resonable results (e.g. saving news articles from a cgi-bin site would need the title, saving tarballs would need the original filename), so there is no way how to deal with this using just one method. Fixing this with a preference has its drawbacks too: often one only realizes that the proposed filename is not what one wants when the save dialog comes up. For example, you prefer to save using the original filename, but now you are at a server that serves all files via cgi-bin script and you get "file.pl" for all files. As I said in the first comment, my suggestion therefore is to let the user choose between the different default values in the filepicker by a small button in front of the suggested filename that cycles through the different values. One could also imagine that the button would remember which default value source the user was last using or there is a global preference for that. I think that the complexity and added clutter of having a preference for that is by far outweighed by the benefits: one should not forget that there are many people who use a browser for saving quite often - so this is, apart from the viewing one of the core functions of the browser. Forcing either group of users to correct the default name because it does not match their preferences is just not acceptable IMO.
I personally would not mind even if the toggle existed ONLY in the prefs.js configuration file (I'm a 'seasoned computer geek' ...with about 15 years of experience). I recognize that it *IS* better to save files with their original filename whenever possible... UNLESS one is saving web pages from a site that is using cgi's to generate pages. For example, try saving any auction page from eBay -- you get "eBayISAPI.dll.html" as the filename every time (not very meaningful). Perhaps a better solution for this would be to add a save option under the "Bookmarks" menu? Like "File Page As" (to differentiate it from the "Save Page As"). So then users could do: "Bookmarks" -> "File Page As" ...and it would bring up a dialog similar to "Save Page As", but would behave like MS-IE -- by using the page title as the default filename, and adding the page's original URL in a comment line at the top of the saved page. This would allow everyone to totally avoid adding another configuration option, and would make everyone happy, wouldn't it? :-)
I also posted in the bug 115176 as Comment 150. I reworked a bit and I post it again here, since it seems nobody noticed the possibilities in this silution. I worked out a complete suggestion for the Save as ... file naming feature, and I feel it would be THE almost complete solution for the problem. 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, what he/she wants as Save as... filename, we just predefine some typical filenames for the user. Solution: We just need a downdrop menu in Save as window, where we list those file name variants, what users would mostly like (and/or was setup in the Preferences options). Of course the user could change these predefined filename types. The default file naming option should be also configured in the Preferences. If we think about the problem, 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 predefined filename template types as we would like. Some interesting predefined template tags could be added, like: - <%original%> - original file name (without extension) - <%ext%> - extension of original file name - <%Page_Title%> - full Page Title of the page we want to save (chars must be converted to allowed filename chars) - <%Link_Text%> - text on the link, which was clicked using e.g. Save Link Target As... - <%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 (incorrect characters are converted to valid characters). - <%counter%> - this will be a counter which will increase if there is already the same filename with numbering. E.g. <%original%>_<%counter%>.<%ext%>. So if we have file_2.zip, it will suggest file_3.zip. - <%yyyy%> - year (like 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 formats of the most common types, which was discussed: 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) <%original%>_<%yyyy%>-<%mm%>-<%dd%>_<%HH%>-<%MM%>.<%ext%> => this will result the format: filename_2002-06-12_16-46.html 5) If we have a cgi generated page (we have parameters in the URL, so at least a `?' character), the <%Page_Title%>.html can be suggested. Templates above can be added, deleted, modified in Preferences/Navigator/Save_as, or Preferences/Navigator/Downloads. One type of them can be selected as default type (<%original%>.<%ext%> could be the default type). Also we could assign default templates to several extensions, like <%Page_Title%>.html for the .cgi .pl .dll types. <%original%>.<%ext%> could be also assigned to .zip .tar .gz .rar .r?? .arj, etc. These predefined file name types, could be selected by the user from the downdrop menu in the Save as... window. 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 predefined names: 1) download.php.html (much better just download.html if possible) - (using template: <%original%>.<%ext%>) 2) CodeWeavers - Technology - Wine - Download.html - (using template: <%Page_Title%>.html) 3) screenshots.html - if we clicked using Save Link Target As... on the screenshots menu item - (using template: <%Link_Text%>.html) 4) download_2.html - if download.html already exists - (using template: <%original%>_<%counter%>.<%ext%>) 5) download_2002-10-14_10-46.html - (using template: <%original%>_<%yyyy%>-<%mm%>-<%dd%>_<%HH%>-<%MM%>.<%ext%>) The bottom line is: - we define several filename types, - we assign some template based filename types for several extensions, - user can furthermore choose from several predefined filenames. I not just hope, but I'm sure this solution would solve most filenaming problems and would satisfy almost everybody's needs, because it is as flexible and configurable as possible. Best regards, Webmaster33
Maybe, but that would be considerably harder to implement, would it not? I'm guessing that the reason why Boris Zbarsky was so hasty to mark bug 67901 as WONTFIX (for an interesting read, see: http://mpt.phrasewise.com/discuss/msgReader$198 ), is because the developers assigned to the File Handling module have come to the consensus that it now does what they want it to do, and they don't want to spend any more effort on it. Apparently none of them have discovered the usefulness of saving web pages to disk instead of bookmarking them. There are several issues that any change would have to deal with -- primarily, Netscape v4.xx (and earlier) users are used to having it use the original filename as the save-as filename -- thus the amount of complaints that using the page title was a bug exceeded the amount of complaints that using the original page filename was a bug. Hell, neither method is a bug. Unfortunately I think that disproportionate amount of complaints indicates that either Mozilla is not having much luck of winning over MS-IE users, or all MS-IE users are not competent enough to post here. Anyway, so the first issue is "user expectation". The next issue is convenience -- my earlier suggestion to use an option under the Bookmarks menu may not be so good, because the shortcut keys would be weird, for example: "Bookmarks" -> "File Page As" ...would probably be implemented as "&Bookmarks" (already is -- hit Alt-B), and "File Page &As" (A, just like in Save As). Now, try contorting your left hand to press Alt-B ...worse, try this on an MS-Natural keyboard. Well, that at least, I could fix with a simple macro. Personally I think I would like it if there was just a very simple, possibly undocumented, basic, easy-to-code, option in prefs.js ... to toggle between Netscape-style file saving, and MS-IE style file saving. Of course, that option could correspond to a toggle in Preferences->Navigator, or Preferences->Advanced. ...but it DOESN'T HAVE TO. However, that's my point of view, for my own use -- from a development perspective, the broader scope of users must be considered. There's only one way to figure it out -- everyone should start saving web pages to disk (in a subdirectory structure similar to bookmarks) and see how convenient this is when a page with useful information suddenly disappears from the Internet. I think though, that if I ever want this fixed, I'll have to do it myself. Since I don't have the source tree for Mozilla here, and have never compiled the thing yet, it will take some time to do it... I won't be able to do it for a few weeks yet. However, I don't relish the thought of having to modify and recompile every new Mozilla release for my own use... ...maybe I'll just keep using MS-IE ... BTW: another Mozilla bug is the page-rendering of CNN news webpages (most any news story at http://www.cnn.com is incorrectly rendered -- the text does not wrap properly) ...I don't feel like creating a new bug report for that right now though. It probably would get marked WONTFIX anyway.
>Maybe, but that would be considerably harder to implement, would it not? Yep, it would be considerably harder to implement. But this would be a complete solution. If it comes with preconfigured values, the user should never need to change or even touch that Preferences/Navigator/Save_as config page. So this feature would not disturb beginner users, but could help advanced users... >usefulness of saving web pages to disk instead of bookmarking them Bookmarking is not always the preferred way. Everybody can find a lot broken bookmarks in his list. That's because a lot sites: does not keep archives, changes URL-s, and are closing. Earlier URLs are BROKEN. Here we need the flexible file naming feature, which can speed up file naming, thus saving the files. This area is undiscovered area, and I think there is much more to do that we think right now. Just to mention features like: directory bookmarking, file categorizing features, file grouping features, file naming features, etc... All worths to think about for a while. The truth is that MS IE become so popular because 2 main reasons: 1) MS implemented IE into the system and made available by default. And most users as too lazy to download an another web browser. 2) MS IE 5.x and above unfortunately(?) contained a lot of useful features, what the users liked very much, like Title in Save as, selectable earlier content of forms, improved URL autocomplete, selectable images, complete page saving, etc. These special features made IE so popular. What I suggest fits into the the user-close feature line what IE started in the market. Mozilla can only competitor of IE if provides the popular user-preferred features, PLUS adds new features like my suggestion, which can make the product UNIQUE comparing to other products. If developers will be lazy to implement it, it makes me think, that all their previous developments was wasting of time. I believe, Mozilla CAN compete with IE, but needs more new features + those which was useful in IE! That's only my personal opinion. Sorry if I did hurt somebody with it. Well, I'm curious, if the "browser history" will prove my opinion.
Webmaster33: yes, I think you're right -- I didn't switch to MS-IE until v5.0 either (was using Netscape before). MS-IE loaded faster (the old Netscape versions took forever to load -- Mozilla is now a LOT faster), and contained lots of useful features. Yeah, well, I believe the Mozilla developers are developing the browser mainly for themselves -- I can't fault them though -- after all, nobody is paying them to do it. Therefore I believe they won't be likely to add features that they don't find useful themselves. Of course, Mozilla will never compete with MS-IE if that's the case... shame really -- page rendering is ALMOST perfect (except for that bug with lack of proper text wrapping on news pages of http://www.cnn.com, I haven't found any faults really).
>the Mozilla developers are developing the browser mainly for themselves - >I can't fault them though -- after all, nobody is paying them to do it. You are right, Mozilla developers are developing the browser mainly for themselves. But they would be the most happy people on the world, if they would get SUCCESS. If they would see that the web statistics shows decreasing of MS IE usage, and INCREASING Mozilla usage on the web!!!... Example of Linux is the same. Most Linux developers would never want GUIs for the software apps. But now they DO. Why? Because they recognized that otherwise they can not compete with Windows. It is exactly the same situation for Mozilla! I do not want any arguements here, because the bugs are not to have arguements. We would better wait developer opinions now, to see what is the official response to the suggestions. Best regards, Webmaster33
MSIE has never been my primary browser, and I don't plan on ever making it such... I try to avoid using stuff from Microsoft as much as possible. Thus, I don't see "MSIE does it that way" as a good reason to add a feature to Mozilla. The Mozilla developers should, of course, look at all other browsers (Opera, Lynx, etc., and also MSIE) as possible sources for ideas which can be implemented if they make sense, but not to be mindlessly imitated just to jump off the same cliff as the Microsoft lemmings.
Dan: it is necessary to avoid thinking in terms of "hostile company, bad product" when examining features of other browsers. ...my point was *NEVER* that just because MSIE does something, Mozilla should do the same -- my point was that the page saving in MSIE is useful, for example, let's randomly select a page from eBay: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=2062733976 Now, doing File->Save Page As ...in Mozilla. You get: eBayISAPI.dll.html ...as the filename. ...now view the HTML code of that file -- and try to determine what URL it came from... can you? Now save the same page in MSIE... you get: eBay item 2062733976 (Ends Oct-22-02 173102 PDT ) - 15 ATI 9000 P4 2_8 5,400 40G 512M 16X Combo ...as the filename. ...now view the HTML code in that file, and at the top, you see: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <!-- saved from url=(0061)http://cgi.ebay.com/ws/eBayISAPI.dll? ViewItem&item=2062733976 --> <HTML><HEAD><TITLE>eBay item 2062733976 (Ends Oct-22-02 17:31:02 PDT ) - 15" ATI 9000 P4 2.8 5,400 40G 512M 16X Combo</TITLE> Why is this so hard for some people to understand? THIS IS USEFUL!!!!!
QA Contact: sairuh → petersen
Alex is right! If there are useful features, what millions of users like, no matter if feature appeared in IE or other browser, it should be implemented because *the popular demand* in Mozilla. The truth is that IE *has* some good user-friendly features, what many users are missing from Mozilla... If something is default feature in IE, and users like it in IE, in Mozilla it should be at least optional feature, so users could turn it ON/OFF as they like. This kind of solution will satisfy everybody's needs, and making Mozilla much more popular!!! Best regards, Webmaster33
Summary: [RFE] Allow different default file names when saving → Allow different default file names when saving
One man[/woman/child/sentient lifeform]'s "good user-friendly features" is another's "atrocious dumbing-down". Microsoft, in particular, has a large tendency to design its software to "DWIM" [Do What I Mean], where the reference user whose meanings are to be guessed is a prototypical stupid, ignorant newbie without a clue as to how computers or the Internet really work. This means that anything from MS tends to ignore what its users (or the developers of whatever data goes into the programs from non-MS sources) actually *tell* the program to do, and instead second-guess it and figure out what MS thinks the end-user really wants, on the theory that the user is too stupid or ignorant to say what he wants correctly in the first place. This DWIM functionality is, additionally, done without concern for following any standards, practices, or traditions that didn't originate at Microsoft. The result is often to completely botch up the intended actions of users with higher degrees of intelligence and knowledge than the target MS user, as MS decides they don't really want to do whatever they just specifically told the program to do. Where filenames are concerned, there's a large body of tradition behind what to name files, based on what is likely not to cause problems over the wide range of operating systems, filesystems, applications, transfer protocols, command-line and GUI interfaces, scripting/programming/markup languages, and so on, that a filename might potentially be used within. In particular, a good filename should be reasonably compact and not use problematic characters like spaces and commas that might be (1) invalid on a given operating system, (2) reserved for use as delimiters in a given language, (3) invalid for use in URLs and hence requiring the ugly use of hexadecimal escapes. Unfortunately, page titles generally fail to fit in these criteria, so they don't make very good filenames unless, as Microsoft seems to assume, any file you're saving under them is to be used only by the end user, within the Windows operating system, and accessed only through a GUI interface; never used from a command line, transferred to a system under a different operating system, or put on the Web to be accessed by a URL.
Dan: you're totally correct -- long filenames with spaces and other characters can be difficult to use from a commandline. You're also correct that MS's products are designed for people who are generally ignorant (after all, anyone with programming or engineering skills is in the minority). One just has to develop the products for the masses, if one wishes to compete... either that, or one is only developing the products for oneself and a very few others. One thing I really disliked about MSIE originally, and still dislike, is the way it saves each bookmark in a separate file -- horrible waste of disk space! (one cluster per file... so each bookmark takes up 4k or more!!!) Since then, I've stopped bookmarking as many pages as I used to, hard drives have got larger, and I began saving entire webpages. An alternative to implementing a page-saving feature that is actually convenient for developing an archive of web pages, would be some sort of bookmarking feature that saves the pages in addition to the bookmark data. ...another idea that could be added to that, is it could apply ZIP compression to the saved data, and archive all the saved web pages in a single file, using a bookmarks-style list to access them, and decompressing the appropriate page when it's wanted. THAT would be really cool, would overcome OS limitations on filename length and format (could modify the compression/decompression algorithm to use whatever filenames one wants, or just use a bookmarks-style file as an index to the files in the archive), and would save lots of disk space!
for Comment #12, Dan Tobias: You are talking about MS, repeating that it is bad what they do. I do not bother about MS, and if they are doing correctly what they do or not. About the file names, your opinion is reasonable, but why do you explain this to me? Nobody can not stop the unstandard long file name usage, because 95% of the web users use MS IE. We simply can not stop this tendency. Additionally Mozilla could get/attract those IE users who are awaiting such features, if this feature would be implemented... I posted the suggestion, which can solve the problem generally, and could expect wide support from the users, because it would be match almost everybody's needs & taste: - If you want short file names, then use the short file name template and be happy - others who needs loong file names, use the title template and they will be also happy I'm not going to argue about any kind of file naming behaviour. I honour everybody's opinion & right to name his own file as he want, until it is stored on his own computer. If you want to argue with me, read again my comments above. for: Comment #13 From Alex >I really disliked about MSIE originally, and still dislike, is the way it >saves each bookmark in a separate file - horrible waste of disk space! I absolutely aggree! That's why I store all my bookmarks in Netscape. Only the a few important links are bookmarked in IE. >hard drives have got larger, and I began saving entire webpages My reason to save a webpage is (while I still bookmark it), that it is possible, the page I saved now, the link will be broken 1-2 year later. It happen in several cases. Only the most important, personally required informations are saved by me. >An alternative to implementing a page-saving feature that is actually >convenient for developing an archive of web pages, would be some sort of >bookmarking feature that saves the pages in addition to the bookmark data. Not a bad idea. I like it. Basically when users bookmarks a page could decide to: 1) just bookmark 2) bookmark & save webpage for future usage, categorized in same directories like bookmarks, relatively from a root directory (optionally in zip compressed format). I.e.: relative root dir is: "E:\save". We bookmark link in "Computers/Accessories" bookmark folder. So will optionally the page can be saved to E:\save\Computers\Accessories\ directory. Well, just my mind got working a bit on the idea. But this idea should be discussed in a new enhancement suggestion bug. >could apply ZIP compression to the saved data, and archive all the saved >web pages in a single file Yes, I also like this idea. Many times I also compress the saves complete pages. But this should be optional. It should be also discussed in a new enhancement suggestion bug, not here. Best regards, Webmaster33
Well, I actually think Mozilla's file saving process is OK ...it manages to save files when MS-IE says "couldn't be saved from current location", etc. It DOES lack the ability to use page titles as filenames though, and it also lacks the ability to store the original URLs in the saved page's HTML code. As you explained, both of those are useful when archiving web pages for personal storage. Some guy was arguing in the "page title as filename" 'bug' report, that saving pages with the title as the filename causes "data loss" (he was citing a case where he was apparently manually downloading each page of his web site because he couldn't get a FTP connection). I disagree -- data loss occurs when one cannot find the web page stored on one's hard drive, because it has a lousy filename like: eBayISAPI.dll.html Anyway, considering the simplicity of the minimum that I would like (ability to use page titles as filenames, and ability to have original page URL source listed as a comment at the top of the saved pages), it should take about 1 or 2 minutes for anyone to add to the Mozilla code (considering that I don't mind if it's just one or two undocumented option(s) that has to be manually set in Prefs.js), and I'm amazed that it seems it will NEVER be implemented.
Alex, we all would be happy if you donated those 1 or 2 minutes of your time and provided a patch.
>ability to have original page URL source listed as a comment >at the top of the saved pages This idea should be posted as separate bug, so it can be followed by anybody easier, comparing the case it is posted as comment here. So I suggest post a new bug with this subject, and please post a link here, so let we know, what bug to follow for this feature. I can promise a vote for this feature, as it is posted. I like it too. Thanks, Webmaster33
Johann: when I have time to set up the source tree and figure out how to compile Mozilla, if nobody else has done it already, I will, I promise. I do hope I won't have to, though.
At last I have found a real bug to vote for. Inflexibility of Mozilla is nearly killing me when saving files. If I save a continuous file area, e.g. a website, it's much better to use filenames taken from URL (keeping in mind that I can easily change HTML of index, killing leading parts of each hyperlink URL, and get a working site image on the hard drive for offline browsing). If I save a really independent buch of pages, especially those dinamically-generated with lots of query strings, then titles are pretty useful, and filenames from URLs are really confusing and may even be identical. Even Mozilla pref will not make a real difference for me, since those above described ways of saving should be implemented altogether, because they both can be (possibly) used in concurrent windows and downloads while surfing. It could be a real pain in the butt when a brouser reload is required. So, this bug name, 'Allow different default file names when saving', is a title of the top item in my Mozilla wishlist. Hope this bug will be fixed once.
Well, I have no plans to work on this. And I'm the only one "actively" working on this code (if it can be called that) at the moment. So someone who actually cares will have to step up and fix this.
Keywords: helpwanted
Seems like a good idea. Can you post an URL here which points to that part of the code you're working on? I'll take a look.
well um. let's start by someone explaining where they'd actually put this feature. after you explain where you'd put the feature please try and sell the idea to one of the following people: Ben Goodger (netscape), David Hyatt (apple), Jesse Glick (netscape), Mathew Thomas (independent). You're welcome to suggest another UI person to whom you'd like to sell it and then sell it to that person. Do you really want to stick it into the actual saveas dialog? I can tell you exactly how to do that for windows, but i'm not certain which version of windows you'd require, my guess is w98 perhaps w2k or wXP. in fact i don't think i will tell you, i'd rather you show that you understand the problems of hacking the win32 api, think of it as a research project, all you need is google.com/microsoft and google.com/search?q=site:msdn.microsoft.com+... Note that sticking it into the saveas dialog will probably be rather difficult for MacOS and various ports where the dialogs are rather fixed. For the xpfp it's just a matter of hacking xul. If you want to make a mockup demoing how it'd behave you can start with the xp file picker and create a small xul file which calls it manually (bypassing the standard file picker apis). ok, so supposing you don't do this because while i can describe how you'd do it for windows, it isn't pretty and probably means our look and feel will probably break for future versions of windows (this is never a good thing). There are other approaches like making sure the user has a list of possible strings they can just copy into the saveas dialog, but they all have problems. oh, and let's get one thing straight. the reason work isn't done in file handling has nothing to do with the people who could work on it being satisfied with how it works. the people who could work on it don't like how it works but find fixing other things more satisfying.
All right, I've downloaded lots of JS/C++/XUL/IDL - and I've got an immediate bunch of questions; first of all, in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 the dialog after clicking File -> Save page as... is actually system WinNT SaveAs dialog, that means no XUL is really involved. Then what are those XUL about - a progress dialog when dowloading? Am I using an old milestone, or the system standard SaveAs dialog still has to be replaced with Mozilla XUL if we're going to fix bug 173982? Where the system dialog is launched (plz show me the exact filename & string number)? I feel that is actually the point to start from.
Great, I've found it, that's in those http://lxr.mozilla.org/seamonkey/find?string=nsFilePicker files, where the system file pickers are launched. That means also that timeless@bemail.org is absolutely right about the problem, different approaches are used on different platforms, and either they're all to be hacked separately from each other, or the filepicker is to be made platform-independent, rewritten on XUL, and there's no other way (except those two above described) to implement a feature that will allow applying different default filenames (or filename templates, or anything else filename-related) when saving, when the dialog is already launched... I'm going to give up at this point for now, I won't even try to understand and rewrite these codefiles until September 2003. Probably some other coder will have time to fix it before. Good-bye.
After some dozen days of meditation, I finally came to some brilliant idea. There's no need of rewriting the interface (whick is really hard) in order to fix the bug. Only "File" menu is to be changed slightly. Instead of "Save page as... (Ctrl+S)" item (which is between two separators, and that will help) there should be two different items: "Save page with filename... (Ctrl+S)" and "Save page with title... (Ctrl+Shift+S)" This will introduce multiple choice, and fix the bug. It seems pretty simple, doesn't it?
I like the idea in Comment #26 very much.
What Should Be The Last Word On Bug 173982 When a user selects “Save Page As”, more often than not, the default filename chosen by the browser is complete gibberish. Let me give you an instance: “0,,SB106133088768734900,00.html” To the majority of users it simply looks as if Mozilla has a bug. Some may even think the browser is unstable: applications often do strange things just before they crash, and saving a page as “0,,SB106133088768734900,00.html” is certainly strange. Programmers will quickly figure out why this bizarre string appeared as the default filename, but the majority of users will be left in the dark. There shouldn’t be any confusion over how to implement the “Save Page As” function, but clearly there is. So what is going on? The problem lies with the programmer’s perception of the object to be saved. Certain developers are failing to draw a distinction between a “file” and a “page”, leading to confusion over what to use as the default filename. Users deal with pages, whereas browsers deal with files; or to put it another way: a browser downloads files, but it displays pages. When a user clicks “Save Page As”, he or she wants to save the currently displayed page, which is why the function is called “Save Page As”, as opposed to “Save File As”. By selecting “Save Page As”, the user is declaring an interest only in what is displayed on the screen in front of him; he is not interested in the HTML code that underlies that page. So, what exactly is the user looking at? A browser displays a virtual object called a “Web page”. We imagine a Web page to be identical to a page in a glossy magazine; the only difference being that a Web page appears on a monitor whereas a magazine page appears in print. As users, we remove - abstract away - all the implementation issues. We don’t worry about how the page is downloaded, where it is stored in RAM, or how it is “pasted” together. We are only interested in the contents of the page – the text and graphics - and nothing else. Thus, the name of an HTML file on a server is immaterial in this context. Because a Web page is a virtual object, the user shouldn’t be exposed to implementation issues when working with this object. Saving a page as “0,,SB106133088768734900,00.html” merely demonstrates that certain developers are failing to grasp this point, and, as a result, failing to maintain a logical separation between files and pages. A particular page may be built from a file called “0,,SB106133088768734900,00.html”, but the page itself, once constructed, should be given a more meaningful name. From the perspective of the user, a filename on a server has as much to do with a Web page as, say, the make of their computer. The HTML code provides all the information needed to construct a Web page, and that is where the browser should look for the name of the object – in the TITLE element! This makes a lot of sense, for even Word searches for a title to use as the default filename. When you save a new document using Word, the filename defaults to the first sentence or line of the document. This is eminently sensible, since most documents begin with a title. By all means, provide a way for an advanced user/programmer to gain access to the server filename, if that is what they want, but don’t make this the default option. Heavy users will quickly become exasperated at having to overwrite the default filename every time they save a page. I’m happy to pay for my copy of Mozilla and recommend it to friends and family, but only if it’s worth buying. If I have to keep switching to IE because Mozilla is not up to the job, I may as well stick with Microsoft’s offering. However, I’d rather see Mozilla succeed, and remove IE from my desktop once and for all. Finally, to those who say adopting a user-friendly approach will only dumb things down, they need to realise that most people’s lives do not revolve around computers. To most users, a PC is merely a tool, and - though some Mozilla developers may find this hard to swallow - a trivial presence in their daily lives. I entered a Mozilla chat room to express my dismay at the way “Save Page As” is implemented, but my views were largely dismissed. If Mozilla is merely a plaything for programmers, that’s fine. But, at least, the developers should have the courage to come out and say so. Don’t string everyone along; particularly those who are prepared to pay for their copy of the software. Michael
Well, I'm clearly not a "typical user" (being from a programming background), but when I save a Web page from Mozilla, it's usually for the HTML code, not the "virtual object". And I don't generally like to use filenames with all the weird stuff like spaces and punctuation that are usually in page titles. Recently, I took over as webmaster of a local group's site. It was like pulling teeth to get the password to the server that had been hosting the site so I could FTP it, but I was setting the site up at a new host anyway; so I saved the pages out of Mozilla as my starting point to edit them and put them up on the new server. In such cases, the original server filename is what I want to save the pages as, not some concoction based on the title. While I agree that some cases, especially script-generated pages, have really awful "URL filenames", others try to use names that make some sense -- I do in my sites. And some sites use really awful title elements -- sometimes they use the same title in lots of different pages, which would be a pain if Mozilla saved the pages under that name.
>Well, I'm clearly not a "typical user" (being from a programming background), >but when I save a Web page from Mozilla, it's usually for the HTML code, not the >"virtual object". Dan, your use of "but" indicates to me that you missed the point of the previous comment. You are not a typical user, and therefore, you are more interested in saving HMTL code. The previous poster was talking about another type of users that are interested in "pages", not HTML files. Since there are two types of users, and filename suggestions aren't always good (for the reasons Dan mentioned), I think having two commands (or options in the save dialog) is the best solution for this problem. I also often have to resort to IE because I want readable filenames, and I don't want to type them. It may be hard for some to believe, but I use computers to do some work FOR me.
Comment #29 From Dan: If you don't have FTP access, and you still want to move your site, using exact filenames, you should use a mirroing software, not Mozilla. However in Mozilla different filenames should be choosable by the user when he/she wants to save a page (original name, page title, link text, custom names with date or serial number, etc...), as I suggested earlier in Comment #4.
It seems, that somewhere along the way, the whole point of the original bug report has been lost to commentors and peaople started their religious rants about their personal preferences. As far as I can see - the point of this bug is not wether one or another way of default filename would be better or not - the point of this bug is that the people should be presented with a choice of default filename in a most unobtrusive manner. The best place for such a choice would be the "Save As..." dialog, since it is the place where the user decides what filename to use. If the dialog is able to remember user's choice of the default base for a filename, then next time it will do what the user expects and everybody is happy. There are however two problems that need a solution: 1) How the choice of possible filenames will be presented so that it is visible enough, but does fit in a native toolkit. One possible way of presenting those filenames, would be by providing an autocomplete to the filename field of the (native?) filepicker. The problem with this approach is that not all toolkits allow extending of the native dialogs (maybe I'm wrong). This could be solved either by using xp dialog (bad) or simply not implementing given feature on the that platform. 2) If the user changed the proposed filename to something that is not one of the defaults - what should be remembered as a default filename for the next time? Basially, there are 2 solutions: a) ignore the last choice; b) do some semi-intelligent heuristics based on the filename entered (say - if the filename has spaces and/or punctuation in it, then next time use Title of the page, if not, use filename part). The question 2 is actually important because it allows us to guess the default filename preference even if there are not going to be any changes to the UI of the file-picker.
erm. question 2 of comment 32 is not important. if you can't do 1 reasonably well then don't bother worrying about 2. since i'm commenting, i'll take a moment to say that i dislike comment 26 very much. if dan tobias ever visits this bug again, i'd be curious to know what he would say to having view selection source use the title as a filename. further, i'm not really sure the original point was ever lost, although there have certainly been a few rants along the way...
Ok - maybe point 2 is not important, but helpful none the less. I personally can live with any static choice, but since there have been some firece religious rants on this topic, I believe little picking on the brain of the user would go long way to satisfying both parties... And in addition - an autocomplete of the filename field with some preconfigured values would be nice bonus to those platforms that can support that kind of modifications to system dialogs. just offering my few cents on the topic...
From a logistics standpoint, how can this be done incrementally? That is, how can we get this working on 1 platform at a time? It looks like hacks to the native save dialog on every platform will need to be developed and it would take an Act of God to get that done simultaneously. On a volunteer basis it pretty much won't/can't happen. So do we need to do make this a tracking bug and file another bug for the common 'backend' code then another bug for each platform? Is there better way to organize the required tasks?
*** Bug 291620 has been marked as a duplicate of this bug. ***
*** Bug 327523 has been marked as a duplicate of this bug. ***
*** Bug 173983 has been marked as a duplicate of this bug. ***
Assignee: law → nobody
QA Contact: chrispetersen → file-handling
Look at http://online.wsj.com/article/SB124657539489189043.html Firefox wants to save the File as SB124657539489189043.html Both Google Chrome and IE8 offer to save the file with the page's title - New Evidence on the Foreclosure Crisis - WSJ.com When I want to save a file I copy the URL and open Google Chrome. I then use the paste and go feature, and then save the file. It sure beats typing in the title. This has been an issue for years. When Firefox was first released some of us noticed that it was not following the save-by-title standard that IE had set. Then Chrome followed the IE method. If those guys can do it why can't Firefox? Looking at comment #1, I see that this behavior was considered a "holy war" back in 2002. Nearly seven years later, it's time to revisit the logic. What do users expect in 2009? Again: if IE and Chrome can make this work - indeed, they have made this behavior the standard - why can't Firefox follow suit?
WORKSFORME Also, related bug 254139 was fixed in Nightly 18.0a1 2012-09-06 by: https://hg.mozilla.org/mozilla-central/rev/b901e1920284
Status: NEW → RESOLVED
Closed: 13 years ago
Keywords: helpwanted
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.