Closed Bug 120327 (exe-san) Opened 23 years ago Closed 22 years ago

Sanitize extension-fixup code: Don't add .exe or .txt to files names of text/plain and application/octet-stream, etc.

Categories

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

Product:
Core Graveyard
Component:
File Handling
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.1beta

People

(Reporter: jmd, Assigned: bugs)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: topembed, Whiteboard: This bug is DEAD. Do not reopen. File new bugs on specific problems.)

Attachments

(2 files, 5 obsolete files)

screenshot of download dialog
9.59 KB, image/png
Details
same patch with minor changes to make it compile
3.86 KB, patch
bzbarsky
: review+
jag+mozilla
: superreview+
asa
: approval+
Details | Diff | Splinter Review 
At least on UNIX, possibly also Mac (I'll get mpt's input), for text/plain
files, Save Page As shouldn't add .txt to the file name. The assumtion on UNIX
is if there's no extention the file is text. Adding a txt ends up with some
files named oddly.

For example, the URL is a perl script of mine. It's named "remv", but Mozilla
tries to rename it "remv.txt". This is a silly name for an executable, and
breaks UNIX convention.

Adding .txt is good on Windows though, as Bill's OSes have big trouble with
unextentioned files.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.2
mpt sez: "Absolutely". Updating summary to clarify problem, and include Mac and
UNIX.
OS: Linux → All
Hardware: PC → All
Summary: UNIX only: text/plain documents shouldn't save as *.txt → Mac & UNIX: text/plain documents shouldn't add .txt to suggested file name
*** Bug 130262 has been marked as a duplicate of this bug. ***
As I have saif (in bug 130262) this is indeed close (and perhaps the same).
Still note that in my case the problem is for _all_ text files, not only for
files with no extension.
*** Bug 130570 has been marked as a duplicate of this bug. ***
*** Bug 131349 has been marked as a duplicate of this bug. ***
*** Bug 131402 has been marked as a duplicate of this bug. ***
This is very annoying on Windows as well. See bug 131402.
Summary: Mac & UNIX: text/plain documents shouldn't add .txt to suggested file name → text/plain documents shouldn't add .txt to suggested file name
Attached patch Simple-minded patch (obsolete) — — Splinter Review 

    
    

    
  
Last MSWindows I used ('98), it was impossible to associate non-extentioned
files with a program, so there was never a way to get, say, "file", to open in a
text viewer. I think it would be much much much more annoying for windows users
NOT to add the .txt. UNIX convention is no extention and Mac uses the filesystem.

    
    

    
  
So.  A "non-simple-minded" patch would look something like this maybe?

----------------
if (type == "text/plain") {
  if (not windows)  // XXX what about non-mac/non-unix things like OS/2?
    return "";
  if (already has an extension)
    return "";
}

// fall through to code that will get the preferred extension for text/plain
// content from the MIME service.
----------------

The thing that gives me pause is the "XXX" comment.  Could we have a clear
definition of what the expected behavior is here on every single platform we
support?  I'd rather not spend multiple patches and bugs and review cycles
tweaking this over and over...

    
    

    
  
if (already has an extension)
  return "";
switch (type){
case "text/plain":
  if (not windows && not os2)
    return "";
}

BeOS uses mime types, text/plain is a mime type, life is good.
OS/2 uses extensions. .txt is an extension.

    
    

    
  
This really should be fixed on Windows as well. Files served as text/plain is
far from always text files, and they will often not work at all if they are
given a .txt extension. <http://www.gerv.net/software/patch-maker/pm>, for
instance. Keep in mind that not only files without an extension are subject to
Mozilla's extension adding -- if I put a perl script called someperlscript.pl up
somewhere and serve it as text/plain, Mozilla will suggest someperlscript.pl.txt
as the file name.

BTW, it has always been possible to create associations for non-extensioned
files -- just add the extension to HKEY_CLASSES_ROOT\Unknown\shell in your registry.

    
    

    
  
*** Bug 132207 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 132358 has been marked as a duplicate of this bug. ***

    
    

    
  
The "simple-minded patch" does the job, IMO. Have you asked for r=/sr=?

    
    

    
  
No, because I think it's the wrong thing to do (hence my suggestion of the 
non-simple-minded patch).

See the end of comment #10.  We need a spec of what we _want_ to do here before 
we start coding.

    
    

    
  
Your non-simple-minded patch would still add .txt to text/plain files with no
extension on Windows. *That* would be the wrong thing to do, IMO, since
text/plain is used for a myriad of things other than human readable text, many
of which have some sort of requirement that the original filename is preserved.

    
    

    
  
> since text/plain is used for a myriad of things other than human readable text

Any such use is completely and utterly incorrect.  RFC 2046 says:

  text -- textual information. The subtype "plain" in particular indicates plain 
  text containing no formatting commands or directives of any sort. Plain text
  is intended to be displayed "as-is". No special software is required to get
  the full meaning of the text, aside from support for the indicated character
  set.

So the question becomes, 

"Which of the following two happens more often?

1)  Text content meant to be viewed as text which has a filename that has no
    extension
2)  Non-text content which is sent as text/plain, is in a file that has no
    extension and would be completely unusable if given a .txt extension"

I have no good answer, since I don't use Windows and hence pay no attention to 
extensions 99% of the time.  As it happens, I don't even care what the answer is 
or which exact course we take here, for the same reason.  I'm just not willing 
to waste my time and the time of various reviewers on a patch that will just 
need reworking.

As a further note, a "really non-simple-minded" patch would draw a distinction 
between filenames derived from a "Content-Disposition" header (which perhaps 
does not need to be extension-munged), filenames derived from the URL "fileName" 
part (which are more likely to be mungible than the header) and filenames that 
we create based on the hostname/text/title/moonphase, which almost certainly 
need munging even if they look like they already have an extension.

    
    

    
  
I'll just note that saving binary files tries to add ".bin" to the existing name.
Why not take the pseudocode in comment #11 and remove the test on the MIME type?
If it already has an extension and/or it's (not windows or os/2), just leave it
alone.



    
    

    
  
> Why not take the pseudocode in comment #11 and remove the test on the MIME
> type?

This is only doable in the "really-non-simple-minded" case when we consider the 
source of the filename before doing things to it.  Consider doing "Save Page As" 
at http://www.mozilla.org/:

1)  There is no content-disposition header
2)  There is no filename in the url
3)  There is no directory in the url
4)  The page title is "mozilla.org"

Thus the only filenames that are worth considering are "mozilla.org", 
"www.mozilla.org", and "index.html".  We currently do the first of these, but we 
need to append ".html" on Windows so things will work.  Too bad ".org" looks and 
smells like an existing extension... 

    
    

    
  
Can someone explain why UNIX users like me are seeing added extensions
at all ? Whether or not servers should be serving C files as text/plain,
I definitely don't want an added extension under *any* circumstances.

    
    

    
  
The scenario in comment 20 should be adding an extension on non-Windows 
platforms as well, imo (and I say this as a Linux user who hates extensions).  
Basically, if the filename is based on a real filename we should let it be.  If 
it's based on some random text we got from somewhere, we should add an extension 
for the benefit of dumb programs that won't open the file otherwise.

    
    

    
  
*** Bug 135920 has been marked as a duplicate of this bug. ***

    
    

    
  
Actually, as far as compatibility with 4.x is concerned under 4.75 on Linux
there is at least one case where .txt should be appended & it's not.

Under Mozilla if you choose "Save page as" and choose the "Text file" option the
extension is left as .html (which is wrong).

Under NN4.75 if you change between between text and source the extension is
changed too *unless* you edit it manually. I note that it also handles the case
listed in the example URL here correctly also. (i.e. it doesn't add an extension.)

NN4.75 gets all the cases I can see right (under Linux at least) shouldn't Moz
act the same way for reasons of correctness and 4xp?


P.S. Not sure which of the many bugs like this my comment should be attached to,
but hopefully it'll find it's way to the correct place.

    
    

    
  
*** Bug 136411 has been marked as a duplicate of this bug. ***

    
    

    
  
As a Unix user, I'd really rather there not be extension mangling done to files
I download.  I find it to be much more often harmful than helpful.  More often
than  not, files have the correct extension already, but the web server in
question is misconfigured to report MIME types incorrectly, so I end up
downloading a bzip2ed tarball and end up with foo.tar.bz2.txt.

I don't normally advocate pandering to broken server-side behavior, but in this
particular case, there isn't much reason to do name mangling at all.  The only
cases where it's really necessary are generated content, and I can't remember
the last time I saw a generated text/plain document.

Perhaps the following psudocode would be a reasonable solution?

// if content is the result of a GET with query params, or a POST
if(isGenerated){
  doMangle();
}else if(!isUnix && !hasExtension){
  doMangle();
}

The only problem I see with this logic is that content generated based entirely
on session state and retrieved by a regular GET would fail the isGenerated test.
 I think that saving this content to disk is rare enough that it probably
doesn't matter though.

    
    

    
  
This sucks on windows too, .dot (Word templates) become .dot.doc . Really ugly...

    
    

    
  
*** Bug 138970 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 138146 has been marked as a duplicate of this bug. ***

    
    

    
  
I agree that this is no good in Windows either.  If I want to download a file, I
want to download the file with the name as it is.  I don't want Mozilla to
change it on me.  If the Save As dialogue box wants to list other files of the
same "type" (not extension) that's fine - but don't change the extension of the
existing file to be downloaded.

    
    

    
  
> If I want to download a file, I want to download the file with the name as it
> is.

Is that a blanket statement?  So if you do "save as" on a web page with a URL
that ends in "foo.exe" you want the saved file to be names "foo.exe" (if so, I'm
sorry, but you'll be disappointed with the final solution to this bug)?

If people note, this bug is targeted for Mozilla1.2alpha. I feel that this is a
fairly realistic estimate of when I will have the time to fix this (I suspect
it's an optimistic one for Bill).  In the meantime, if someone wants to produce
a patch I would be quite happy to give feedback on it....  

If you're not producing a patch, please do not comment "I hate this too!".  All
it does is clutter up this bug and people's mailboxes.
Keywords: helpwanted

    
    

    
  
> So if you do "save as" on a web page with a URL
> that ends in "foo.exe" you want the saved file to be names
> "foo.exe"

Correct.  Or, at least, I want it to default to the name is it is on the server.
 If I want to rename it to something else, then I can do so via the Save As
dialogue.  This is, AFAIK, how all download managers work, and I'm not sure why
the behaviour should now suddenly be changed in Mozilla.  Worse, is that in the
current behaviour even if I manually override the suggested filename extension,
it ignores me and uses it anyway.

> If you're not producing a patch, please do not comment
> "I hate this too!".  All it does is clutter up this bug
> and people's mailboxes.

Such is not my intent.  I see that there is already some discussion on the
subject, pro and con, and I'm giving my input - hopefully more than just "me
too".  Bugs needs to be discussed to some degree to see if they will be fixed or
not.  It took me some time to find this bug, since the Summary doesn't lend
itself to an easy Bugzilla search, and I'd been following another one that was
recently marked as a dupe of this - although the one marked as a dupe was really
a super-set of this one.  This bug seems to pertain to text/plain documents
only, whereas I think it should apply globally.  Either the summary of this bug
should be changed, or else bug 138146 should be re-opened since it's not a dupe
but a super-set. (Theoretically, this bug could be marked as a dependency of
that one.)

    
    

    
  
*** Bug 139372 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 139731 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 139444 has been marked as a duplicate of this bug. ***

    
    

    
  
for a while i though this was a security feature:  
.vbs.txt, .bat.txt, .pl.txt
but things like .mpeg.mpg and .jpeg.jpg are clearly a bug

    
    

    
  
*** Bug 140570 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 140519 has been marked as a duplicate of this bug. ***

    
    

    
  
I disagree with this entire issue. It is not Mozilla's business to make sure that:

a) People offering files on websites/FTPs gives their filenames the "correct"
filename extension

b) The OS knows how to open incorrectly named files

       Trying to solve the above two problems is a waste of your time and will
lead to a lot of headache.

FYI: Under OS/2, file type isn't determined by filename extension but rather
each file has an appropriate EA header attached to it stating the actual file
type, so at least for us this entire issue is totally irrelevant. If you want to
add EA headers, fine; do whatever you want as long as you're _adding_
information, not changing information. I don't like the idea of Mozilla altering
files I download in any shape or form.

    
    

    
  
That is not entirely correct.

On OS/2 association can be determined by extension OR by file type. The file 
types are system file types that do not map to mime types (Text file, BMP file, 
etc.)

But I have to agree with Gili on this one. In no way shape or form should we be 
modifying the name of the file that is being saved to disk, regardless of 
whether it is text or not.

If the user wants to call it a .txt file, more power to them.

    
    

    
  
Just to clear up a misunderstanding.... The current behavior on everything but
Windows is:

1) We take the filename we generated (from the URL, HTTP headers, web page
   title, etc)
2) We make sure it has a reasonable extension (one that matches the content
   type)
3) We put up a filepicker with some default filename
4) The user chooses what name to save as
5) We use that name

So the user can call the file anything the user wants; the only thing we touch
is the _default_ name we prompt with.

The behavior on Windows is a little different, courtesy of the Win32 filepicker
and the fact that people saving HTML on Windows want to be able to type "foo" in
the filepicker and get "foo.html" saved.


    
    

    
  
Let me give you a real good idea why this is wrong.

I have a local file on my system called CONFIG.SYS. It happend to be a text 
file.

I open it in Mozilla. 

I select save as.

The save as name is config.sys.txt

This is totally wrong.


    
    

    
  
> The current behavior on everything but Windows is:

Which many of us obect to...

> 2) We make sure it has a reasonable extension

Why?  Is it technically impossible to tell what file extension it actually has?
 If not, why not make the default be what it really is?  People can choose to
modify it if they wish, based on any recommendation the picker might suggest. 
Otherwise, it's like ordering a cappucino and having the server hand over a
decaf black instead - because it's "better" for you, or more along the lines of
what the server thinks you should have ordered...

> people saving HTML on Windows want to be able to type "foo" in
> the filepicker and get "foo.html" saved.

How many people want this?  Was some kind of study done?  Do you have numbers to
show that this is the majority concensus?  (It it is, I'll go along with it.) 
If I type in "foo" that's what I want the file to be named when downloaded.  If
I wanted it named "foo.html" then I'd type in "foo.html".

    
    

    
  
Due to Microsofts bad design, people don't know how to use file name extensions
anymore (the file manager doesn't show them anymore by default). So
Windows-Users actually do expect some sort of "auto-extension". That's ok for me
if the file served actually is called something like "foo" without extension.
But it gets extremely confusing if mozilla renames things like wordTemplate.dot
to wordTemplate.dot.doc because for mozilla (via windows standard extension
settings) a msWord mimeType should have the extension .doc. That's bad for
everyone, novices and expert users.

    
    

    
  
I'm all for not EVER making ANY kinds of alterations to the original
filename(*). Especially, Moz should never alter anything I specifically typed
(or specifically removed).

(*): Exception: I'd really like to see .asp, .php, .pl, .cgi, .jsp, and other
such generated files get renamed to .html when saving (but only if the file is
served as a HTML file). I don't think anyone'd be interested in the fact the
file was ever generated by PHP or the like... And double extensions are just
annoying.


However, I think for the average Windows user who doesn't know much about
extensions the following would be good:

Adding an extension on Windows should ONLY happen if the original file already
had an extension, but I type a new name WITHOUT an extension AND the filetype
picker is set to something other than "all files (*.*)". 
So if I download "foo.html" but then type "bar" instead, the new name should be
bar.html IF the Save As Type picker is set to HTML (which it should be by
default as I was trying to save an HTML file). If I download anything else
that's not listed as a known type or the original file didn't have an extension,
the Save As Type picker should be set to "All files (*.*)" and in this case it
should NEVER add any extension.
I think this is actually the behaviour of most Windows programs. (or at least
the ones that don't suffer from bugs like this, like Internet Explorer does..)

Just my 2*10^-2$

    
    

    
  
> How many people want this?

Good question.   Since this is actually done the Windows filepicker in one of
its modes (like the one where you tell it that there is a default extension of
_any_ kind) and since IE uses said mode (as do most other commonly used Windows
apps), I would expect the answer is "any non-power-user who uses Windows and
most power-users".   But I don't know of any formal studies done on this.. see
bug 57113 and its various dups for related discussion.

comment 44, is spot-on in that we should not be munging extensions unless we
know we're doing it right... the fact that ".dot" is not in the valid extensions
list for the msword type is actually a bug (since I assume that if you ask the
OS for all extensions associated with the msword type ".dot" is in there...). 
This bug should be fixed if our extension-fixing on Windows is to be all viable,
imo.

-----------------------------

I've been thinking about this bug far too much over the last few days...  Here
is what I definitely think we should do:

1)  Do no extension-fixup for application/octet-stream on any platform, since
    chances are this would be completely bogus.
2)  Do no extension-fixup for text/plain on any platform _if_ the the filename
    came from the filename-part of the URL and there is already an extension on
    the filename (since text/plain is a dumping ground for stuff....)
3)  Do no extension fixup for text/plain on non-Windows/non-OS2 platforms,
    period.
