There are five callers to ConvertAndSanitizeFileName: One caller asks for a unicode filename for a prompt string One caller asks for a unicode filename for the filepicker Three callers ask for a native filename for nsILocalFile::AppendNative By switching to nsILocalFile::Append we can eliminate this, which will make things easier for when we switch to libxul, which doesn't export it (yet?). Note that this shifts any error-checking into nsILocalFile::Append (non-Windows versions call NS_CopyUnicodeToNative) but we already error-check that anyway, so that ConvertAndSanitizeFileName never has to worry about returning an error.
Created attachment 366793 [details] [diff] [review] Proposed patch
Attachment #366793 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 366793 [details] [diff] [review] Proposed patch >+ nsString unescapedName; >+ ConvertAndSanitizeFileName(displayNameArray, unescapedName); >+ localFile->Append(unescapedName); > rv = PromptIfFileExists(localFile); > NS_ENSURE_SUCCESS(rv, rv); According to your comment, shouldn't we be checking the result of Append here and >+ ConvertAndSanitizeFileName(state->m_displayNameArray[i], unescapedName); >+ localFile->Append(unescapedName); > rv = m_messenger->PromptIfFileExists(localFile); here ? We probably should be checking them anyway, so r=me with appropriate fix.
Attachment #366793 - Flags: review?(bugzilla) → review+
Pushed changeset 7cdd1820c9f5 including error-checking to comm-central.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.