Please use the nsIFilePicker and the wstring (unicode) attributes in the nsILocalFile instead of nsIFileSpecWithUI and nsIFileSpec 783 if (filePicker) filePicker = filePicker.QueryInterface(Components.interfaces.nsIFileSpecWithUI); 784 if (!filePicker) return(false); 785 786 var promptStr = bundle.GetStringFromName("SelectImport"); 787 788 filePicker.chooseInputFile(promptStr, 2, "", ""); // 2 = html filter 789 var filespec = filePicker.QueryInterface(Components.interfaces.nsIFileSpec); 790 if (!filespec) return(false); 791 var filename = filespec.URLString; 792 if ((!filename) || (filename == "")) return(false); 793 794 debug("Import: '" + filename + "'\n"); 795 urlVal = filename;

Frank, I tried to use nsIFilePicker and it had various bugs (which Pavlov is aware of). What's your real issue with using nsIFileSpecWithUI ?

.

I have a fix for this in my tree, but it will depend on being able to set the default filename correctly (bookmarks.html, for export). rjc, we fixed some issues recently with the filepicker not preserving the filename on chdir. Had you encountered other problems that would make this a bad idea to check in?

Yeah, nsIFilePicker was (is still?) broken on Mac... it was (isn't?) returning file:/// URLs properly. Pav, is this still the case?

i have no idea, i don't have a mac. try open file.

I tried Open File on the Mac and it worked for me... so bryner, why don't you attach your patch to this bug? (I'd be happy to review it.)

Bryner, looks good & works for me on my Mac. r=rjc

just fyi for the dev types, 'Open File' gets checked _every_ single_day_ on every build, on every platform, ever as part of the daily smoketests. You'd know if and when it broke. http://www.mozilla.org/quality/smoketests/

Nominating for nsbeta2, because this helps out i18n and is a fairly safe fix.

[nsbeta2+][6/15]

rjc: one small change I'd like to make, after law brought this up in another bug... we should probably change: if (filePicker.show() == nsIFilePicker.returnOK) ..... to if (filePicker.show() != nsIFilePicker.returnCancel) ..... otherwise, it would fail to save in the returnReplace case. If you think that would be ok, I'll check this in.

Yeah, that makes sense.

Fix checked in.

code-level fix, marking VERIFIED.