4)  Do no extension fixup if the filename came from the content-disposition
    header.
5)  Do no extension fixup if the content type came from a protocol like ftp://
    which does not have content types to start with.
6)  Do extension fixup if the filename came from the host or directory name part
    of the URL.

In all these cases, the Win32 filepicker should be initialized with the
filename's extension as the "default" extension.

This part I _think_ will be agreed on by people, but if you have issues with it
feel free to let me know.

The question then becomes "In other cases, should we fix the extension, or no?"

The basic problem is the following: If I have a link to http://foo.com/bar.exe,
(or http://ebay.com/foo.dll, which is _very_ common) which is a CGI script and
returns an HTML document and you either "save link as" or go to the page and
"save page as", should the default filename proposed be "bar.exe", "bar.html",
"bar.exe.html", or what?  

I realize that the Linux diehards (like me) will vote for "bar.exe" but the fact
is, a _typical_ user actually wants to open that file after downloading it and
if it's saved as bar.exe many linux programs will fail to detect that it's
actually HTML.  I just tested Mozilla, NS4, amaya, lynx -- amaya was the only
one that showed such an HTML file as HTML (but it shows _anything_ as HTML,
including real .exe files, PDF files, etc).  Furthermore, current Linux file
managers unfortunately rely on extensions to launch applications....  OSX is in
a similar boat...

In summary, please let me know ASAP if you disagree with points 1--6 above,
since the rest of this discussion is moot if I missed something and one of those
does not apply.  If you _do_ agree with them, I'd welcome comments on dealing
with the problem of CGI programs with wildly inappropriate extensions while not
breaking other things served over HTTP...

    
    

    
  
By the way, from comment #20:

>Consider doing "Save Page As" at http://www.mozilla.org/:
> ....
>Thus the only filenames that are worth considering are "mozilla.org", 
>"www.mozilla.org", and "index.html".  We currently do the first of these, but we 
>need to append ".html" on Windows so things will work.  Too bad ".org" looks and 
>smells like an existing extension... 

I think this is the wrong thing to do. We should call the file index.html. 99%
of the time this would make sense, and would probably have been the original
name too. Don't call it www.mozilla.org.html, or even www.mozilla.html or
www_mozilla_org.html (to completely get rid of dots in the name; which I think
should happen should it be decided not to go with 'index.html').

    
    

    
  
Oh, and by "extension-fixup" I mean "we append the extension to the filename the
user is _prompted_ with.  After that, if the user changes the filename, we use
the user's filename _except_, as Arnoud points out, on Windows, where the
filepicker will sometimes add the "default extension" to the filename (we're
using the built-in Windows filepicker, so it should do this correctly, no?  I
know that it does not append the extension if *.* is selected as the filter (and
yes, we should have that filter in the filepicker; separate bug)).
Whiteboard: Please read comments 45, 46, 47 before commenting.

    
    

    
  
Sounds great!

>The basic problem is the following: If I have a link to http://foo.com/bar.exe,
>(or http://ebay.com/foo.dll ..

We should probably look at the content types here. If it serves text/plain, make
it bar.txt. If it's text/html, make it bar.html. If it gives
application/octet-stream, leave it as .exe (or .dll, or whatever). In any case,
please don't make it bar.exe.html. That's exactly what this bug wants to rid us
of :)
Whiteboard: Please read comments 45, 46, 47 before commenting.

    
    

    
  
> In summary, please let me know ASAP if you disagree with
> points 1--6 above,

I'm in agreement.

> I realize that the Linux diehards (like me) will vote
> for "bar.exe"
 
(Raises hand. <grin>)

>  but the fact is, a _typical_ user actually wants to open
> that file after downloading it and if it's saved as bar.exe
> many linux programs will fail to detect that it's actually HTML.

I question how many typical users would actually want to *download* such a
document in the first place.  Most Web sites offer it as a link, you click on
it, and the CGI formatted information is displayed on the screen.  Would a
typical user even be aware that you could download it in the first place or have
any use for storing it locally?  Wouldn't most of them simply use it online in
their browser session?  My first thought would be only non-typical users would
want to download it - and the majority of those *would* be aware of the filename
issues.

However, if we are going to assume that we want to make such a download "typical
user friendly" then an approach similar to comment 49 (content type based) makes
sense.

    
    

    
  
Oops, accidentally cleared the whiteboard. Putting back...
Whiteboard: Please read comments 45, 46, 47, 48 before commenting.

    
    

    
  
My 2 cents: if type is "application/octet-stream" don't touch it. If the website
author screwed up and none of his users have enough brain power to figure out
how to open this file, it's their own problem. We're not here to cure the world
of all ailements.

I believe in providing "enhancements" when the solution is straight-forward
(i.e. if we _know_ the file is a text file, we might choose to append .txt,
otherwise don't bother guessing, guessing is bad!). If it's not straightforward,
leave it be.

BTW: Another comment: if the File Dialog file type is "*.TXT" the suggested
filename *should* include the .txt extension. i.e. if the filename reads "hello"
I expect "hello." to be saved to disk; if it says "hello.txt" I expect
"hello.txt" to be saved to disk. I think it's totally bogus that typing
"hello.txt" when file type is "*.txt" will save to "hello.txt.txt".

    
    

    
  
> if type is "application/octet-stream" don't touch it.

Please read comment #46 again.  This is item 1 under "what we should definitely do".

> think it's totally bogus that typing "hello.txt" when file type is "*.txt"
> will save to "hello.txt.txt".

If it does this on OS/2, that's a bug in the OS/2 filepicker that should be
filed on mkaply@us.ibm.com.  If it does this on Windows, it's a bug in the
Windows filepicker (that has not been observed) and we need to work around it. 
No other platform we have touches the filename the user enters in the filepicker.

> I question how many typical users would actually want to *download* such a
> document in the first place.

Anyone who wants to save a web page (using "Save Page As").  This is very
common, especially for things like results of transactions and the like...

    
    

    
  
> Anyone who wants to save a web page (using "Save Page As").

True.  But that's not the same thing as right-clicking on a "hardcoded" link
along the lines of "foobar.exe" (that uses a CGI script), with a predefined
name, and selecting Save As from a context menu.  In the example of saving a Web
page that they're already viewing, there's no preconception of a filename. 
Rather, they would expect "something" to be saved to disk, but wouldn't be too
worried what it was called.  (Currently it's [Web site name].html)  The example
of saving a page being viewed isn't quite the same as saving a "foobar.exe"
link.  (Unless the Web site happened to be named "foober.exe" - which would be
quite unusual.)

So, I have no doubt that many typical users would wish to save a Web page that
they're currently looking at.  But, again, how many would do the same for a
"foobar.exe" link?  Surely, they'd left click on it (view it) first, THEN save
it if they wished.

    
    

    
  
> But that's not the same thing as right-clicking on a "hardcoded" link

Except that they follow the same codepath at the moment...  I'd be quite fine
with attempting to introduce a distinction there, myself... ccing some UI folks.

I'm not sure I see how saving a "foobar.exe" website can be considered unusual
while saving a link to "foobar.exe" that returns a text/html type is "usual",
but that's just me.  :)  In any case, I'm glad we agree that "foobar.exe" is not
an acceptable name for something being saved from "Save Page As".

    
    

    
  
> 2)  Do no extension-fixup for text/plain on any platform _if_ the the filename
>     came from the filename-part of the URL and there is already an extension on
>     the filename (since text/plain is a dumping ground for stuff....)

I vote for expanding "and there is already an extension on the filename" to
"regardless of whether there is already an extension on the filename". I
certainly do not want http://www.gerv.net/software/patch-maker/pm to be saved as
"pm.txt"

    
    

    
  
Here's a very simple question that really gets to the heart of this bug.

How many files on your machine are text/plain documents because of their 
content, but do not end in .TXT?

My guess is most of them.

what about all the files you've named .diff because that's what they are? What 
about READ.ME? What about .ini files on Windows? what about .BAT files?

The assumption that text/plain means it should end in .TXT is just simply wrong. 

    
    

    
  
*** Bug 141632 has been marked as a duplicate of this bug. ***

    
    

    
  
Who defines that files must have an extension?
OS/2 (for examples) use extended attributes to associate filetypes with
applications.
Additional - to be compatible with windows - you can associate file extensions
(*.DOC) to an application but in many cases this is not the right application
for this file extension. 

All these functions are part of the operating system and should IMO not be
changed by the application. 

It's not a good idea to offer the default filename "mozilla-os2.zip.exe" for a
file named "mozilla-os2.zip" on the server. 

Question: Why does this file has not the right file type on the server? Another Bug?

    
    

    
  
The foo.zip.exe thing is a bug in Mozilla, and is handled by point #2 in comment
#46.  If this is an FTP server, it's also handled by point #5 in comment #46.

The server can send .zip as application/octet-stream and that's not a bug; that
type is the designated "dump shit here if you don't know what it is" type.
Blocks: 141806
Blocks: 65827

    
    

    
  
*** Bug 141927 has been marked as a duplicate of this bug. ***
Blocks: 142102

    
    

    
  
*** Bug 142116 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 142274 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 142327 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 142493 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 142743 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 142763 has been marked as a duplicate of this bug. ***

    
    

    
  
Updating summary
Summary: text/plain documents shouldn't add .txt to suggested file name → Sanitize extension-fixup code: Don't add .exe or .txt to files names of text/plain and application/octet-stream, etc.

    
    

    
  
*** Bug 143007 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 143210 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 143260 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 143473 has been marked as a duplicate of this bug. ***

    
    

    
  
As the Bug 143473  I filed has been marked a duplicate of this one I disagree with comment#41.     
   
The dialog that appears when I click on a link with a .pls file gives the choice to pick an application     
to open that file or save it to disk. If I want to pick an application I can't change the file name. I wonder    
how that feature makes it easier under Windows to open a file.    
     
But nevertheless can't this feature be made configurable?     
Because I strongly wish to switch it off without recompiling.   
   
And I don't understand why such a feature that didn't exist in RC1 has to be put into the 1.0 branch. Does that  
mean this will be in the 1.0 Release?   

    
    

    
  
Detlef, the situation you describe (not being able to change the filename when
running an app) is due to the fix for bug 116938. That got checked into the
mozilla1.0 branch because the alternative was allowing websites to make Mozilla
execute arbitrary content as a Windows executable.

Note that the "save as" behavior from menus or context menus is in JS, so no
recompile is needed to change it if you really care.  The
click-on-something-we-can't-handle behavior is in C++, and the pref would be
equivalent to a "allow web sites to run whatever they want on my machine" pref
-- hence no pref.

Yes, this behavior will be in the 1.0 Release unless someone comes up with a
better fix.  Note my comments in bug 116938 which describe what I feel is a
reasonable way to do it.

Also, you are in fact not disagreeing with comment 41.  You are just complaining
that you don't like the current behavior.  Neither does anyone else... Patches
accepted.

    
    

    
  
Whoa mozilla offereed to save an .mp3 as a mp3.mpga for me today, very strange.

    
    

    
  


  
Boris,
there must be a misunderstanding.
I have attached a screenshot of the dialog that I'm speaking about.
I use Mozilla build 2002050509 and got this dialog. If you press "OK" you can't
change the filename and xmms (or maybe RealPlayer or WinAmp or what you like)
doesn't now to do with a "pls.exe".

If you click away the checkbox "Always ask before opening this type of file"
the helper application will be called with the filename without any further
prevention. So this feature is already there.

What I think of is a pref like "put filename extensions to downloaded files".

The risk of running an unwanted application on Windows is higher when the
filename is extended with ".com" or ".exe" as Mozilla does not support ActiveX.
Especially with the option "Always ask before opening this type of file"
disabled.

    
    

    
  
Detlef, there is no misunderstanding...  Note that the file is served as
"application/octet-stream".  This is where .exe comes from -- it is the
extension Windows has listed as the extension for that type.

If you click away the always ask, we will call xmms with that file, yes.  This
is not the same as launching ::ShellExecute() on the file, which is what we
would do if the "xmms" came from the Windows registry as opposed to from
Mozilla's preferences.

The fact that you get that dialog at all when the filename involved ends in .exe
is very odd to me and shoule be filed as a separate bug (file handling
component, severity critical) -- we should be forcing "executable" files to be
saved and not opened.

And yes, the fact that we are appending a .exe extension _is_ a bug, I agree
with that....

If you can point to a line of code that should be controlled by this pref, I'm
all ears... I cannot do so at the moment (for the dialog you mention).

    
    

    
  
This offending dialog appears because I use the configuration of a previous mozilla.  
Here I have chosen xmms for opening files with .pls. The MIME type  
"application/octet-stream" is then associated with xmms. When running the new mozilla  
build the ending .exe was added to the file but the MIME type is still associated with  
xmms. Though xmms can't open files with the ending .exe.  
  
The problem is that two different file types (.exe and .pls) have the same MIME type  
"application/octet-stream". In the preferences dialog you can add the ending .pls to the  
MIME type "application/octet-stream". Then mozilla doesn't add a .exe to the filename any  
longer. But .exe files are offered for opening with xmms, too. 
Yes, nowadays even Linux applications depend on filename extensions. 
Obviously mozilla does not add a filename extension when the ending is registered for that MIME type. 
  
The solution for this problem is more complex than I thought. I think it will be necessary  
to divide MIME types into subcategories according to the ending of the filename. Then  
there must be a helper application for each subcategory and not only for the MIME type. 
 
Or is there a own MIME type for mp3 playlists (pls)? I don't know. 
 
  
  

    
    

    
  
#78
> Or is there a own MIME type for mp3 playlists (pls)? I don't know.

<http://hostutopia.com/support/s058.html> says

> .m3u => audio/x-mpequrl

I wonder why it's called "mpequrl" though (as opposed to "mpegurl"). Also, this
is an "x-" mime type, e.g. a non-accepted / non-official one.

    
    

    
  
Detlef, as I said, "The problem is that our code tries to protect against
security issues when the helper comes from the Windows registry and as a result
fails when the helper comes from preferences".

If you have "pls" listed in preferences as an extension for
application/octet-stream and you are loading a url that has that extension and
that type, and you have a helper set in preferences for that type and we are
passing off ".exe" files to said helper, then something else must have broken...
But I note that when you add "pls" to this list in preferences things work
correctly.

application/octet-stream is the "No idea what this is" type and if you look at
comment #41 again, it says that we should never change the extension for this
type because of that.  Which would fix your problem.

As a note, you can make up your own application/x-pls-type type for pls
files....  There is no standard type for them.


    
    

    
  
Boris,  in fact there are two file extensions "exe pls" registered for one MIME type "application/octet-stream". And for this MIME type "xmms" is registered as helper. It is not possible to register helpers for extensions but only for MIME tpyes. But you can register several extensions for one MIME type. So here everything seems ok to me and nothing is broken.  Unfortunately you can't edit the extensions. You have to delete the whole MIME type registration to get rid off the extension "exe" once it is in the pref.  But I think I could file an enhancement "one helper per file extension" if there isn't already one.  

    
    

    
  
*** Bug 143748 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 143597 has been marked as a duplicate of this bug. ***

    
    

    
  
Just wanted to confirm this bug on 1.0 rc2 2002051009 on linux (mandrake8.2).

Reproduce -  just right click save as to download jhead binary from this web
page.  Only get save as  .txt file type.  This bug seems to have a lot of dups
and similiar problems occur in Bug#:96134 in the mail handler front end.


http://www.sentex.net/~mwandel/jhead/index.html

    
    

    
  
Why exactly is mozilla adding an extension to files in the first place; why
don't we just leave them as they are? I'm in windows and it's insanely annoying
to download zip files with the .gz extension being added or downloading .msi
files and having the .exe extension added.

    
    

    
  
> Why exactly is mozilla adding an extension to files in the first place; why
> don't we just leave them as they are?

Because it doesn't make sense to save an "image.cgi?id=1234" with a .cgi
extension if it was served as image/png.

    
    

    
  
In windows there is a drop down box for multiple extensions to files.  Why can't 
one be .<mimetype> and the other be "leave it alone" (aka *.*)?

    
    

    
  
That's bug 116951.  There is no reason.

    
    

    
  
*** Bug 143899 has been marked as a duplicate of this bug. ***

    
    

    
  
Using 2002-05-09-04/Win2000pro:
Handling of apparent extensions is really whacked out now.  

Using the FTP transfer, go to <ftp://ftp.tug.org/pub/tex/>;
select file{modes-3.3.mf} (for example), rightmouse, 'save-link-as';
the file chooser strips off the ".mf" arbitrarily and offers to save
"modes-3.3" with a "type" of all-files.

Mozilla should not be making *any* change in the file-name in a case like this!

    
    

    
  
*** Bug 144089 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 144113 has been marked as a duplicate of this bug. ***

    
    

    
  
To add some more pepper: When accessing vBulletin Forums (PHP), attachements
(ZIP Files) were saved newly (rc2) as "file.zip.php". That's annoying, because I
want the original filename "file.zip" and nothing php.
It also occurs with random unknown file types like this one: "milano_21712.ea1"
will be saved as "milano_21712.ea1.php". That's simple wrong !
Images (jpg), via "save image as..." are OK.
Mozilla 1.0rc2 build 2002051006 / Win2k

This problem was not there with my former Mozilla 0.9.9 Build 2002032408 but I
remember the same problem with Mozilla 0.9.2 or something like that.

Example Forum: forum.racesimcentral.com (needs login)

Please correct this. Thanks.

    
    

    
  
We know this is wrong.  Please don't comment saying so unless you have a
specific solution you propose ("don't touch extensions" is not a solution that
covers all cases), or better yet a patch...

    
    

    
  
If I read all the comments correctly, the most bugging thing about this bug is 
the automatic extension of filename if Mozilla has no "correct" extension. 
Wouldn't it help to remove this feature? I'm not into all the details, but if I 
readthe code correctly, the extention is added in the function 
getNormalizedLeafName. My suggestion remove these lines:

687   if (url.fileExtension != aDefaultExtension) {
688     return aFile + "." + aDefaultExtension;
689   }

Will this break something or is this just too simple?

    
    

    
  
That will make HTML pages get saved with filenames like "mozilla.org", which is
very poor.

It will also not address the issue of extension-magling when clicking on a
filename directly, since that does not happen in the JS code.

    
    

    
  
When downloading files in the OS/2 version there does not need to add .txt or
exe or any other extension (if needed I will add).  Please do not add etra
extension data this requires much extra, unnecessary work.

    
    

    
  
*** Bug 144334 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 144353 has been marked as a duplicate of this bug. ***

    
    

    
  
I agree with points 1,2,4,5, and 6 from Comment 46

I would agree with point 3 in 99% of cases; the exception being if text/plain
document is the output of a binary CGI script (ie foo.exe foo.dll etc) because
in those cases, I would like for it to be foo.exe.txt rather than foo.exe --
likewise I would like for text/html documents coming from foo.exe to be
foo.exe.html so that I can easily determine that the file on my hard drive is an
HTML document that came from a foo.exe script.  I disagree with comment 49; the
problem is not about having 2 extensions; the problem is about Mozilla adding
improper extensions.  It would be wrong to save text/plain or text/html output
as foo.exe because the OS would think it was an executable and that would be
wrong. Mozilla knows that it is transferring a text file and not a binary file
and so it should default to naming it appropriately.  Note I am only saying that
the extension should be added when the URL has a binary extension for a text
document; I do not think that the extension should be added if the URL has no
extension or if the URL has a non-binary extension or if it is a binary
transfer.  I would also like to see other script output saved in a similar
fashion (ie foo.pl.html), but I am not sure how Mozilla would determine whether
foo.pl was the Perl source file or the output of the Perl script being executed;
unless this distinction can be made, I would prefer to stick with foo.pl as the
default filename.

Regarding point 6, I would be in favor of either www.mozilla.org.html,
www_mozilla_org.html, or index.html.  Although my personal preference kind of
leans towards index.html, I think that would more confusing for users who are
not familiar with web development.  Using the domain name in the filename makes
it easier for users to find the file later and know what it is; naming them
index.html would also probably cause users to encounter a lot of "File already
exists" issues.  I have no problem either way regarding the use of dots or
underscores.

BTW, the reason that I came searching for his bug is because I just downloaded a
bunch of text/plain files ( *.java *.c etc) and Mozilla kept adding .txt on the
end.  It was very annoying.  I am on OS X, but I can not imagine anyone on any
platform wanting .txt added to the end of source code filenames. 

    
    

    
  
We also need to cope with the regretable fact that some servers that should know
better serve out X.tar.gz files (for example) as "text/??".  In such a case, I
don't expect Mozilla to know the difference; but *I* know what's going on and I
don't want Mozilla to overrule me.

In the Windoze File Chooser dialog, this would mean always having an "All files
(*.*)" choice in the "Save as Type:" list.  This choice explicityly means NO
filename mangling.

If anyone wants an example that should be embarassing to the Free World, prowl
around the CTAN network.

    
    

    
  
We shouldn't be doing anything with FTP, though, should we?

Go to:

ftp://ftp.software.ibm.com/ps/products/warpzilla

Can someone tell me why all these ZIPs are saved as EXE files?

    
    

    
  
> We shouldn't be doing anything with FTP, though, should we?

FTP is already in the list of things we should definitely *not* add extensions
to. See comment 46.

> Can someone tell me why all these ZIPs are saved as EXE files?

Well, because of this bug.

*Everyone: Please read comments 45, 46, 47, 48 before commenting.*

    
    

    
  
> ftp://ftp.software.ibm.com/ps/products/warpzilla
> Can someone tell me why all these ZIPs are saved as EXE files?

This is strange, but I have jsut tested my newly installed RC2 on "these ZIPs"
and they get zip extension suggested ... (under Linux). I am becoming puzzled.

    
    

    
  
*** Bug 144725 has been marked as a duplicate of this bug. ***

    
    

    
  
I suggest the following temporary solution, or hack: Make it configurable (by
prefs.js, no GUI necessary) wether to fixup extensions or not, with default
value "yes" on all platforms. If a user does not want to have file extensions
mangled, well, let him/her have his freedom. As soon as a better fix for this
bug is found, this hack can go away safely.

This workaround could even make its way into 1.0, if you really want it. I
dislike having to wait for 1.2alpha to see a change.


    
    

    
  
*** Bug 144879 has been marked as a duplicate of this bug. ***

    
    

    
  
Comment #46 asks for responses. I have one which does not appear to have been
made by anyone else. Point 3 of comment #46 lumps OS/2 in with Windows. OS/2
should not be included with Windows here, it needs to be treated like all the
others such as UNIX etc., so point 3 should read:

3)  Do no extension fixup for text/plain on non-Windows platforms, period.



    
    

    
  
*** Bug 145059 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 145197 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 145326 has been marked as a duplicate of this bug. ***

    
    

    
  
This bug is targeted for 1.2alpha?  So this means that the final 1.0 will ship
with this very annoying bug?  I don't think this is right, because 1.0 will
surely get a lot of press and if Mozilla "destroys" files by messing up the
extensions (as it does right now), it will surely get bad press.

I agree that this should be fixed and the former (that is pre 1.0rc2) solution
wasn't perfect - however I think that 1.0 should ship with the <1.0rc2 solution
and then the whole thing should be fixed, so to not get bad press.

    
    

    
  
Boris, what do you think? Would it be wise to disable extension-fixup completely
on the branch so 1.0 doesn't ship with this bug?

    
    

    
  
From a totally technical point of view (leaving aside religious considerations):

1)  The extension-stuff in contentAreaUtils.js can be disabled with no trouble.
2)  The extension-stuff in nsExternalHelperAppService.cpp is already disabled on
    everything but Windows (see bug 144923) and cannot be disabled on Windows
    due to bug 116938
