User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; ru) Opera 8.54 Build Identifier: http://mozilla-chi.osuosl.org/pub/mozilla.org/thunderbird/releases/1.5.0.4/win32/ru/Thunderbird%20Setup%201.5.0.4.exe When I save letter twice under own name, then second save doesn't asks, if file should be replaced. Reproducible: Always Steps to Reproduce: 1. Select File / Save as (or press ^S) on/in some letter. 2. Enter new name (say, "letter") and press Save button. 3. Again select File / Save as (or press ^S). 4. Enter same name ("letter") and press Save button. Actual Results: 1. Opened Save dialog with "File type: all files". 2. File saved and me returns into mailer panes. 3. Again opened Save dialog. 4. File saved and me returns into mailer panes. Expected Results: 4. Before replacing old file, Save dialog should ask permissons for this.

Not a problem on linux/tb1.5.0.4

Is the filename in ASCII or some other character set?

> Is the filename in ASCII or some other character set? Word "letter" (without quotes) contains only pure ASCII or do you mean something else?

Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 2.0.0.16)

NOTHING changed. As previously, (1) TB opens dialog with "File type: All files" [this is senseless], (2) offers "Name: <subject>.eml", (3) adds ".eml" to name, entered by mine ("letter" in given case), (4) not asks when overwrites file at second save with same name [main theme for this report], (5) and not offers option to add new saving to existing file.

Arkady, what's the version of Thunderbird and OS you tested against for comment #5? It will help to narrow down the problem.

As previously: latest (2.0.0.16) TB in Win98.

using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090407 Shredder/3.0b3pre the only way I get this to fail is if I type a name, like ABC and then hit enter, i.e. do not click SAVE. The result is no prompt. I haven't looked to see if this is a duplicate

using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090602 Lightning/1.0pre Shredder/3.0b3pre I get no prompt using enter, no prompt clicking "Save". Confirming. There's a later duplicate which I'll be duping to this bug. I'd consider dataloss esp. if the previous file existed and wasn't intended to be overwritten.

The issue is here: http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMessenger.cpp#1006 We set the file picker to ALL, then a bit below that if there is no file extension (or it isn't recognised) we'll append .eml without checking if the file exists or not.

I would go so far as to say this is a bit of a blocker, because of the dataloss issue.

(In reply to comment #12) > I would go so far as to say this is a bit of a blocker, because of the dataloss > issue. Upping severity, as it seems quite easy to trigger this dataloss on all platforms.

Yeah let's get this fixed for tb3, seems like all that's needed is a PromptIfFileExists(localFile) call. I think you may need to have windows set to hide file extensions for this to show up... (as i can't repro on linux)

(In reply to comment #14) > > I think you may need to have windows set to hide file extensions for this to > show up... (as i can't repro on linux) I believe Windows does that by default

(In reply to comment #14) > I think you may need to have windows set to hide file extensions for this to > show up... (as i can't repro on linux) Nope, I see this bug even with hide file extensions disabled. Taking.

I initially considered using a do/while loop to do this, but the UI would be rather confusing then. Consider that you're saving an email with subject |foobar|, and there are already files called |foobar| and |foobar.eml| in the folder. If we attempt to save as |foobar|, then - first, the OS filepicker would confirm the replacement of |foobar|. - we'd then append .eml, and then confirm the replacement of |foobar.eml| while the filepicker's closed. If the user says no, we'd do the whole thing again. This patch removes all the stuff where we try to second-guess the file picker -- if the user wants us to save the file without an extension, we should happily do so. As far as I can tell, no other major application tries to force an extension on the filename the way we do. I've also removed the |All Files| save as type -- such a type would require us to guess which type we want to save as based on the filename, which is something we want to avoid here. Since this is a reversal of some of the UI decisions made in bug 96134 comment 23 and bug 124217, asking for ui-review. I've also tried to cover all platforms with the reviews -- please test the patch on your platform as part of your review.

Try builds: Linux: http://s3.mozillamessaging.com/build/try-server/2009-07-16_13:22-sid.bugzilla@gmail.com-340168-save-as/sid.bugzilla@gmail.com-340168-save-as-mail-try-linux.tar.bz2 Mac: http://s3.mozillamessaging.com/build/try-server/2009-07-16_13:22-sid.bugzilla@gmail.com-340168-save-as/sid.bugzilla@gmail.com-340168-save-as-mail-try-mac.dmg Windows zip: http://s3.mozillamessaging.com/build/try-server/2009-07-16_13:22-sid.bugzilla@gmail.com-340168-save-as/sid.bugzilla@gmail.com-340168-save-as-mail-try-win32.zip Windows installer: http://s3.mozillamessaging.com/build/try-server/2009-07-16_13:22-sid.bugzilla@gmail.com-340168-save-as/sid.bugzilla@gmail.com-340168-save-as-mail-try-win32.installer.exe

Comment on attachment 388982 [details] [diff] [review] don't second-guess the OS file picker, v1 this is probably just moved code, but this could be just one line: + filePicker->Init(mWindow, saveMailAsStr, + nsIFilePicker::modeSave); +

Comment on attachment 388982 [details] [diff] [review] don't second-guess the OS file picker, v1 sounds right to me.