Closed Bug 230166 Opened 20 years ago Closed 20 years ago
Saving page prompts with chained file extension: utilities
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Trying to save files appends Mozilla generated extensions,lenghtening each save from a single click to a 10+ times longer editing of file extensions. There needs to be at least a global option "Leave file extensions alone." If it wants to be smart, the browsers should at least check all the extensions of supplied mime type and if any matches the one provided by the server, leave it as it is. To save the excessive and almost always redundant registry lookups, a built in table of most common equivalent types (such as html = htm = shtml...) can be used to preempt the current half-baked "append The Ideal extension" logic. The old "dumb" browsers were much smarter by simply recognizing they don't know how, or whether it is possible at all, to turn the tangled world of all the servers and all the mime types and all the OS's/platforms into utopia. Reproducible: Always Steps to Reproduce: 1. Go to page 2. Type Ctl-S to save Actual Results: The Save As dialog will offer: utilities.shtml.htm which is not what anyone would want, whether they support or oppose the extension mangling. Expected Results: The expected prompt should be: 1) utilities.shtml or in the worsyt case, if the extension mangling has to be done, no matter what, for philosophical reasons, then at least: utilities.htm (or whatever the first extension for text/html mime type is on the platform). Changing mime types in registry, by adding shtml and cloning htm entry doesn't help.
Please test a more recent build; a lot has changed in this code since 1.5 (and even since what will ship as 1.6).
Assignee: general → file-handling
Component: Browser-General → File Handling
QA Contact: general → ian
> Changing mime types in registry, by adding shtml and cloning htm entry doesn't > help. in current builds, that should work, especially if you have a string value under HKCR\.shtml named Content Type with value text/html.
Just installed 1.6 and the problem seems fixed. Great.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
thanks, vrfy fixed by Bug 163254
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.