3)  The last 5 dups are all due to the nsExternalHelperAppService.cpp code
    (that's the code that runs when you just click on a link; the other code
    runs when you do "save as" from a menu or context menu).

There is already a suggestion earlier in this bug on fixing the
contentAreaUtils.js code to be correct in almost all cases (simply disabling it
for text/plain and application/octet-stream types).  Please feel free to attach
a patch that either does that or disables the fixup completely; I'd be perfectly
happy to review the patch.  Please make sure that law@netscape.com and
ben@netscape.com are OK with your solution, however.

Alexander, your comment confuses me.  Presumably you read all the comments (and
hence comment 31)...  The bug is targeted at 1.2alpha because that's when Ben
thinks he will have time to fix it.  If you have time before then, the bug _is_
"helpwanted".

    
    

    
  
*** Bug 145754 has been marked as a duplicate of this bug. ***

    
    

    
  
1. This bug also affects links to files. When trying to open a file, it uses the
type associated with the assumed type. (Reproduce: go to
http://grayrest.com/moz/resources/icons.shtml and click the "download"link. It
opens the .xpi file as if it were an .txt file and that is the assumed (and
added) extension)

2. This bug also affects "save link target as..."

3. There should _always_ be an option to override mozilla's preferred extension
with your own, or none if wanted. I agree completely with the view in comment 45. 

4. I have not read all comments extensively, but somewhere read that windows
file-picker adds the extension on its own. It will not do this when file typ
"all *.*" is used. (Which is not an option at the moment)

5. Sorry for everything i said that has been said befor.

    
    

    
  
Every single thing you said was said before, except item #5.  Apology accepted.

    
    

    
  
*** Bug 145918 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 146152 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 146361 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 146605 has been marked as a duplicate of this bug. ***

    
    

    
  
Note that this got worse between 0.9.9 and 1.0rc1.  Before, .mp3 files with
correct mime type had the name left alone.  With 1.0rc1 and later, mozilla wants
to rename the following file to "a_sound.mp3.mpga":

http://www-eng.llnl.gov/documents/a_sound.mp3

That would explain the big surge in duplicates...

    
    

    
  
Can you take a look at your mime types file? Is this what it has for audio/mpeg:

audio/mpeg		 		 		 mpga mp2 mp3

This might be an easy fix.

The code in helperappservice only appears to grab one default extension 
(probably the first one) to check against.

there could be a number of extensions, and we should check against all of them 
before deciding to add one.

    
    

    
  
I'm stuck on a Windows NT machine, and I don't know where mime types are stored
on such an animal.  I've never fiddled with them, so if they're wrong on my
machine, I won't be the only one.

In any case, there's a more-agressive renaming of files going on that wasn't
there in 0.9.9.  Wish I could have control over this or have the old behavior back.

    
    

    
  
Reading a linux machines mime.types, I found other examples where the new
(1.0rc1 and later) behavior is causing problems:

Example 1:
  application/octet-stream        bin dms lha lzh exe class

all of these, Mozilla tries to force to .exe

Example 2:
  application/postscript          ai eps ps

...Mozilla tries to force to .ps

Just hunt through mime.types, find types with multiple extensions,
and you should be able to find 20 others.

It looks as though Mozilla now attempts to enforce The One True Extension on all
file-saves, even in cases where there are several legitimate extensions.


    
    

    
  
With Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0+) Gecko/20020524
on Win2000pro

I just ran into this in a place I really didn't expect it:  Received an e-mail
with attachments including a "profiling.diff" text file.  I wanted to look at
it, so I rightmoused and selected "Open"

I got a SaveAs dialog proposing to save the file as "profiling.diff.exe"!

That is very bad news

    
    

    
  
*** Bug 146839 has been marked as a duplicate of this bug. ***

    
    

    
  
One more time, for those too lazy to read the bug comments in this bug (but not 
too lazy to comment).  The behavior that is new since 0.9.9 was put in place to 
plug up a security hole in bug 116938.  That bug contains enough information 
(including pointers to the exact code to modify and suggestions for how it 
should be modified) for anyone with the time and will to whip up a patch that 
will prevent the unwanted behavior while not reopening the security problem to 
do so.

    
    

    
  
Re: Boris in Comment#123

OK, I looked at bug#116938.  The first thing I learn there is that I wouldn't
want to dive into code where the folks who get paid to do so say they "hate
working on this code."  The second thing is that, as in this bug, there are so
many arguments in different directions that clearly nothing will please all of
the people all of the time.  

Having said all that, Boris, I fail to see the identity in these cases. 
Bug#116938 dealt with cases where the URI said ".exe" and it was determined from
the MIME header to be inappropriate.  In fact, some of the commentary says that
text files aren't considered there.  Compare my comment#126 and see a case where
there is _no_ good reason to muck with the file type: it is just text and /I/
know what .diff means even if Mozilla don't!

We are better off if Mozilla simply doesn't mung the filename at all, ever.  If
the result is an ".exe", then just offer to save it [DON'T EXECUTE IT, PLEASE!].
 I doubt that Mozilla users are so uninformed that they wouldn't notice the
cases where that is incorrect.  I think the commentary on this bug, and on
bug#116938, is so long because y'all keep fixing a different problem than what
the users are complaining about.

    
    

    
  
<sigh>.. The file you mention in comment 126 is _not_ a text file as far as 
anyone but a human is concerned.  It was attached as application/octet-stream.  
Hence any software that is MIME-aware must consider it a binary file.

Please see bug 116938, comment 46 and the responses to that...

In either case, bug 116938 is irrelevant to the problem you describe with the 
mail attachment. That problem is a bug in the contentAreaUtils.js code, pure 
and simple.

Comment 128 was a response to comment 122.

Again, I am not defending Mozilla's current behavior.  I am also perfectly 
willing to point people to code, review patches, etc.  I just can't fix this 
myself till a few weeks from now....

    
    

    
  
*** Bug 146587 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 147139 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 147181 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 147185 has been marked as a duplicate of this bug. ***
Blocks: 111461

    
    

    
  
*** Bug 147477 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 147530 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 147569 has been marked as a duplicate of this bug. ***

    
    

    
  
Perhaps the Summary should be modified to reflect that the current behavior is
broken on things other than text/plain and application/octet-stream...?  Or
should I file a different bug for this (and how could it be phrased to avoid
getting tagged as a dupe of this one)?

Additionally, I don't see a description anywhere here as to what the "correct"
behavior is for other MIME types, i.e. audio/mpeg, application/postscript
(things where there's more than one legal extension).

    
    

    
  
What I think we should do there is the following

A)  If the extension on the file is in the list, leave it as-is (of course)
B)  If the extension on the file is not in the list, ...?

I'm divided about item B.  I feel we should consider appending it from the 
list, but I personally would dislike that behavior...  Also, "the list" on 
Windows is currently wrong (it only has one extension).  I just filed bug 
147679 on that.
Depends on: 147679

    
    

    
  
IMO the extension should never be changed.  If a page offers a file called
"foo.pdf" as application/octet-stream, then this is surely be done with a reson
- if not, then Mozilla can never know the real reason why this has been done. 
And it's also not Mozillas job to "fix" "broken" (here should be a definition of
what's considered to be "broken") things.

So the answer to both points is: Leave things as they are.

    
    

    
  
I'm going to pretend that the type you listed is _not_ application/octet-
stream, which is covered by comment 46, item 1.

If a page offers up a file called "foo" as application/pdf, what do we do?

If a page offers up a URL http://foo.com/bar/ with no filename that's a link to 
application/pdf content, what do we do (hint: naming it "foo.com" is bad.  
Naming it "bar" is also kinda bad). These cases are not broken.  The site does 
not need to work around the limitation of Mozilla and the OS Mozilla is running 
on...

In both of these cases _on_Windows_ we should append ".pdf".  I can see an 
argument for not appending the ".pdf" on Linux, except acrobat reader will not 
open such files then.  A Mac person should weigh in with the correct behavior 
on the mac.

There is also the question of what happens when the url already has an 
extension.  http://foo.com/myscript.pl that returns an application/pdf 
document, for example.  Saving it as "myscript.pl" is hardly a good option, 
especially on Windows...

    
    

    
  
My vote for what to do with http://foo.com/myscript.pl that returns an
application/pdf document would be myscript.pl.pdf for all three platforms
(provided of course that there is no content-disposition header as per comment
46).  If the webserver has gone to the trouble of identifying the document as
application/pdf then we should utilize the .pdf extension so that the user can
easily recognize it as a PDF document.  I can think of no logical reason why a
user would be opposed to having a .pdf extension on a PDF document.  What is the
reason to not do this on Linux?  Surely it would be confusing for any Linux user
(as much as it would for Windows or Mac users) to have PDF documents named with
any extension other than .pdf (ie .pl .dll .exe).  When I am using Linux and I
see myscript.pl in my directory, I expect it to be a Perl script that I can
open, read, and edit with vi.  When I am using a Mac, the file extension is
traditionally not as important because the embedded file type will indicate that
it is a PDF file, but still it would be better to have it named myscript.pl.pdf
than just myscript.pl -- especially now with OS X which makes file extensions
more important than the Classic Mac OS (particularly if you are using the CLI).

As for the case where the URL http://foo.com/bar/ with no filename offers up 
application/pdf content, I would vote for foo.com.bar.pdf as the Mozilla
suggested filename.  The user of course should be able to change it to whatever
they might want, but that would seem to be the most logical name based on the
limied info Mozilla is given.  Of course, ideally the web author would use a
content-disposition header so that Mozilla would not have to guess.



    
    

    
  
Yes, I agree, foo.pl.pdf wouldn't be bad.  But what about mime types which have
more than one extension (like image/jpeg -> jpg,jpeg, or postscript -> eps,ps)?
 Which one to chose?  Or what about text/plain?  foo.pl might actually be the
most correct file ending, since the to be downloaded file might be a perl
script, in which case a foo.pl.txt would be no good at all - same also for
visual basic scripts.  foo.txt.vbs *IS* good!  foo.txt.vbs.txt is no good.

