When using nsIFileWidget::GetFile() to get a local file, it should not return if the user typed a filename that doesn't exist. In Windows code, there is a flag to set to let the OS put up a messagebox forcing the user to type an existing filename. We might want to check for file existence ourselves and put up our own dialog for the user so it is the same on all platforms. This is probably not an issue for Mac, and I'm not sure about UNIX, but I think that is like Windows and lets you type a filename.

GetFile no longer exists in nsIFilePicker. You pass a value (load, save, getDirectory) to it and it should behave based on that. so if the value is 'load' it shouldn't return. I know this is the case in the new linux file picker and the windows and mac code is basically the same, so if one of them didn't work before, reassign this bug to a mac or windows person.

With Pavlov's new nsIFilePicker, the problem still exists in Windows: You can type anything in the filename input field of the Open File dialog and that gets returned when you click OK, even though it's garbage. In the Windows-specific code that nsIFilePicker calls, someone needs to set the flag that prevents this -- i.e., the OS can ensure that the file exists. Bill: Are you responsible for the Windows-specific code? Pavlov: Please check UNIX behavior to be sure it forces filename to exist as well.

I guess I can be the "windows person." Are there any tricky corner cases? For example, I could see where one might use "open web location", select "Chose File...", and expect to be able to enter a previously non-existant file (because they had selected, or were going to select, the "New composer" option).

No, you can't create a new file that way. In Composer, we always want the file picked by the filepicker to return an existing file.

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

Move to M20 target milestone.

Oops. Should be M21.

This works on Windows.

vrfy fixed --ie, get an error dialog if you enter a bogus [non-existent] filename in the [native] file picker. tested on winNT using 2001.02.09.09 comm bits. don't get an error dialog on linux, tho', so filed bug 68374.