Closed Bug 545091 Opened 14 years ago Closed 1 year ago

setting defaultExtension in nsiFilePicker on Mac OSX and GNOME (Ubuntu 9.10) does nothing

Categories

(Core :: Widget, defect)

x86
macOS
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: skoczko, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

Setting defaultExtension property of nsiFilePicker to enforce a given extension when saving a file does work as expected on Win32 (XP, Vista) but appears to be completely ignored on Mac OSX and Linux/GNOME (Ubuntu 9.10) as the file is saved without any extension. This is critical since the filename cannot be altered after the filePicker has opened a filehandle on the inserted filename (would need to re-check for overwriting and such). Either fix the nsiFilePicker to respect the defaultExtension property or allow more fine tuned control over what the user is inserting (e.g ability to specify onChange handler)

Reproducible: Always




//code to reproduce
const nsIFilePicker = Components.interfaces.nsIFilePicker;
var fp = Components.classes["@mozilla.org/filepicker;1"].createInstance(nsIFilePicker);
fp.init(winCtx, winName, nsIFilePicker.modeSave);
fp.appendFilter("My apps files", "*.myext");
fp.defaultString = "new_file";
fp.defaultExtension = "my_ext";
var rv = fp.show();
if (rv == nsIFilePicker.returnOK || rv == nsIFilePicker.returnReplace) {
   //do your thing on the filehandlde
   dump(fp.file.path); //this should already contain the default extension
}
Any news on this item?
This affects the Selenium IDE add-on, which allows user to save tests. See related issue: http://code.google.com/p/selenium/issues/detail?id=3060
Confirmed on CentOS 6.2, with Firefox 10.0.5 and 13.0.1.

However, this is *not* a bug. This functionality is provided by other means, see
https://developer.mozilla.org/en/NsIFilePicker.

For some reason defaultExtension does add the file extension on Windows, but does not add it on Linux/MacOS.

As detailed in the docs, to ensure that a file extension gets appended universally, "defaultString" should already include the extension. That is all.

Suggested status: closed.
Since users can clear the default string out of the file picker box using defaultString is worthless.

I can confirm this bug on OSX Lion 10.7.4 using Firefox 13.0.1.
(In reply to George from comment #3)
> Confirmed on CentOS 6.2, with Firefox 10.0.5 and 13.0.1.
> 
> However, this is *not* a bug. This functionality is provided by other means,
> see
> https://developer.mozilla.org/en/NsIFilePicker.
> 
> For some reason defaultExtension does add the file extension on Windows, but
> does not add it on Linux/MacOS.
> 
> As detailed in the docs, to ensure that a file extension gets appended
> universally, "defaultString" should already include the extension. That is
> all.
> 
> Suggested status: closed.

George:

This *is* a bug. As already mentioned, using defaultString is useless since the user can edit it before saving the file (as it should be -- defaultString has entirely different purpose, that is to let users change the proposed filename).

On OSX this is simply braindamaged at this point: in the open mode FilePicker can be restricted to only list files of a given extension but this extension cannot be enforced when saving files. As a result, if the user is not extra careful he/she will not be able to re-open the file previously saved!
Dan, Jakub,

Here is the exact wording of the documentation:
------------------------
defaultExtension - The extension for the type of files you want to work with. On some platforms, this is automatically appended to filenames the user enters, if required.

defaultString - The filename that should be suggested to the user as a default. This should include the extension. You can set this value before calling show().
------------------------

My point was:
- it is clear, defaultExtension will *not* work on all platforms, and
- any extension should *always* be included in the file name specified with defaultString.

My aim was chiefly to point out how you can specify an extension easily on all platforms, without relying on defaultExtension.

Can you also specify an extension on OSX/Linux? Yes.
Can you force a file extension on Windows (with defaultExtension)? Yes.
Can you force a file extension on OSX/Linux? No.

Yet, should you really *force* a file extension?
This is debatable. Users should always have the last say whether we like that or not.

Now, whether omitting/ignoring defaultExtension on OSX/Linux completely is a smart thing to do is an entirely different matter. I do feel this was a poor design choice, if this helps.
(In reply to George from comment #6)
> Yet, should you really *force* a file extension?
> This is debatable. Users should always have the last say whether we like
> that or not.

It depends on what's being saved. If I create a settings file with my own format, I want to enforce the file extension.
George :
This is a bug. Changing the filter drop-down menu changes the extension of the file on windows but not on Linux.
QA Whiteboard: qa-not-actionable

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --
Component: XUL → Widget

Let's get new, platform-specific bugs on file if this is still an issue today.

Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.