I also agree that domain.com.bar.pdf is good for the http://domain.com/bar/
case.  but this rather quickly get's quite complicated.  what about
http://domain.com/bar/index.php/output?  domain.com.bar.index.php.output.pdf?  
Hmmm... A little long for my taste...  Here, I'd prefer output.pdf as the
suggested file name.

    
    

    
  
> application/pdf document would be myscript.pl.pdf for all three
> platforms (provided of course that there is no content-disposition
> header as per comment

I tend to agree that the behaviour should be the same for every platform. 
Otherwise it becomes inconsistent which Mozilla is not about.  (Unless there is
some compelling reason for it to behave differently on a certain OS - and I
don't see that here.)

> visual basic scripts.  foo.txt.vbs *IS* good!  foo.txt.vbs.txt is
> no good.

I think that if the file already has two extensions on it, a 3rd should not be
added - especially if the type you would want to set it to (.txt) in this
example is already one of the extensions.  (In this example, somebody already
changed it from .txt to .txt.vbs for some reason.)  For simplicity, I think that
extension mangling (or "correction") should only apply to a file with no more
than one already existing extension.

> which have more than one extension (like image/jpeg -> jpg,jpeg,
> or postscript -> eps,ps)?

Either just use the 1st defined extension, or the most common one (if that's
possible to determine).

> Or what about text/plain?  foo.pl might actually be the
> most correct file ending, since the to be downloaded file
> might be a perl script, in which case a foo.pl.txt

I think it's impossible to 2nd guess everything.  Pick the most common scenario
for text/plain and go with it, whatever the decision is.  There will always be
an exception here and I think it would get too complicated to try to accomodate
everything.

Besides, these are all just default filenames.  I am *ASSUMING* that when a
filename different than that server supplied is chosen by Mozilla that the UI
will say so.  Something grossly along the lines of  "The file you're downloading
was originally called X, but we suggest that you download it as ... ".  In any
case, the user should certainly be told by the UI what the original filename was
in order to help them override the Mozilla change if they wish.  (Having it not
mention the original name, despite offering the ability to change the default,
is not providing sufficient information.)

> domain.com.bar.index.php.output.pdf? Hmmm... A little long for my taste...
> Here, I'd prefer output.pdf as the suggested file name.

Agreed.  For this reason, the site name and subdirectories should be left out. 
Only the filename itself should be used.  Unless, of course, there *IS* only a
site name in which case that would be the exception.  (If there is a site name
with a series of subdirectories, but still no filename, then the last
subdirectory should be used.)  In other words, the most significant part of the
path.

    
    

    
  
Regarding mime types which have more than one extension, I do not think it
really matters which of the valid extensions Mozilla chooses as a default as
long as the user can easily change it.  Whether Mozilla were to use foo.pl.jpg
or foo.pl.jpeg,  either one would be better than an image named foo.pl.

As for plain/text documents, Boris addressed that in comment 46 and I
specifically  addressed the issue of lain/text documents being generated from
CGI scripts in comment 100.  I do not believe anyone here is condoning the
arbitrary addition of the .txt extension.  The only exception that I made was
for documents designated as plain/text that were coming from known CGI binaries;
obviously mistakes could be made, but IMO, the mistakes would only be
encountered when a website administrator had the wrong mime type configured.

I agree that names like domain.com.bar.index.php.output.pdf could be a bit long,
but again I really blame the issue on the website administrator who makes the
default page a PDF file without designating a name.  If the user thinks the name
is too long then the user has the option of changing it.  I would rather have
Mozilla default to a long descriptive name rather than a short name that will
have no meaning to me when I happen across the forgotten file next week.

    
    

    
  
Comment #144 has the perfect solution!
UI stating, this is the filename the website specifies, but this appears to be a
... (example: PDF) file. Giving the option to pick. Obviously this can be done
before 1.0. Is the current guessing strategy backed out from 1.0 yet? Its not
complete

    
    

    
  
More UI is almost never the perfect solution.... Where would this (rather
verbose) text go, for example?  This solution may work, but someone who knows UI
design should check it out. Marlon?  mpt?

As for 1.0, since no one bothered to create a patch, current branch is the same
as RC2, more or less (except for bug 144923 getting fixed).  At this point
checkins are no longer being taken for 1.0, as far as I can tell.  Draw your own
conclusions....

    
    

    
  
Like I've said before, please don't ever give me double extensions like
foo.pl.jpg or and especially not domain.com.bar.index.php.output.pdf. How often
would we then get an index.php.html? and how about pages generated by ASP, JSP,
PL, and all those other webscript languages? Surely I couldn't care less whether
the page was generated by JSP or PL or whatever. I'm only interested in the fact
the file is now an HTML file.
Besides, double extensions are bad on Windows, since Windows (especially 9x) has
a way of hiding known extensions by default, and this could be annoying, as well
as a security problem. If there is an index.php.html, the user will see it as
index.php. It is confusing to have a browser pop up then, instead of the
expected texteditor. Worse, what about index.html.exe? The user might think it's
just an innocent page, but it could be any kind of malicious code damaging the
system. 

We should prevent these kind of things by not ever giving files two extensions.
As I see it, there are two solutions:

1) Use underscores instead: We get index_asp.html and foo_html.exe instead of
index.asp.html and foo.html.exe.
2) Remove the extension it previously had: index.asp just becomes index.html

Personally, I would very much like to see option 2 happen, but option 1 is good too.

    
    

    
  
Trying to summarize everything (non octec/stream!)

Case 1)
If we are receiving a plain/text file with _no_ extension on a windows platform,
we should add the extension txt

if (mime=="text/plain" && os==windows && extension==null) {extension="txt";}


Case 2)
If we are receiving html in a file that has the extension of  the 
category html_generator, the current extension (php, py, asp, jsp) should be
replaced by html

if (mime=="text/html" && extension==html_generator) {extension="html";}


Case 3)
If we are receiving some other mime type and the file has _no_ extension (what
so ever!)  we should look it up in a table for mimetypes.

if (mime=="any/any" && extension==null) {
   ext == lookupExtensionOfMime(mime);
   extension=ext;
}


Case 4)
If we have no way of knowing the filename (http://www.foo.com/bar.php/fubar/)
then the filename should be www-foo-com_bar-php_fubar and the extension should
be determined as in Case 3.

if (filename == null && extension == null) {
   filename = convertAddressToFilename(inetAddress);
   extension = lookupExtensionOfMime(mime);
}


Case 5)
If we receive a file where the mimetype says it's image/jpeg but the extension
is pdf we should merely inform the person. We have no way of knowing which is
correct.

if ( mime != getMimeOfExtension(extension) ) {

   alert( "You are about to receive a file. Mozilla has been informed that this
file is of type "+mime+" but the extension is "+extension+". This means that the
extension might be wrong, but as Mozilla has no means to be certain of this, no
change to the extension will be made by Mozilla." );

}


    
    

    
  
On a similar note, these "mime type" <-> "extension" tables should be platform
specific.

Yes, that makes case 1 and case 3 are basically the same, sorry for the bloat :O/


    
    

    
  
c148:
> 2) Remove the extension it previously had: index.asp just becomes index.html

But that would also cause "LongLetterToMr.James" served as text/html to be saved
as "Letter to Mr.html", wouldn't it? Not good.

    
    

    
  
No, it wouldn't, but this brings to focus another problem. But let's address
your problem first:

Since the file LongLetterToMr.James already has an extension "James", but
"James" is not a know "html_generator"-type (html_generator types would be asp,
jsp, py, php etc) it would fall in to category 5. This means a warning would be
shown, but nothing would get done to the file itself (so the file would be saved
with the wrong extesion, yes, but there is no way for Mozilla to tell if the
mime type is correct and the extenesion is wrong or vice versa).

Here is a refined suggestion: 

We make a table for mime-types <-> extensions which is os specific and go
through the following hoops:


1) If this checks out, there is no problem: 
if( mimeType==getMimeFromExtension(extension) ) { return; } //all ok

2) If this checks out, we need to change the extension:
else if ( mimeType=="text/HTML" && isHtmlGeneratorExtension(extension) ) {
  extension=html;
}

3) If it hasn't got any extension, we look one up for it (this covers plain/text
since we would simply have the os specific extension (Windows .txt; Linux
nothing) added).

else if (extension == null && filename!=null) {
  extension=getExtensionOfMime(mimeType);
}

4) If we cannot determine the filename (eg. mime=image/jpeg
address=http://www.foo.com/bar.php/fubar/)
then the filename should be converted and the extension should be determined as
in Case 3. This would result in a filename www-foo-com_bar-php_fubar_index.jpeg
which is longish but not really ugly and absolutely correct.

else if (filename==null && extension == null) {
   filename=getFilenameFromInetAddress(inetAddress);
   extension=getExtensionOfMime(mimeType);
}


5)It has an extension and a filename but it doesn't match the mimetype, so we
simply post a warning and save "as is".

else {
  alert("See comment 149, case 5");
}


    
    

    
  
> If we receive a file where the mimetype says it's image/jpeg but the
> extension is pdf we should merely inform the person.

As I mentioned in comment 144, I'd been under the (it now seems) false
impression that we'd always inform people if the extension gets mangled.  If
it's mangled for security reasons, the text should read "File X has been renamed
to Y for security reasons."  But whatever happens, the user has the right to
know that the file the server offered was not named as it was received.  (In an
FTP listing there is no confusion, but in a link there could well be.)  I don't
believe for one minute that any solution proposed here will make every person
100% happy in all situations.  Therefore, in order to mitigate people getting
angry at Mozilla behaviour, some explanation should be offered.

    
    

    
  
> We make a table for mime-types <-> extensions which is os specific 

No, we do not.  We just uses the system MIME registry (registry on Windows, IC 
on Mac, mime.types and the GNOME/KDE/whatever mappings on Unix).

I have become convinced that we never want to append anything to text/plain, 
not even when it has no extension.

Making http://foo.com/bar into foo_com_bar is actually kinda hard to do, since 
there is no method of easily accessing the subparts of the path (short of 
writing a parser for it).  I also think it will create filenames that are far 
too long in practice... I would vote we leave that issue outside this bug for 
now (we currently use foo.com.something for such cases; changing the foo.com to 
foo_com is part of this bug, the rest is independent of it).

"Letter.James" arguably has no extension.... are there _ever_ files with 
extensions that are more than 4 chars?



    
    

    
  
#154
Yes, there are, such as the ".theme" (from "Microsoft Plus! 95") and ".mstheme"
(from Windows XP) formats by Microsoft.

    
    

    
  
for kicks what if i had Letter to Mr. TXT or Letter to Mr. HTM?

for fun you could also have movie.mjpeg (not traditional, but why not)

    
    

    
  
More observations (as though y'all need /more/):

1) We cannot count on being "on top of" the list of known HTML generators -- the
interpretation of the <script>?<query> form is completely up to the server: the
list of "types" is completely open; 

2) For base type "text" we should probably accept /any/ apparent "extension"
except one(s) known to be dangerous -- like ".exe"; 

3) It is _not_ Mozilla's mission to cover up deficiencies in Micro$oft's OS: any
user who hasn't set the Explorer options to reveal all extensions almost
deserves to be zapped. Yes, it is a security hole - but it is _not_ /our/
security hole;

4) Re <mailto:mikko.virkkila@mbnet.fi> in Comment#152, points (1) & (2) --
It seems reasonable to distinguish between "more precise" and "more general."
Something presented as "text/html" should be assumed to contain HTML.  The
windows filepicker or its equivalent should be defaulted to *.htm" but the
choice 'unmangled' (*.*) absoultely must be offered.  OTOH, "text/plain" is a
generic catchall.  My point (2) above applies, if nothing that looks conceivably
like an extension is offered, offer "*.txt" and "*.*".

5) Issues to do with stuff served as "Application/octet-stream" are another
kettle of fish.  But, again, we cannot possibly know all the potential types. 
How about offering (always) the "Save-it/Play-it" choice.  Perhaps that dialog
should contain the warning that playing anything received from an untrusted
source is a potential danger.  Directly executable files are always dangerous,
but there could be some pretty dangerous flash scripts out there for all we
know.  As a practical matter, if I am sent an ".exe" purporting to be a
self-unzipping file, my acceptance of the risk is a direct function of the source.

6) ABOVE ALL, lets stop batting it around like a beachball and DO something
conservative and darn soon!

    
    

    
  
Regarding your comment 4)
that is Bug 116951

    
    

    
  
Regarding comment 148 :

I agree that it is evil that Windows has a tendancy to hide extensions and it
annoys me to no end that Mac users are now offerred the opportunity to
experience that Windows flaw. :P  However, I very strongly disagree with the
idea that multiple extensions is a bad thing.  

I personally VERY MUCH LIKE to have files named foo.pl.jpg or index.php.html
because I DO want to know 1) that they were generated and 2) what language was
used to generate them.

I do not understand your question about "how often would we then get an
index.php.html?" when your stated preference is that such a file should be
renamed to the ever so much more common index.html -- what exactly is your point
in mentioning the frequency of occurance?  It seems to me that you are
expressing support for the more unique file naming that multiple extensions provide.

With the basis of comment 46, how are you suggesting that a Mozilla saved
document is going to end up index.html.exe?   Mozilla is not going to be
arbitrarily appending .exe to files.  One of the major issues about the change
that initiated the creation this bug was specifically about the issue of .exe
extensions to files; this proposed solutions to this bug are definitely not
going to create new instances of files with .exe extensions.   

There is nothing wrong with a file having 2 or more extensions.  

I personally do not want Mozilla to truncate ANY extensions from files that I am
downloading.  It is fine if Mozilla appends one on to the end (regardless of how
many it might appear to have) but I do not want it to automatically remove any 
file extensions that might serve to describe the file.

From comment 144 :
> if the file already has two extensions on it, a 3rd should not be
> added - especially if the type you would want to set it to (.txt) in 
> this example is already one of the extensions. ... For simplicity, 
> extension mangling (or "correction") should only apply to a file 
> with no more than one already existing extension.

If the web designer has created a script called dynamic.jpg.creator.pl that
dynamically creates jpg documents with the mime type image/jpeg then I still
would want Mozilla to append a .jpg extension rather than save an image file
with a .pl extension.  The fact that the script author used periods and "jpg" in
the naming of his script does not change the fact that I want appropriate
extensions on my files.

From comment 148 :

> 1) Use underscores instead: We get index_asp.html ... instead of index.asp.html

I am opposed to arbitrarily changing periods to underscores in existing
filenames.  Periods are a traditional separator on many unix systems.  I see no
reason to force a change to underscores for files being acquired through
Mozilla.  If you whoever makes the patch wants to have http://foo.com/ saved as
foo_com.html instead of foo.com.html then that is fine by me, but please leave
the periods in place for non-generated filenames.

Timeless, is your first question about filenames with spaces?  If so, I do not
see the point.  How do spaces affect extension handling one way or the other? 
As for the movie.mjpeg example, what is the appropriate mome type for that? 
Regarding your looking for work, how about working on a patch for this bug?  ;)

    
    

    
  
Well,

some things have changed in the RC3, at least Mozilla is accepting the changed
filename, if I decide to change it. This is already helping a bit...

    
    

    
  
Ups, I double check that and have to correct myself. It is still a problem,
sorry for the noise.

    
    

    
  
> Making http://foo.com/bar into foo_com_bar is actually kinda hard to do, since

That is a completely seperate discussion, in another bug, which is mostly
settled. foo.com/bar/ served as text/html should be saved as bar.html...
"foo_com_bar" is incredibly silly.

So please quit discussing what to do with host/directory names when saving, this
bug is only for storing MIME types in the file name extention on certain platforms.

UNIX has no database to do this, AFAIK. "mime.types" is a database for
converting extention to MIME type. It doesn't work properly the other way
around. Wasn't designed to do so.

There's only a few types we need to special-case. The ones we handle internally.
A few text types (html, xml, css, plain, js). The rest I believe we should
depend on the server to properly name.

    
    

    
  
*** Bug 148022 has been marked as a duplicate of this bug. ***

    
    

    
  
Lots of complaints about this in PR1 feedback, and this basically breaks saving
of many attachments and files for users.
Keywords: nsbeta1

    
    

    
  
*** Bug 148106 has been marked as a duplicate of this bug. ***

    
    

    
  
C'mon guys, this isn't rocket science: correct behavior is not to add any
extension to the existing file.  So quit trying to figure out how to make the
thing read minds or predict the future, and simply set to save the file AS IS,
like every other FTP manager on the planet.

    
    

    
  
#166
Grumble.

> C'mon guys, this isn't rocket science:

Unfortunately it is.

> correct behavior is not to add any extension to the existing file.

In a perfect world were there wouldn't be a conflict between mime types and
extensions, yeah.

> So quit trying to figure out how to make the thing read minds or predict the
> future, and simply set to save the file AS IS, like every other FTP manager on
> the planet.

