31096 - File->Save doesn't, depending on extension

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[Akkana Peck]

From the mail window, while viewing a message, do Save As->Message.

A file selection dialog pops up, pre-filled with the filename "mail".

Click ok.  The dialog goes away and no error message is shown.  Now look for the
file: none was created.

There are two problems here:

1. It should save regardless of what the filename is.  If you want to change
type, there should be another UI element to do that, but don't expect that users
will understand the magical file extensions that are supposed to give them
different formats.  I don't use any other programs that expect me to know
magical formats and don't give me an option menu (or something) to change
formats.

2. If it doesn't save anything, it should give an error message.  This could
lead to data loss, if someone thinks they saved their message, deletes it and
only finds out later that we didn't really save it when we implied we did.

Comment 1

[rhp (gone)]

I'll look into this bug I've spent a LOT of time on File->Save for I18N reasons 
and I know this works on other platforms. We are extremely forgiving on file 
extensions and do the right thing...we don't expect users to know what a file 
extension means and if they don't specify one, we tack on the type selected.

Now, I have seen awful behavior from the file selection dialog on Linux and 
that may explain part of the problem, but I will look further.

- rhp

Comment 2

[rhp (gone)]

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

Comment 3

[Akkana Peck]

Nominating for beta2 consideration since it's a data loss bug.

Comment 4

[jefft]

I'll take this since I am fixing bug 34252....

Comment 5

[jefft]

There is a big problem in the way nsFileWidget implemented for linux bug 35082.
We need to fix that before I can fix this.

Comment 6

[jefft]

If nsIFileWidget needs to be retired then I don't know how to make it work with 
new nsIFilePicker interface. There is no corresponding interface in 
nsIFilePicker for nsIFileWidget::PutFile(). nsMessenger::SaveAs() uses 
nsIFileWidget::PutFile() to get the output file name from the user. Reassign to 
trudelle....

Comment 7

[Peter Trudelle]

reassigning to pavlov, p3 for M18 sounds okay for me, since this is a seldom
used feature (mostly because we have never been able to open these saved files).
 The part about changing types should be a non-issue for this bug, I don't think
anyone expects a change in file extension to change the format of what is being
saved.

Comment 8

[Akkana Peck]

Seldom used?  Really?  I do Save As fairly often in 4.x mail, any time I want to
save a message by itself rather than as part of a local folder.

If this feature is M18 because it's a seldom used feature, please disable the
menu item for beta so users who *do* use the feature fairly often (like myself)
won't get fooled into data loss after thinking they've saved their messages and
only later finding out that nothing was saved and the message is lost.

Comment 9

[leger]

Putting on [nsbeta2+] radar.  

Comment 10

[Stuart Parmenter]

There are a couple of issues here.  I have begun rewritting
nsMessenger::SaveAs.  In the process I have run across some issues with
nsIFilePicker that I am working on resolving having to do with getting the
extention currently selected from nsIFilePicker.  I do not like the way that
nsIFileWidget returned an index of the filters since this implies that the
filters are declared in a specific order, which is not the case with the
bitfield that is being used currently.

My current thinking is that I will replace this the way filtering works now with
mimetypes using nsIMIMEService, etc.  I will have to make another interface that
will allow the use of wildcards so that you may say image/* or something to this
effect.  I have not quite figured out if this is the correct thing to do yet
though.

When I have figured out how to change nsIFilePicker, I will finish changing
SaveAs.

Comment 11

[Stuart Parmenter]

ok, thats a bad idea.  Using filters to tell the type of file is bad.  If the
user enters foo.html, I think we can safely assume they want html, but if they
enter 'myfile' with *.txt or *.html selected, we should not save 'myfile' as txt
or html, but as whatever the default is.

I am going to attach a patch that fixes this bug and bug #34328

Comment 12

[Stuart Parmenter]

Attachment: patch to fix bug

Comment 13

[Stuart Parmenter]

the behavior of saving a file as the default type reguardless of filter selected
is also seen in 4.x on windows and unix.  unix has a combobox in its save as
dialog to specify the file type, but we can't do that in an XP way, so I think
we should punt on the save based on filter behavior completly.

Comment 14

[Stuart Parmenter]

fixes checked in

Comment 15

[fenella]

Win32 (2000-05-26-09 M16)
OK. When I let its extension default to "mail" and opens it using wordPad, it 
displays the mail source file.