This *isn't* FTP. It's HTTP. And HTTP has the sometimes inconvenient property of
redirecting features. You enter http://foo.com/bar and the actual URL on the
server is /usr/home/foo/files/http_files/bar/eek.html . The output file, in an
ideal world where every webmaster knows about the Content-Disposition header,
would be called "eek.html". In the actual world, a dumb browser would call the
output file "bar" though. And "bar" can't be opened on Win32, at least not for a
newbie.

So no, your "solution" just won't help.

    
    

    
  
absolutely right, dont f*ck with stuff you cant to right. 
atleast for 1.0 extensions should be left completly alone until its 100% sure
this works. this is toy stuff for the trunk but nothing that should be in branch. 
even after 1.0 i find this behaviour very doubtful cause it bears too many
sources for errors.

    
    

    
  
Seeing how this bug is going, I'm leaning towards agreeing with the "do nothing
- ever" approach.  Do no mangling.  Then, a separate bug can be opened for each
*specific* situation in which mangling is being considered and it can be
discussed on its own.  I think including *all* situations in which extensions
should/shouldn't be changed under a single bug makes it impossible to resolve
the bug due to dispute/disagreement.  Perhaps this bug could be changed into a
tracking bug for each of the specific cases, which should be opened separately.

    
    

    
  
http://bugzilla.mozilla.org/show_bug.cgi?id=120327#c101
as mentioned in comment 45 and as clearly stated in comment 101 and various
others the Option to save as "All Files (*.*)" is really important and should
always be available at least as an option.  

I would like to clearly state that the options to Save as All Files should
always be available for all mime types (i am not suggesting it be the default)
as this would always allow me the option of manually specifying exactly the file
extension i wanted.  
This should not intefere with anyone elses proposed solutions and i would really
really like to have it included in the next release, please.  I have not
explained this clearly enough.   (this option is not available for html in the
todays nightly build im am using, Mozilla/5.0 (Windows; U; Windows NT 5.0;
en-US; rv:1.0.0+) Gecko/20020529)

(i filed a bug marked as duplicate of this and i dont know how to stop from
getting mails about this bug, as my name is not on the CC list.  please mail me
directly if you know how i can solve this mailto:horkana@tcd.ie ).  

    
    

    
  
Alan:   (and all others)
Please read *all* comments before adding to a bug.  If there are too many
comments to easily read, then that's even more reason for you to think twice
before adding to it.  (since what you want to say has probably already been said)

What you have just said here is filed as Bug 116951
(which I have stated already in comment #158 )

    
    

    
  
*** Bug 148259 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 148297 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 148647 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 148670 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 148699 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 148739 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 148930 has been marked as a duplicate of this bug. ***

    
    

    
  
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

    
    

    
  
*** Bug 149264 has been marked as a duplicate of this bug. ***

    
    

    
  
I don't think mozilla should touch the original name. Many servers provide mime
types almost arbitrarily and we can't count on them or find any common pattern
in different servers behaviour. Some servers send any file that contains textual
information as text/plain even if it's not a "text document" and send files as
application/octet-stream even if it's an archive which MAY contain executables.
I encouneted servers sending .zip, .rpm or .deb files as
application/octet-stream, and mozilla tryed to save them as .zip.exe, .rpm.exe,
.deb.exe which is wrong on both Unix and Windows.

    
    

    
  
I agree with the last comment. I frequently see 'foo.rpm.exe' being suggested
when downloading with recent Mozillas. Mozilla should definately not be making
up its own extensions, especially when a file already has a valid extension.
Besides, .exe is meaningless on Linux - this just makes Mozilla look stupid.

A suggestion - why not just have a checkbox on the download dialog: 'use default
mimetype extension', which by default would start off unchecked. If you check
the box, then mozilla can try to guess what it thinks the extension should be,
and add it if necessary.


    
    

    
  
Comment 181: That has been pointed out a zillion times in this bug report
already. Read the existing comments before adding a new one!

Comment 182: No There Should Not Be A Checkbox. The fact that .exe is added on
application/octet-scream is a bug which should be fixed. There's no need to
provide a checkbox to turn the bug on again.

    
    

    
  
*** Bug 149519 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 149706 has been marked as a duplicate of this bug. ***

    
    

    
  
apologies for spam. with 67 votes and 62 dupes (9 of them in the last 7 days), 
I think this deserves a couple more keywords (not sure if 1.0.1 is appropriate -
 don't know the timescale for it).  it's not the end of the world, but it's 
very visible and annoying.
Keywords: mozilla1.0.1, 
          
            mozilla1.1

    
    

    
  
*** Bug 149783 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 149794 has been marked as a duplicate of this bug. ***
Blocks: 129979

    
    

    
  
*** Bug 150313 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 150324 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 150449 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 150613 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 150661 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 150856 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 142939 has been marked as a duplicate of this bug. ***

    
    

    
  
Mozilla 1.0 on Linux: Downloads file.h as file.h.txt, which is 
extremely annoying: Think of downloading a whole tree of files,
all of which have to be fixed by hand ! Again, don't touch 
extensions (at least on non-Windozes, I don't use Gates products), 
even if they are broken (it's a fault of the file server and should 
be fixed there). Mozilla NEVER can always guess right what purpose 
an extension serves for. 


    
    

    
  
*** Bug 151126 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 140011 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 151265 has been marked as a duplicate of this bug. ***

    
    

    
  
On comment #196, this behaviour of Mozilla is indeed more a server issue.

I've seen many downloads which to a .tar.gz file add .tar because it's
application/x-tar.

The following link however will result in a correct extension in the save as
dialog box:
http://telia.dl.sourceforge.net/sourceforge/pgpenvelope/pgpenvelope-2.10.2.tar.gz
I presume this will be true for all downloads at telia.dl.sourceforge.net

    
    

    
  
this whole thing is a server issue, but please, we cant reclaim the whole world
to configure their servers right. just look at the amount of dupes and votes.
just leave filenames alone!

    
    

    
  
On comment #200: No, this is definitively *not* a server issue. That an existing
file extension is used when it is the default extension for the respective MIME
type, has never been discussed here. Read the comments again.

The question was always: When a file has a MIME type and an extension that is
not among the known extensions for this MIME type, how should Mozilla behave? As
a special case: How should it behave when no extension is there? As another
special  case: How should it behave when no filename is there? The answers are
given thoroughly in the thread, no need to repeat them again.

    
    

    
  
I think you are bilding a Big Problem from nothing.
If i set to a web server a file to upload for anybody
or somebody, I know MUCH MORE BETTER what type of
extension should have this file. If i set .exe extension
to text file, that means i want it and nothing more!
Try to imagine that computer must help you, but not
think for you!!! I hate the programs which are more clever,
then myself...

I see this realy simple, but some people here do not...
Why????

To Mozilla Team: Please check it up...

    
    

    
  
*** Bug 151553 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 151744 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 151825 has been marked as a duplicate of this bug. ***

    
    

    
  
Well, I would personally choose to not to to mess up the original filename at
all. As said by some others, this is not Mozilla's problem.

The webmasters should be responsible for naming files correctly. If they can't,
they shouldn't write web pages (well, there are many other problems we can't fix
anyway, such us incorrect HTMML markup etc.). If they do, they should be
bothered by the visitors to fix those problems themselves.

Neither should Mozilla fix problems in specific (particularly Mickey$oft's) OSes
in this way.

Now, if you really need to take some care about the extension, why not make a
compromise? Simply adding a checkbox into the preferences dialog to toggle this
operation would make both groups happy. The only thing to solve is what exactly
is to be done withe the extension if the user chooses Mozilla to twiddle with it
(and of course you'll have to decide the default value for this option; but,
please, don't argue about this much, it can be changed!). ;-)

    
    

    
  
No. Adding a preference is definitly *not* an option. Such a preference would
confuse users unnecessarily and as mpt and hyatt pointed out repeatedly, the
preference dialog already is a mess of options nobody cares for.

The best solution for all problems is the one which doesn't confuse people who
don't use/understand Bugzilla. Most people who are adding comments to
discussions here could patch the code anyway.

The question is: is the user more confused by a saved webpage called index.html
or is he more confused if a file he just downloaded from the server is saved as
blah_name_stuff.mpg.mpeg.txt?

The real solution is: look what Internet Explorer does on Windows and emulate
that, because that is what the average AOL users expect today. Which also means:
don't fiddle with filenames on Unices or Mac OS, because that's what people
expect there. It's not even about reinventing the wheel. The problem is people
expect the wheel to look just like the wheels they are used to. The whole
discussion has no point beyond "do what Microsoft does". You can still change
from that when you have 20 million users which love to decode the meaning of
"W2P_EPS_SP_1290_SETUP.exe.txt" when they download printer drivers from the
Epson Website.

    
    

    
  
> The real solution is: look what Internet Explorer does on Windows
> and emulate that

> The whole discussion has no point beyond "do what Microsoft does".

No, that's totally wrong.  If Mozilla did everything just like IE because that's
what people were used to, then there would be no Mozilla.  The whole point of
Mozilla is NOT to copy IE blindly, but to only put things in that make sense. 
That's why Mozilla adheres so strictly to standards, despite however
incompatible that might make it with Web sites designed to work proprietarily
with IE - because we want to do it right.  So just because IE does it a certain
way is not at all a good reason for Mozilla to do it that way.

Now you can fairly argue that you think the way IE handles this particular issue
does make sense - but that's open for discussion.

    
    

    
  
*** Bug 152689 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 152595 has been marked as a duplicate of this bug. ***

    
  
Blocks: 1.1b

    
    

    
  
Hi,

I don't mean to be adding to this already bloated bug, but can someone direct me
to the location of 'contentAreaUtils.js' on Windows?

I would like to have a go at fixing it for my own benefit (I have no illusions
about providing one here, as I have no experience with mozilla, other than as a
user!)

But I cannot find it in my windows install of Mozilla 1.0 at all.  I might be
missing something, but I would have thought that .js logic for Mozilla would not
be compiled, and would be included somewhere in the install.

Is this an incorrect assumption.  If someone can at least direct me to some
documentation on navigating my way around the mozilla source / binary
distributions, I would be extremely grateful.

Thanks again for all your hard work

Cheers
Jason

    
    

    
  
It's in "comm.jar"; you can use winzip or some such program to get at it (.jar
files are compressed exactly like .zip files)

    
    

    
  
Hi,

Thanks for the info

Cheers
Jason

    
    

    
  
Hi,

I have done some initial investigation in the contentAreaUtils.js
file.

The getDefaultExtension(aFilename, aURI, aContentType) function
is where I have a few questions.

The statement:
   if (ext && mimeInfo && mimeInfo.ExtensionExists(ext)) {

... for .zip files at least never seems to get executed,
which I find strange, but what I find even stranger is
the content-type for which the mimeInfo object is
created.

I added the following code just above this line, and then
commented out the rest of the function.

// XXX: Remove Me!
  if(ext && mimeInfo)
  {
  	if(mimeInfo.ExtensionExists(ext))
		return ext;
	else
		return aContentType;
  }

The resulting filename (for myfile.zip) in the File Dialog is:

   myfile.zip.text-html

So when the mimeInfo object is created in the getDefaultExtension
function the 'content-type' is 'text-html'

I opened this zip URL manually and the 'Content-Type' header is
actually 'application/zip'

I am suggesting that some of the file extension functionality
would actually work again if the mimeInfo object in getDefaultExtension
was given the correct extension.

Unfortunately I am now getting into territory where I am really unsure about how
to proceed.

Note: I added the content-type as extension, because I am unsure how to
generate debugging information in mozilla javascript.  Anyone care to enlighten me?

Thanks again
Jason





    
    

    
  
Jason, were you using "save link as"?  That uses the HEAD method to get the
type, and a lot of servers unfortunately lie about the type when you use HEAD....

> how to generate debugging information

dump('The type: ' + aContentType + '\n');

(you'll need to enable dump output in debug prefs and make sure that you have a
console -- simple on linux, harder on windows, dunno about mac).

alternately, you could use alert() to alert debug info...

    
    

    
  
How right you are:)

I tried to download a zip file (using GET method) from
http://prdownloads.sourceforge.net/opendb/default2_0.50.zip with a test script
to view the headers, and the Content-Type was 'application/zip'

With HEAD method the same request returned 'text/html'

   Content-Type: text/html

The question begs (at least for me) why would Mozilla use HEAD if it is so
unreliable?  I realise it is fast, before you answer that :-)  But is this
the only reason.

By the way I was using 'Right-CLick' context menu 'Save Link As' on a Zip file url.

Thanks
Jason




    
    

    
  
Can you please take this discussion offline and stop spamming the bug?

    
    

    
  
*** Bug 153797 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 153958 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 146687 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 154022 has been marked as a duplicate of this bug. ***

    
  
Alias: exe-san

    
    

    
  
*** Bug 154153 has been marked as a duplicate of this bug. ***

    
    

    
  
This bug also affects local downloads (not served by an http-server) in a network or on a local computer. Because there will be no server I think local downloads should be allowed unchanged.

    
    

    
  
I've been coasting along, thinking how good Mozilla is, until
I came to download something...
In particular, I need to download a CDROM image file, with
extension ".ISO", linked on a HTTP web page
-- left-click, Mozilla *opens* it in another window.
-- right-click, Mozilla *insists* on downloading it as a text file.
No, no, no!

At least give us the option in the download dialog box to overrride
the default mime type.
And that stupid ".TXT" stuck on the end of everything... well, at
least I can take that off.



    
    

    
  
*** Bug 154406 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 154694 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 155004 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 155247 has been marked as a duplicate of this bug. ***

    
    

    
  
I read through roughly half the comments posted about this bug.  I only found
one mention of Internet Explorer, and it went something like "Mozilla should
mimic Internet Explorer because lots of people use IE".  I agree that's not a
_good_ policy at all, especially being that Mozilla is a cross platform browser
and IE is not, but I think it does bring up an interesting point.  How does IE
handle this problem?  I don't remember ever downloading a MSI file in IE and
having it end up with a .exe extension.  Does IE have access to some secret list
of mime types and extensions that Mozilla does not, at least under Windows?  I'd
say if Windows will calculate the appropriate filename for you based on mime
type and "original filename", then you should take advantage of this feature, at
least in the Windows port.

If not, would it be possible to add a section to the preferences dialog where
users could modify this setting?  You could have a list of all possible mime
types, and under each type, a list of all possible file extensions.  You could
then specify one as the "default" setting for the mime type.  That way, if I
download a file of type "application" and it ends in .msi, then I can add "msi"
to the list of allowed file extensions for type "application" under the
preferences dialog.  And if the mime type is "application" and the extension is
".txt" (don't know when this would actually happen, but let's assume it does,
just for kicks), then append an ".exe" to the filename.  I don't think this
would be too difficult to do.

    
    

    
  
Nominating for buffy.
Keywords: nsbeta1- → nsbeta1

    
    

    
  
*** Bug 152448 has been marked as a duplicate of this bug. ***

    
    

    
  
Ok, I just wanted to add my lines to this hopelessly long bug.

First, I mostly agree with the rules Boris lines out in comment #46. Then, a few
other suggestions:

1. When doing a "Save Page As", take something from the title, domain name,
document name (or whatever else usable there is) and just mangle it so it
doesn't contain dots (for example drop a three-letter extension and change other
dots to underscores). Then use the filepicker to add the appropriate extension
(.html, .txt, whatever). I'm not sure about platform differences here.

2. If there is no good way to guess a viable filename, don't. It is perfectly
acceptable to let the user make it up.

3. Let's do it. Boris' suggestions are good and they address the majority of
problems. The result may not be perfect, but the situation here demands action.
It seems that there are no better or more complete ideas, so it's pointless to
try squeezing out the perfect solution now. This bug is becoming impossible to
manage and it would be much better to fix this now and move the possible
remaining issues to new bugs.

    
    

    
  
> When doing a "Save Page As", take something from the title, domain name,
> document name (or whatever else usable there is) and just mangle it so it
> doesn't contain dots

But *why* should it be mangled to not contain dots?

    
    

    
  
For the poor ones getting confused about multiple dots. Well, for me either way
is ok.

    
    

    
  
*** Bug 155751 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 155727 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 155903 has been marked as a duplicate of this bug. ***

    
    

    
  
comment to #238
I am no shure whether bug 120327 really is a _duplicate_ of this bug, but may
be, bug 120327 is a special aspect of problems discussed here.

I agree with comment #45: It is a really _nonsense_, if mozilla changes (or adds
another) filname-extensions - especially filename-extensions of email-
attatchments, as described in
http://bugzilla.mozilla.org/show_bug.cgi?id=155903#c1
This problem is new, I tried with 
Mozilla/5.0 (Windows; U; Win98; de-DE; rv:1.0rc1) Gecko/20020417
and there (and in all earlier and may be, some later versions, too) everything
was correct and i was able to save the cemail-attatchment with it's original name

    
    

    
  
QUESTION FOR THE IN-GROUP:  Is there some reason, perhaps political(?), why this
needs to be discussed interminably; rather than implementing /a/ solution and
re-filing bugs if it needs to be improved?  This is getting rediculous!

    
    

    
  
QUESTION:  Is /this/ the bug responsible for getting the wrong mode sometimes on
ftp downloads?  I get *.exe files that can't execute; they are OK if I go to
console FTP and set 'bin' mode, so I suspect the Moz download manager is getting
some indication to set 'ascii'(?) mode.

    
    

    
  
Re: Comment #240 From David A. Cobb  2002-07-05 16:32
> QUESTION FOR THE IN-GROUP:  Is there some reason, perhaps political(?), why
> this needs to be discussed interminably; rather than implementing /a/ solution
> and re-filing bugs if it needs to be improved?

Because it looks like no real good solution has been found yet.

Re: Additional Comment #241 From David A. Cobb 2002-07-05 16:35
> QUESTION:  Is /this/ the bug responsible for getting the wrong mode sometimes
> on ftp downloads?  [..] 'ascii'(?) mode.

Unlikely, and even so, this is not a support group. In the future, please ask in
the user newsgroups instead.

    
    

    
  
> Because it looks like no real good solution has been found yet.

Not true.  See comment 46.  At the very least put that in place.  It's much
better than what we have now.  Once that's implemented and this bug is finally
closed THEN further bugs can be opened to address specific issues.

I agree with comment 233 and comment 240.  There is no reason why a patch (any
patch) cannot be at least added to this bug.  Is it simply that there's nobody
following this bug who knows how to write a patch to follow the guidelines of
comment 46?  I'm not knowledgeable enough to submit code on this.  It would be
pretty sad state of affairs if nobody else who's following this is either and/or
there ARE political reasons why Netscape/Mozilla is not assigning technical
resources to it.

So, please, somebody submit some kind of patch.  If it fails at the review
stage, fine.  But at least something will have happened.  Let's have SOME kind
of forward momentum here rather than the most duped and most contentious bug
around that does nothing but spin its wheels and get more and more people
frustrated...

    
    

    
  

      
      
      
      

        Attached patch
          
          
        very simple patch (obsolete)
        — 
          — Splinter Review
      

    


  
Out of sheer frustration over all the stupid "someone make a patch now!"
comments, I wrote a very simple patch. This is *not* a complete fix for this
bug -- far from it.

This patch makes us 1) not do any extension fixup for text/plain, 2) not do any
extension fixup for application/octet-stream, and 3) not do any extension fixup
for ftp:// URLs. It only affects the extension fixup that occurs when selecting
Save As on a pulldown menu or a context menu; it does not affect what happens
when you simply click a link.

    
    

    
  
*** Bug 155996 has been marked as a duplicate of this bug. ***

    
    

    
  


  
As Neil pointed out, it makes more sense to include the protocols that need
extension fixup than exclude those that doint.

        Attachment #90354 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 90370 [details] [diff] [review]
check for != "http" && != "https" rather than == "ftp"

r=bzbarsky.

Note that this does not fix the last 15 dups or so on this bug...  But it's a
start in the right direction.

        Attachment #90370 -
        Flags: review+

    
    

    
  
*** Bug 156212 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 156303 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 156544 has been marked as a duplicate of this bug. ***

    
    

    
  
Comment on attachment 90370 [details] [diff] [review]
check for != "http" && != "https" rather than == "ftp"

sr=brendan@mozilla.org, sr=ben@netscape.com too.

/be

        Attachment #90370 -
        Flags: superreview+

    
    

    
  
Comment on attachment 90370 [details] [diff] [review]
check for != "http" && != "https" rather than == "ftp"

Checked in on the trunk in an 11th-hour (literally) fix before the 1.1 freeze. 
I've asked for approval for the 1.0 branch.

    
    

    
  
Comment on attachment 90370 [details] [diff] [review]
check for != "http" && != "https" rather than == "ftp"

Please land this on MOZILLA_1_0_BRANCH.  Once there, replace the
"mozilla1.0.1+" keyword with the "fixed1.0.1" keyword.

        Attachment #90370 -
        Flags: approval+

    
    

    
  
Landed that on branch too.  Jonas, thanks for the patch!

Again, this does not fix the Windows-only issue with clicking directly on a
file...  So leaving this bug open.
Keywords: mozilla1.0.1+ → fixed1.0.1

    
    

    
  
I think it's better marking this bug as FIXED and opening a new bug for the
windows-only file-clicking problem.

    
    

    
  
I agree.  Start new, specifically targeted bugs at this point so as to cut down
unfocused discussion.

    
    

    
  
*** Bug 156718 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 156738 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 156906 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 156993 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 157189 has been marked as a duplicate of this bug. ***

    
    

    
  
The big number of DUPs shows that this bug must be fixed soon!

    
    

    
  
Agreed, I just noticed this bug, it causes major annoyances for vbulletin (PHP
based) sites with messages that have attachments.

    
    

    
  
An article on the IE approach to the problem of figuring out file types in the
face of unclear URLs and bogus mime types:
http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp

    
    

    
  
I hope no one is thinking of mimicking IE's broken behavior of scanning an
entities content to determine its type. This behavior has resulted in several IE
vulnerabilities (and its likely to continue to do so).

    
    

    
  
I would like to propose either a Java or XML based file of rules for naming. 
Using the rules from comment #46, and the consideration from comment #246, this
file would allow expert users a quick and easy way to customize the rule set. 
This file could also contain multiple rule sets, which could be selected from
the Mozilla preferences dialogs.  This would obviously be a long-term fix, and
not something that could be added quickly, but would ultimately allow everyone
to have their way.  I think a short-term workaround should be provided for now,
but this could be our final solution.

    
    

    
  
This is also important for the embedding effort. From the Latin America effort
we have a case with an important site serving pdb files. I am marking this
topembed. 
Keywords: topembed

    
    

    
  
*** Bug 158094 has been marked as a duplicate of this bug. ***

    
    

    
  
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1 → nsbeta1+
Whiteboard: Please read comments 45, 46, 47, 48 before commenting. → [adt3] Please read comments 45, 46, 47, 48 before commenting.

    
  
No longer blocks: 1.1b

    
  
Blocks: 1.1

    
    

    
  
*** Bug 158420 has been marked as a duplicate of this bug. ***

    
    

    
  
As to whether files should be automatically named on Windows, let's let the
numbers speak for themselves, shall we?

Of the duplicates filed, here are the platform stats:

Windows: 83
Linux:   14
OS/2:     2
Other:    1
All:      1
-----------
        101

Now, it might just be me, but I would say that when 83% of the duplicate bug
reports are coming from a platform that the reported behavior was aimed at, that
the reported behavior isn't desired on that platform.

Now, I expect some might think that this is to be expected since Windows has, by
far, the largest install base. But, if you take a look at mozilla.org usage
statistics, only 25.68% of the hits on mozilla.org are from Windows platforms.
It seems to me that if 25% or the users are generating 83% of the duplicate bug
reports, that this behavior is REALLY unwanted.

    
    

    
  
*** Bug 158503 has been marked as a duplicate of this bug. ***

    
    

    
  
Look UNIX people... this behavior is wrong on windows period. For example I just
went to download a quake 3 .pk3 file and it comes thru as .exe... major PITA.
Its simple: fix it, or people like me will have to go back to IE.

    
    

    
  
It is quite sad that this bug takes so long to discuss and fix. With reference
to Jakob Nielsen, Joel Spolsky, Hyatt and mpt (go mini-hyatt ;-) ), let's again
take a look at how Windows users want software to work (I'm talking about the
99% of potential users here, *NOT* those who know how to use Bugzilla !!!):

1. They expect any download to work right out of the box (which means: NO
preferences settings, NO .mpg.mpeg, NO .zip.txt, NO .exe.dtd).
2. If the browser can't figure out the right mime-type, they expect it to make
the same mistakes that Internet Explorer would make in this case.

Point 2 means that if we can improve on IE's mistakes that's a good thing, just
*don't* make any other or *more* mistakes. On Unixes users expect any program
not to fiddle with extensions at all, because usually Unixes are used by
experts, i.e. at least at the moment. Please recognize that even if we'd all
hate Microsoft: if Microsoft thinks that they can't figure out the right
mime-type without looking at the file's content, they're probably right. That
Microsoft then goes on to execute "known" content (opening WMP for .wavs for
example) is a problem we simply don't have to copy. Anyway, any kind of
behaviour that doesn't result in the right thing 99.9% of the time is simply
*wrong*. Microsoft got that right, we didn't. That's a fact.

Now, to fix this: let's evaluate if we can copy IE's strategy for recognizing
mime-types. If we can't do that now, postpone it until 2.0 and stop changing
extensions alltogether. In fact, after short testing with 1.0 and the current
patch, I'm pretty confident that doing nothing at all to the extension would
more often result in the right file extension than what we do now. I think
comment 271 is self-explanatory.

    
    

    
  
OK.  I seem to have forgotten to add a comment number to the status whiteboard.

Summary:
The Windows behavior that people are bitching about is _not_ due to a desire to
be helpful on our part.  It's due to the need to prevent a remote-execution
security attack of exactly the sort IE suffers from (see comment 128 and comment
114, which I'm sure everyone has read before they commented).
Whiteboard: [adt3] Please read comments 45, 46, 47, 48 before commenting. → [adt3] Please read comments 45, 46, 47, 48, 275 before commenting.

    
    

    
  


  
This is a proposed "fix" for the Windows problems that have been getting
reported so much. It does not fix _everything_ by any means, but it should fix
the '".exe" getting added to everything' problem.

Now I'm one of those Unix users being railed at in comment 273, so it would be
very nice if one of these incredibly helpful Windows people cced on this bug
would:

1)  Make sure the patch builds (it should, but one never knows).
2)  Make sure it actually helps the problem in question (again, it should).
3)  Make sure it does not regress bug 116938 in any of its incarnations (I
    _think_ that's the case, but the ways of ::ShellExecute() are somewhat
    mysterious to me).
4)  Test the hell out of it to make sure it does not break anything (this part
    will take some creativity; I have nothing to suggest here beyond trying
    every aspect of opening with apps and saving by clicking on a link
    directly).

If those are done Now, and the patch passes the above four tests, there is a
chance this can land in 1.1, maybe. Drivers certainly want it....

Oh, and some code reviews would be nice too while people are being all helpful
like that.

        Attachment #74523 -
        Attachment is obsolete: true

        Attachment #90370 -
        Attachment is obsolete: true

    
    

    
  
Forgive my ignorance of Mozilla code, but is the security risk in bug 116938
that a file named foo.exe could be sent with a content-type like audio/mpeg, and
thus cause an exe to be run on the user's system? If that is an accurate
description, I see no issue that requires file extensions to be added to
downloaded files. If that is how it works, there is a flaw in Mozilla's handling
of files from the network, and it shouldn't be covered up by introducing further
annoying behavior on top of the already bad handling.

Mozilla should never be doing a shellexecute on any file for this exact reason
(and that's the only way I know of to get an exe to run under these
circumstances). Mozilla should work the way NN4 does in this respect. Mozilla
should only see if there is an application registered to handle the current
MIME-type, and if so pass the application the temp file (application.exe %1). If
there is nothing registered pop the unknown content type box with an offer to
find an application or save it.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Better wallpaper (obsolete)
        — 
          — Splinter Review
      

    


  
I think we need the check on the GetMIMEInfoForMimeTypeFromExtras() call
too....

        Attachment #92180 -
        Attachment is obsolete: true

    
    

    
  
Jonas Maurus:
> let's evaluate if we can copy IE's strategy for recognizing mime-types

That does not need to be evaluated. IE's behavior is a direct violation of the
HTTP specification. End of story.

    
    

    
  
> is the security risk in bug 116938 that a file named foo.exe could be sent
> with a content-type like audio/mpeg, and thus cause an exe to be run on the
> user's system?

Yes.

> I see no issue that requires file extensions to be added to
> downloaded files.

Well, in the above case we would name the file foo.exe.mpg and send it off the 
the MPEG player...  This seems like a better solution than bailing for reasons 
that should be obvious from the opening comment of bug 116938 (where the 
website is _not_ purposefully giving us a .exe filename).

> there is a flaw in Mozilla's handling of files from the network

Please enlighten me as to the correct handling of the case in bug 116938.  
Preferably by personal email or in the newsgroups.

I don't know why the Windows code uses ShellExecute() and it seems odd to me 
to, but I don't know the issues involved.  Please file a separate bug on the 
File Handling component to remove the use of ShellExecute() if you know for a 
fact that one can always get the actual helper (as opposed to a flag that 
says "something is registered to handle this") from the registry.

In any case, that would be a major change that cannot possibly get the testing 
it needs by tomorrow or so.... (which is when I would like to land this 
patch).  No one's proposing this as a permanent solution to the problem, if you 
noted.

    
    

    
  
In the case of a file of a non-binary MIME type with an executable's extension,
it seems that passing the temporary file to the helper application would allow
the helper application to determine if the file is of a valid type, and if not,
it would not execute the binary.  I know that if you pass a binary file with an
'exe' extension to Winamp then Winamp will find that it is not a valid type and
will not execute the binary file.  Additionally, by adding the option to set
helper applications based on both MIME type and extension, as was suggested in
an earlier comment, an additional level of security would be added to prevent
the file from being sent to the helper application in the first place.

Should the user choose to use a right-click to save the file, bypassing the use
of the helper application, then it really is up to the user to decide if it is
wise to open the file using a shell or file browser.  A person providing a
malicious file on their server could identify the file as a binary application
and the user could be told (by the serving page) that the file is an audio or
video file.  When the user saves it, it would be saved with an 'exe' extension
and the user would use their filesystem browser to open the file, without
Mozilla ever having a chance to warn them.  Additionally, if a user chooses to
download a file with a MIME type of audio/mpeg, and the Save As dialog shows the
'exe' extension, it is beyond the powers of Mozilla to protect this user if they
do not realize they shouldn't open the file using their filesystem browser. 
However, if Mozilla is appending '.exe' to the end of any file with an
application/octet-stream MIME type (which is how this bug started), then the
server could rename a malicious program from 'virus.exe' to 'music.mp3', and
Mozilla would slap the extension on the file for the malicious server, aiding
them in infiltrating the user's system.  Talk about automated, they could set up
their compiler to build to a directory on their server, have PHP rename the file
to serve it to the user, and Mozilla would restore the executable extension when
the user saves it, then the user would run the file, and suddenly Mozilla would
become an accessory to the crime.  This might even get a more experienced user
who looks in the status bar for the filename before choosing to save it, then
fails to examine the Save As dialog before saving the file to disk.  A correctly
set icon and hidden file extensions would leave the user completely in the dark
about they hell they are about to release on their system.

Because of the assortment of file types that can be used to provide malicious
content, it is not reasonable to believe that we can protect the user in all
circumstances.  Even if we are not adding binary extensions to files, a batch
file or shell script can be just a damaging, and would avoid the protections
discussed so far.  It might be in the best interest of the Mozilla community to
provide the user with some variety of warning or information brief that informs
them of possible means of attack that can be used by a malicious server.  If
such a warning is properly labeled, and is provided at the right time, such as
installation, users who are not already aware of the risks would likely read the
material.  Knowledge is power, and the only way to make the internet safe for
the general population is to provide them with knowledge of how to protect
themselves.  I've been receiving far fewer complaints from users due to
malicious e-mail attachments because the general public is becoming more aware
of the risks, and is using more caution.  On an operating system that relies on
extensions, the user needs to be aware of what they mean.  We do not need to
fuel the ignorance by copying Microsoft and hiding the truth from users.

The actions outlined in earlier comments (such as those listed in the Status
Whiteboard) are suitable and need to be applied as quickly as possible. 
Vulnerabilities will exist no matter what we do, but we can improve the situation.

    
    

    
  
Please see bug 158623 for discussion about the use of ShellExecute().  Please 
limit comments in that bug to technical suggestions on what can be done; 
discussion on what _should_ be done should go to the newsgroups.

    
    

    
  
Written out of sheer frustration as well:

I fully understand all the arguments "make Mozilla work the way users expect
software to work". But let me look at the whole matter from the oposite point of
view:

Making software do decisions for the users sometimes leads to the situation,
when the applications are more clever than the user. Maybe all the ordinary
users will like it, but more experienced users hate it! If it's really necessary
to make the software work this way, it should be strictly optional with an
option to disable it (if you don't want to add a preferences option, what about
a line that could be added to "pref.js"?).

Too clever software opens several security holes (let's see M$IE and Outlook
Express!).

Now, I'm using Mozilla on Windows and Mozilla on Linux and Mozilla on ... But
it's always Mozilla! The same browser, ain't it? In all cases from mozilla.org,
eh? Even the Windoze version, it's not from Mickey$oft! So I could expect it to
work the same on all platforms.

And probably the last argument: Do you think people switch to Mozilla just for
pleasure? (At least those on Windows...) It's slower than M$IE, eats more memory
(sometimes even whole the rest) and generally needs much better machine than
M$IE. No, I think they do so because they believe Mozilla is far superior to
M$IE in several ways. That includes they believe it won't have IE's bugs and
other annoying behaviour.

If you really must mess up with the extensions, why the hell can't this be
*optional*?? If you don't wanna ad another options into the preferences dialog,
can't there be at least that "prefs.js" line? (However I still *do* insist on
that the web authors and WWW servers administrators are responsible for proper
file namings and MIME types, this is not a thing browsers should take care of.)

Thanx for consideration. This is the last comment from me on this bug. I just
hope to not to have to patch the code of each new version to get rid of some
unwanted features...

    
    

    
  
Perhaps someone could explain my apparent confusion ?

If I generate:
   ...
  Content-type: application/octet-stream
  Content-Disposition: attachment; filename=testform1.asc
  ...
I expect a download dialog box prefilled with the file name "testform1.asc". No
additional extensions or interpretations or guesses based upon sniffing the 
actual content data. That's what Netscape 4.7x does. And that is why I can't use 
IE because it insists upon doing something different than specified.

I don't understand why this is an issue?

Alternatively, is there another way to specify: "Download this file with this 
name"? 

Your indulgence is appreciated.



    
    

    
  
Having read all the comments, it just occured to me that the main thing the
securty fix is trying to do it stop programs from opening improperly. While the
problems users are having are programs saving improperly. 
The fix is to completly ignore the mime type when saving files, and pay
attention to the mime type for opening of files. It seems a rather easy fix,
impliment all the filetype sanitization you want, for when the browser is
launching the file itself. For when the file is simply going to be saved to the
harddrive do EXACTLY what this browser did before all this mess. That doesn't
seem so hard really?
Anyone up for opening a second bug requesting this "feature?"

    
    

    
  
I have been asked to comment. This will be my only comment in this bug report.
If anyone who wants to fix the bug (rather than whining about it) wants more
from me they can ask me by e-mail or on IRC. I think this should be marked as a
duplicate of a fresh bug report which doesn't have so many useless comments.

From a usability point of view, I can offer the following.
1.  Any solution which adds a pref is wrong.
2.  Any solution which adds extensions to any file on Mac OS 8/9, ever, is
    wrong. (I would suggest the same is true for Linux.)
3.  Any solution which adds `All Files (*.*)' to the `Save as Type' menu is
    wrong. (The stupidity of suggesting that `All Files' is a file format
    outweighs the importance of consistency with other programs.) I suggest
    `None (*.*)' instead.
4.  Any solution which adds a whiny alert or explanation in the filepicker is
    wrong. (`The suggested extension of this file doesn't match its MIME type,
    so I'm going to complain to you about it, even though you have absolutely
    no idea what a MIME type is and really don't give a crap.')

From a technical point of view, I know much less than Boris about just how often
server-provided hints of Content-Type and Content-Disposition are accurate. But
I expect that bug 116951, bug 147679, and this bug as currently summarized
(leave text/plain and application/octet-stream alone) will solve 99 % of cases.

    
    

    
  
It really looks ridiculous. When broser transforms .tar.gz to .tar.gz.tar, .zip
to .zip.x and .rpm to .rpm.exe (all that happened to me on Windows) it is wrong
on ANY platform. So I agree with comment 285, when file is going to be saved,
don't touch the name.

    
    

    
  
I agree with the last comment. When I download files, the first extention is
always correct, but then mozilla always adds another extention making the file
be identified by the OS as the wrong type, and its more or less a big
inconvenience for me to fix it. I think what would be a good idea for now, is if
we had a toggle to completely disable mozilla from renaming file downloads at
all, and since it is a security risk, it should be noted to the user when
disabled, and its up to the user to know how to make the browser properly handle
executable files. Support for the proper naming of files could then be added in
a later release since everybody is in disagreement of how exactly they should be
handled.

I like this browser a lot better than IE6, much faster and has a simpler, more
strait forward interface, I don't want to switch back :)


    
    

    
  
> 1.  Any solution which adds a pref is wrong.

I disagree.  One of my biggest complaints about IE is that there is nothing you
can do about behavior you don't like.  I don't really care how the option is
enabled/disabled, but it should be possible to change without recompiling.

>2.  Any solution which adds extensions to any file on Mac OS 8/9, ever, is
>    wrong. (I would suggest the same is true for Linux.)

I believe this is true for all operating systems except for Windows, as Windows
is the only operating system (that I am aware of) that uses extensions to
determine file type in all cases.

>3.  Any solution which adds `All Files (*.*)' to the `Save as Type' menu is
>    wrong. (The stupidity of suggesting that `All Files' is a file format
>    outweighs the importance of consistency with other programs.) I suggest
>    `None (*.*)' instead.

'None' would be (*) instead of (*.*).  We're actually talking about exclusion
filters, so 'All Files' is accurate.  You could reasonably have both, but
Windows doesn't like files without extensions.  I guess a filter with 'No
Extension|*|All Files (*.*)|*.*' would be appropriate, though.

>4.  Any solution which adds a whiny alert or explanation in the filepicker is
>    wrong. (`The suggested extension of this file doesn't match its MIME type,
>    so I'm going to complain to you about it, even though you have absolutely
>    no idea what a MIME type is and really don't give a ****.')

I agree, but I also think showing the MIME type in the dialog somewhere would be
a good idea.  Since we're using the Windows filepicker (and not a custom dialog)
we could probably insert it into the titlebar most easily. (Something like 'Save
application/octet-stream' instead of the standard 'Save As')

As for ignoring filenames when saving, this could also leave systems vulnerable.
 Although Mozilla wouldn't be launching the application, the user probably
wouldn't be checking the extension versus the actual file type (at least this is
true of Windows users, where it really counts, because they don't by default see
the extension).  The argument at hand here becomes whether or not it is
Mozilla's responsibility to protect the user from themselves.

In response to comment #284, read the Status Whiteboard.  In comment #46, see
point #4.  Also, application/octet-stream is the wrong MIME type for '.asc'. 
the 'asc' is for ASCII, which is a text/plain data type.  If you use one of the
patches attached to this bug, or consider the suggestions in the comments listed
by the Status Whiteboard, you'll find that we are already aware of the problems
associated with this and are working on finding a solution suitable for everyone.

Again, a temporary solution is necessary, since the best solutions suggested
will take time to implement.  I am in full support of the idea of removing the
fixup code, or providing the option to do so, until we can implement one of the
more complex plans.  A risk exists as is, and without a proper solution, a
security risk is virtually unavoidable, so lets make Mozilla a bit less of a
pain in the ass to use for the experienced users that currently make up the
largest portion of Mozilla's user base.  I, too, use Mozilla on my Windows,
Linux, and Mac systems, and I want consistent behavior.  I want to get rid of
the fixup code until extensions can be decided properly for Windows.  I can't go
back to I.E., and I really don't want to see Mozilla become a cross-platform
version of it.  There's a reason it has earned the parody-name 'Internet
Exploder' among those of us who know how to handle extensions and don't need our
browsers to think for us.

    
    

    
  
To comment 289...

>>2.  Any solution which adds extensions to any file on Mac OS 8/9, ever, is
>>    wrong. (I would suggest the same is true for Linux.)

>I believe this is true for all operating systems except for Windows, as Windows
>is the only operating system (that I am aware of) that uses extensions to
>determine file type in all cases.

NO!!! Patric you think wrong!
It's not your deal, what extension i use for my file.
It's not a deal of Mozilla also!
There are a lot of examples where M. rename some files
but it was no reasons and no asks for it.

And the main thing at the end. Can you imagine
that the human a little bit more clever then a computer?
Please, give him a chance to be more clever...


P.S. I realy can't understand the people who
think like you. I'm very interesting why some
people think so. Have they never seen a real
computer..? I have no other ideas... and
what about you?

    
    

    
  
Patrick stated in comment #289:

"...Also, application/octet-stream is the wrong MIME type for '.asc'. 
the 'asc' is for ASCII, which is a text/plain data type."

I see now the source of the dispute however I disagree with it.

Mime type is an independent statement from file name/extension. The fact that MS 
Windows attempts to make such an association is irrelevant. A dot.name commonly 
referred to as an extension is still just a file name.

Netscape 4.7x works correctly now in Windows, it offers a download dialog box 
and prefills the filename as defined. IE on the other hand refuses to download 
the file and displays its contents on screen instead. This is incorrect and 
undesired.

Is there an alternative way to issue a directive to download a "text" file with 
a designated name?

    
    

    
  
As for naming files according to content-type, make something idiot proof, and
only idiots will use it. What users do with a file after they have downloaded it
is none of Mozilla's business.

See bug 158623 for the solution to the security issue presented by this bug.

    
    

    
  
In response to comment #290:

The extensions you choose to use for your files are of no interest to me, or to
other Mozilla developers, but the extensions servers use for your files are
critical on Windows.  We MUST change extensions in some cases to avoid serious
security flaws.  I have difficulty understanding your english, but you do seem
to understand that it is important for people to think for themselves, rather
than having a computer do it for them.  If you review earlier comments, you will
see that we do wish to give the user the option to override Mozilla's behavior,
but since Windows relies on file extensions, and not all servers provide the
correct file information, we have to ensure that the file placed on the user's
hard drive has the correct extension.  This ensures that files behave as they
should and that we are not leaving the system vulnerable with a simple, but very
serious, flaw.

In response to comment #291:

If it were easy enough to tell Mozilla what extension to use, I imagine more
servers would use the method, and this bug wouldn't be quite as popular.  With
any of the proposed fixes, you would be able to use the 'Content-Disposition'
technique, in combination with a correct source filename, to specify the desired
extension in all cases.  Until such a fix is released, keep your name on the CC
list, because you're going to have to ride this one through with the rest of us.
 There is currently no way to bypass this bug from the server.  As for Internet
Explorer's behavior, that's Microsoft's bug, and I recommend writing them about
it.  I'm not sure if Internet Explorer still works like it used to, but you
might instruct users of your server to right-click to save the file or to hold
shift and click the link.  It still works on Mozilla, and I assume that it still
works on IE, too.

    
    

    
  
To Patric Barners:

> The extensions you choose to use for your files are of no interest to me, or to
> other Mozilla developers, but the extensions servers use for your files are
> critical on Windows.

Oh, really? - ...Probably you are right. I've got a lot of problems
on Windows with Mozilla's download...

>We MUST change extensions in some cases to avoid serious

Can you relay me to some USA laws about it :-/

> security flaws.

What kind of flaws you mean? Should i repeat that it is not Mozilla's deal what
user make with downloaded files?

> I have difficulty understanding your english, but you do seem

I'm sorry. I was very angry... - too imotional...

> provide the correct file information, we have to ensure that the file placed
on > the user's hard drive has the correct extension.  This ensures that files

But why in most cases it does wrong????????????????
Why do i get always incorrect extension or real file name?
Could you probably share with me the secret algorithm, which
cans determinate what kind of extension should have some file?
If you will, i will pray for you...

> behave as they should and that we are not leaving the system vulnerable with a
> simple, but very serious, flaw.

The most mistake is thinking that unexpected behaviour is correct.

And may be one advice at the end.
Please, don't think about Windows
think about Mozilla...


    
    

    
  
The following is the basis for my understanding that the combination

  Content-type: application/octet-stream
  Content-Disposition: attachment; filename=testform1.asc

should result in a download dialog box without any file name alterations.

    ------------

Hypertext Transfer Protocol -- HTTP/1.1

http://www.w3.org/Protocols/HTTP/1.1/rfc2616.pdf

7.2 Entity Body

...Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type 
header field defining the media type of that body. If and only if the media type 
is not given by a Content-Type field, the recipient MAY attempt to guess the 
media type via inspection of its content and/or the name extension(s) of the URI 
used to identify the resource. If the media type remains unknown, the recipient 
SHOULD treat it as type “application/octetstream”. ...

19.5.1 Content-Disposition

The Content-Disposition response-header field has been proposed as a means for 
the origin server to suggest a default filename if the user requests that the 
content is saved to a file. This usage is derived from the definition of
Content-Disposition in RFC 1806 [35]. 
content-disposition = Content-Disposition" ":" disposition-type *( ";" 
disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
An example is
Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path information 
present in the filename-parm parameter, which is the only parameter believed to 
apply to HTTP implementations at this time. The filename
SHOULD be treated as a terminal component only. If this header is used in a 
response with the application/octet-stream content-type, the implied suggestion
is that the user agent should not display the response, but directly enter a 
‘save response as...’ dialog.


    
    

    
  
Re comment 295:

Yes.  You are correct.  No one's disagreeing.  The problem is that in the
current architecture "save" and "open" follow the same execution path for quite
a while before diverging (this architectural issue is discussed at length in
other bugs; do _not_ discuss it here, please).  The fix for bug 116938 was
inserted at a point in the execution _before_ the two execution paths diverge. 
See bug 116938 comment 46, through bug 116938, comment 60 (and note that this
was happening as we were trying the security hole in time for RC2).

Again, everyone agrees the current behavior sucks.  Some people are trying to
find time to fix it.  Some are just whining and haranguing.  If this is _really_
bothering you, read this bug and bug 116938 and move the problematic code so
that it does not trigger in the "save as" case!  Otherwise, you get to wait
until someone else skips on a few nights of sleep and does something about the
bug.  In short, put up or shut up.

This is my last comment on this bug that is not directly related to a patch. 
From now on, people can make inane and pointless comments amongst themselves all
they want without any injection of reason, sanity, facts, or reality as far as
I'm concerned.  Thank you, all.
Keywords: adt1.0.1

    
    

    
  
*** Bug 158865 has been marked as a duplicate of this bug. ***

    
    

    
  
Comment on attachment 92190 [details] [diff] [review]
Better wallpaper

r=law

        Attachment #92190 -
        Flags: review+

    
    

    
  


  
I had to make two small changes to the win/ part of the patch to make it
compile:
1. Include plstr.h.
2. Change aMimeContentType to aMIMEType to match the function parameter name.

To test the patch, I told my local web server to serve several test extensions
with specific mime types:
.app application/octet-stream
.mmm video/mpeg
.baz application/baz

on server		 .app			.mmm		   .baz 
type in address bar	   .app (was .app.exe)	  .mmm.mpeg	     .baz
click link		   .app (was .app.exe)	  .mmm.mpeg	     .baz
save link target as	   .app 		  .mmm.mpeg	     .baz

I'm not sure that my tests cover both parts of the patch.

        Attachment #92190 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 92444 [details] [diff] [review]
same patch with minor changes to make it compile

r=me on Jesse's "make it compile" changes (and r=law on the rest).  Jesse,
thank you for testing...

        Attachment #92444 -
        Flags: review+

    
    

    
  
Comment on attachment 92444 [details] [diff] [review]
same patch with minor changes to make it compile

sr=jag

        Attachment #92444 -
        Flags: superreview+

    
    

    
  
Comment on attachment 92444 [details] [diff] [review]
same patch with minor changes to make it compile

a=asa (on behalf of drivers) for checkin to 1.1

        Attachment #92444 -
        Flags: approval+

    
    

    
  
checked in on trunk; asking for branch approval.

    
    

    
  
Ok, The JPEG bug on my macine is fixed. (WIN98SE) What I have done is remove
Mozilla with the Add/Remove util. Deleted the folder. Went to the
Windows\users\mozilla\preferences\(MyUserName) folder and remove anything with a
JS, rdf, dat, db, and anything else that I didn't like. "LIKE WHAT THE HELL IS
COOKPERM.TXT" file doing in there anyway? 
Mozilla now loads faster, it d/l exe files AS *.exe files and all jif's jpg's
and everything else works REALLY well. It also loads web pages much faster than
it did before. NICE!
The only thing I found was I had to set up my email prefs again and for the
Server Settings I had to use earthlink.net instead of mail.earthlink.net.
I don't like the Downloadmanager tho... 

    
    

    
  
Scott, there isn't a build available yet, that includes the patch. What you see
it might have been fixed somewhere else.

    
    

    
  
*** Bug 159110 has been marked as a duplicate of this bug. ***

    
    

    
  
i know no one really wants to read another comment, so that's why i'm writing
this one :-)

i decided to download
ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-07-22-08-trunk/windows-xpi/talkback.xpi
using my shell (which happens to be ie, because this is w2k), because I was
planning to make a test modification to the talkback zippy (long story).

so ie saved the file for me, to my desktop, as ... drumroll ... talkback.xpi.zip
that's read: talkback dot zippy dot zip.

this was handy (according to ie) since after all, i wanted to extract it using
winzip (which would have been perfectly happy opening .xpi), reseal it and then
feed it to mozilla, except that mozilla wants .xpi, which is of course what
everyone here should have expected the filename to be, after all, this is ftp:
not http: and what business does an ftp client (or web browser) have munging
filenames?  <grin>

Does anyone here want to suggest that we implement ie's filenaming algorithms?
[this was a rhetorical comment, there is no need to reply, i just thought i'd
share some humor]

    
  
No longer blocks: 1.1

    
    

    
  
*** Bug 159251 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 159317 has been marked as a duplicate of this bug. ***

    
    

    
  
Approval of wallpaper for 1.0 branch granted; change mozilla1.0.1+ to fixed1.0.1
when checked in.
Keywords: fixed1.0.1 → mozilla1.0.1+

    
    

    
  
checked in on the branch.  Further patches should go in dependecies of this bug;
the keywords here confused adt as it was.  ;)
Keywords: mozilla1.0.1+ → fixed1.0.1

    
    

    
  
pls remeber to get ADT approval before checking into the 1.0 branch.
Blocks: 143047
Keywords: adt1.0.1 → adt1.0.1+

    
    

    
  
Hi
I just downloaded the latest build to se if the problem with octet stream
becoming .exe files in windows was solved and I'm sorry to say that it is
different but not ok.
The file was somthing.php3 but when the save box came up it was somthing.php3.php
Not Nice at all. Was not application/octet-stream supposed to be left alone ?


    
    

    
  
Well... now we fall back to determining type based on _extension_.  That should
be a bit improvement unless there are multiple extensions that all map to the
same type... then 147679 (which this depends on) bites you.  :(

    
    

    
  
Stop this extension fixup it brings more bad then good things, in if ihe server
serves a wrong mimetype/extension it sould go to the tech evangelism.

Mozilla should not touch any filenames !!

May be Mozilla can warn the people in the Downloadwindow if the extension ís not
the mimetype.

    
    

    
  
Please.... stop mangling file extensions.

Under windows XP and 2000, v1 was handling things correctly. The latest alpha,
beta and nightly are back to where things were considerably prior to v1.

I frequently browse on a windows box, saving files to numerous differnt unix
boxes via samba shares. If I am attempting to download a "file.tar.gz" that last
thing I want the browser to do is to change that to "file.tar.gz.tar". It is
bloody annoying. This isn't just a remnent of the file choser, the initial pop
up box already has the name mangled before we get that far.

I see this has been a much discussed bug/feature. If we can't go back to the way
things were can we at least have a toggle to turn off the mangling or choose
behaviors?


    
    

    
  
could it be possible, in the popup about the type of file containing "*.*" and
"*.tar" to have another entry corresponding to the type sent by the server ?
like for the last comment, having :
1/ *.*
2/ *.tar.gz <== no modification of the filename
3/ *.tar  <== modification of the filename as it occurs today

And the default would be 2/ or 3/ ?

    
    

    
  
*file name is part of file*
changing it is like having an automatic spell check on a downloaded document.
Sad to say the solution is in comment 264 and anything less is a call for spam
on this bug. 

    
    

    
  
Hopping off the spam train

    
    

    
  
*** Bug 159850 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 159640 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 160275 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 160886 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 161131 has been marked as a duplicate of this bug. ***
Depends on: 160454

    
    

    
  
bz fixed the most common case.  I'm marking this bug as fixed to get it off the
mostfreq list and to prevent new bugs from being "lost" as dups of this bug or
comments on this bug.  There are already bugs for most of the other cases in
this bug's blocks list.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Keywords: helpwanted, 
          
            mozilla1.1
Resolution: --- → FIXED
Target Milestone: mozilla1.2alpha → mozilla1.1beta

    
    

    
  
So should we file separate bugs for each instance of Mozilla improperly renaming
a file?

    
    

    
  
You should file bugs on each distinct technical reason Mozilla renames files. 
When in doubt as to what the technical reason is, try the blockers of this bug.
 If still in doubt, ask Jesse to triage it.

    
    

    
  
*** Bug 161485 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 161689 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 161563 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 161940 has been marked as a duplicate of this bug. ***

    
    

    
  
Stop duping bugs to this bug. First confirm the bug still exist, if it does find
a dup for its exact cause (check all the blockers for this bug) if not file a
new bug and make it block this bug)

    
    

    
  
*** Bug 121243 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 162499 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 162487 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 162865 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 163564 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 162926 has been marked as a duplicate of this bug. ***

    
    

    
  
related: bug 146781, you decide how to deal with it
umm, how and when was this fixed ?

    
    

    
  
*** Bug 146781 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 163814 has been marked as a duplicate of this bug. ***

    
  
Blocks: majorbugs

    
    

    
  
*** Bug 164077 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 163882 has been marked as a duplicate of this bug. ***

    
    

    
  
vrfy'd fixed on the branch (details below). i've added verifyme in case someone
can vrfy this on the trunk before me.

http://hopey.mcom.com/tests/bug-120327.txt

verifying http://bugzilla.mozilla.org/show_bug.cgi?id=120327

"Sanitize extension-fixup code: Don't add .exe or .txt to files names of
text/plain and application/octet-stream, etc."


mime & method:
-------------
[a] text/plain (ftp), accel+S. eg, ftp://ftp.mozilla.org/pub/mozilla/nightly/README

[b] text/plain (ftp), "save target link". eg,
ftp://ftp.mozilla.org/pub/mozilla/nightly/README

[c] text/plain (http), accel+S. eg, http://hopey.mcom.com/tests/plain-no-extension

[d] text/plain (http), "save target link". eg,
http://hopey.mcom.com/tests/plain-no-extension

[e] application/octet-stream (ftp), click link.
eg, for win2k and linux:
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-mac-trunk-stub.bin

eg, for mac os x, i tried a couple of links:
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer.exe
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-source.tar.bz2


[f] application/octet-stream (ftp), "save target link".
eg, for win2k and linux:
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-mac-trunk-stub.bin

eg, for mac os x, i tried a couple of links:
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer.exe
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-source.tar.bz2

[g] application/octet-stream (http), click link.
eg, for win2k and linux:
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0/mozilla-macosX-10.smi.bin

eg, for mac os x, i tried a couple of links:
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0/mozilla-win32-1.0-installer.exe
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0/mozilla-mac-10-full-instal.bin

[h] application/octet-stream (http), "save target link".
eg, for win2k and linux:
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0/mozilla-macosX-10.smi.bin

eg, for mac os x, i tried a couple of links:
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0/mozilla-win32-1.0-installer.exe
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.0/mozilla-mac-10-full-instal.bin


commercial 1.0 branch builds tested, and results:
------------------------------------------------
* win2k, 2002.08.22.09-1.0:

a, b, c, d: no .txt was added to filename.
e, f, g, h: no additional extension was added.


* linux rh7.2, 2002.08.22.07-1.0:

a, b, c, d: no .txt was added to filename.
e, f, g, h: no additional extension was added.


* mac os x 10.1.5, 2002.08.22.05-1.0:

a, b, c, d: no .txt was added to filename.
e, f, g, h: no additional extension was added.

    
    

    
  
Downloaded latest build "Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1b)
Gecko/20020822"
To finally se this bug fixed.
BUT when i download an octet-stream  abc.php3 mozilla still alters the name to
abc.php3.php
Please include this type of misguided alteration in the test case
Since it is an octet-stream it should be left alone.



    
    

    
  
*** Bug 164348 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 164558 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 164673 has been marked as a duplicate of this bug. ***

    
    

    
  
comment 345 is, as I have mentioned a few times in response to similar comments,
bug 147679

    
  
Blocks: tar.gz
Depends on: 164816

    
    

    
  
*** Bug 164799 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 163424 has been marked as a duplicate of this bug. ***

    
  
Whiteboard: [adt3] Please read comments 45, 46, 47, 48, 275 before commenting. → [adt3] Pls read comments 45, 46, 47, 48, 275 before commenting. (pls confirm if prob still exists b4 duping)

    
    

    
  
*** Bug 166641 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 167209 has been marked as a duplicate of this bug. ***

    
    

    
  
There is an additional problem with this issue. Not only are .txt extensions
added, but when downloading a .zip file, I'm getting .x added to the end of the
filename. So foo.zip becomes foo.zip.x. I vote for not adding any extensions
(Windows version - haven't had any problems with the Linux build). Mentions of
this being a Windows file selector problem clearly are off base. The file
requestor in Moz should work the way the file requestor in Notepad does. If I
open a file in Notepad - bar.sys, and then save said file, the filetype remains
"Text file - .txt" but the filename remains bar.sys. It's going to cause all
kinds of confusion for newbies (the people that this behavior is attempting to
help) as they will be unable to locate a file they just downloaded. For more
experienced users it's an annoyance.

    
    

    
  
I'm still seeing a problem with the latest builds on Solaris (build ID
2002090822).  If I have a link to a PDF, and I select "Save Link Targe As...",
the file ends up with an extra "..pdf" on the end.  For example, test.pdf
becomes test.pdf..pdf.  If I click the link and select "Save this file to disk",
the file name is correct.  You can test this at
http://www.eecs.wsu.edu/~rgriswol/test.html.  I opened a bug for this problem
(159640) which was closed as a dup of this bug.  I used to see this bug on Linux
as well, but it was fixed around the 22nd of last month.

    
    

    
  
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.1) Gecko/20020826

attempting to download newer Mozilla 1.2a for linux, go to
http://www.mozilla.org/releases/ 
in the Mozilla 1.2a section, go to Linux section (not the try these section) and
click on the link "x86 Talkback enabled Full Installer" that points to
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2a/mozilla-i686-pc-linux-gnu-1.2a-sea.tar.gz

Mozilla will ask to save a file named mozilla-i686-pc-linux-gnu-1.2a-sea.tar.gz.tar
Will test win32 version of 1.2a as soon as it finishes download.

    
    

    
  
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.2a) Gecko/20020910

NOT FIXED in this build!

Test:
attempting to download newer Mozilla 1.2a for linux, go to
http://www.mozilla.org/releases/ 
in the Mozilla 1.2a section, go to Linux section (not the try these section) and
click on the link "x86 Talkback enabled Full Installer" that points to
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.2a/mozilla-i686-pc-linux-gnu-1.2a-sea.tar.gz

Mozilla will ask to save a file named mozilla-i686-pc-linux-gnu-1.2a-sea.tar.gz.tar


    
    

    
  
Andrei: That is bug 144334, which is in this bug's dependency tree.

Everyone: This bug is dead. Please don't spam it anymore. Thank you.

(removing self from cc)

    
    

    
  
*** Bug 172627 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 173023 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 157764 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 176659 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 175436 has been marked as a duplicate of this bug. ***

    
    

    
  
I posted a comment to bug #175436, and got a response that it is a dupe of Bug
#120327, and has a status FIXED. But the behavior I am experiencing using
Windows 98 SE and build 2002082611 for 1.1 Final does not match what is being
discussed here. My complaint is not just that the file name is being changed by
the Download Manager. That is part of my complaint, but the main complaint is
that the download fails with the message "Unable to open", and I can't get the
file at all, with any extension. At least if the extension is one I don't want,
I could rename the file, but if I can't download the file by any name there is a
problem.

On my system, files with extension .txt are associated with the UltraEdit
editor, which can open binaries, but Mozilla is not invoking UltraEdit to open
an exe.txt file.

Also part of my complaint is that I am not given the choice of directory into
which to save the file. For security reasons, I don't download files to the C:
drive, but to a removable medium, and because it saves me having to archive what
is usually a temporary file, most often some software executable file that I
want to install.

Note that I have installed Mozilla on my E: drive, not on my C: drive, which I
reserve for things that absolutely cannot be installed anywhere else. I wonder
if that might be the cause of some other malfs, such as not being able to load
any Java applets, even though the plugin manager shows JDE 1.4.1 installed okay.

Mozilla should work like Netscape 4.7: If one left-clicks on a link, if the MIME
type allows it to be opened in the browzer, then do so. If not, offer the option
of saving it to disk. If right-click, offer option of download to disk. If
choose download to disk, do so with no name change and DO NOT OPEN.

Changing the file extension to protect the user from inadvertant execution is
not a solution. If the user doesn't recognize the danger of downloading an
executable, then how is he going to know enough not to just rename the file
after it is saved? A warning is appropriate, but not a gatekeeper function.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
bug 175436 has been reopened.  This one is still fixed.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Keywords: verifyme
QA Contact: sairuh → petersen

    
    

    
  
*** Bug 154313 has been marked as a duplicate of this bug. ***

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021111

I can reproduce the problem mentioned in Comment #357.


    
    

    
  
as mentioned in comment 358, the problem mentioned in comment 357 is bug 144334,
not this bug.

    
    

    
  
This bug is fixed, and it is now dead. Do not reopen. File new bugs on specific
issues.

VERIFIED.
Status: RESOLVED → VERIFIED
Whiteboard: [adt3] Pls read comments 45, 46, 47, 48, 275 before commenting. (pls confirm if prob still exists b4 duping) → This bug is DEAD. Do not reopen. File new bugs on specific problems.

    
    

    
  
*** Bug 172445 has been marked as a duplicate of this bug. ***

    
    

    
  
Mozilla 1.4b will add .exe to a downloaded .iso file.  Is that another issue,
or the bug should be reopened?

    
    

    
  
I had mozilla 1.3 add a .tar to foo.tar.gz, making it foo.tar.gz.tar
This bug just won't die until you give up trying to second guess file
names.


    
    

    
  
Perhapse its time to try an alternative method? My thought is to allow the user
to configure the browser so that it accepts the filename for whatever its given,
with maybe a warning message when they enable this mode. Either that or somehow
just treat all files as being malicious...

    
    

    
  
I know comment #369 suggests filing a new bug report and not to reopen, but
issues seems to have regressed (as per #371, 372).  I am also seeing this with
.grs files being marked at .grs.txt.

Are we really advocating opening a new bug with the exact same summary?
(Sanitize extension-fixup code: Don't add .exe or .txt to files names of
text/plain and application/octet-stream, etc.)



    
    

    
  
If you wonder why this has become an issue for mozilla (other
browsers seem ignorant of it), you'll wonder more to learn
that we need to spend some time first on another issue of
whether to open new or reopen.

It took Microsoft less than 5 years to topple Netscape.  It
took Mozilla another 5 years to get a single digit user share.

I like mozilla.  I'll withdraw from this debate and try to
live peacefully with this bug.  Afterall, the bug itself is
really not that annoying...

    
    

    
  
Comment #372 is bug 144334
Please read the comments before commenting yourself.
If there are too many comments to read, that's more reason not to comment yourself.


    
    

    
  
> If you wonder why this has become an issue for mozilla (other
> browsers seem ignorant of it), you'll wonder more to learn
> that we need to spend some time first on another issue of
> whether to open new or reopen.

In fact, Opera introduced the very same "problem" with version 7, so I guess the 
mime-type <-> file extension mapping problem is not really a browser problem and 
will probably affect many other applications in the near future.

    
    

    
  
Um.. yes.  As stated clearly earlier in this bug, it's a problem in the inherent
design of file-launching in the MS Windows operating system.

Which is why this bug is _not_ present on the Linux or Mac platforms, by the way.

    
    

    
  
> Which is why this bug is _not_ present on the Linux or Mac platforms,
> by the way.

The other day I was using 1.4a and downloaded a tar.gz file under linux. It
renamed it, sticking a new .tar on the end.

From that exprerience I think it's present on all platforms. It's also difficult
for users to understand what's going on - the file says it's tar, yet tar says
"hmm that doesn't like like a tar file".

    
    

    
  
Please excure the last coment. I thought it had happened in linux, but checking
back see if was a cygwin file, so I must have been in Windows, which would fit
with #378. It's still a pain though ;)

    
    

    
  
I've seen it on linux, in the last few weeks, with a couple of different
extensions/file types.  Prior to the last several weeks I had not seen it for
many months, since this bug was originally closed.

    
    

    
  
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Bug still exists.

Trying to download a .tgz file from
http://www.openbsd.org/3.2_packages/i386.html leads to the file getting an extra
extension.  For example:
ftp://ftp.openbsd.org/pub/OpenBSD/3.2/packages/i386/zip-2.3.tgz -> zip-2.3.tgz.tar
with Mozilla saving as type "*.tar".


    
    

    
  
jrdepriest: since you have a specific case, maybe you should open a new bug
(since apparently we aren't supposed to reopen this one).  Please report the
number here, so that anyone who is still seeing this can join the new bug.

    
    

    
  
If you would bother to read the comments, it's clear that your symptoms are bug
144334 , jrdepriest.

    
    

    
  
*** Bug 166005 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 181162 has been marked as a duplicate of this bug. ***

    
    

    
  
I am using Mozilla Firebird 0.6.1 and I am also affected by this bug. Often when
I do downloads, the files a file which is called xyz.tar.gz ends up saved as
xyz.tar.gz.tar, ...

It would be cool if the Mozilla committers would fix the bug. I have seen that
some other users have attached patches, ...

    
    

    
  
*** Bug 235396 has been marked as a duplicate of this bug. ***

    
    

    
  
Can I ask which version of Mozilla is this fixed in?

    
  
No longer blocks: majorbugs

    
    

    
  
As <a href="http://4goodhosting.com/billing2/">J</a> said we need to know this Mozilla version

    
    

    
  
(In reply to terizvq from comment #390)
> As <a href="x">J</a> said we need to know
> this Mozilla version

^ spam?
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: