Since that's what it actually returns. See also bug 236989 comment 35.
So actually, there is one problem here. Documenting it as UTF-8 is well and good for C++ consumers, but not for JS ones, because this API use ACString, not AUTF8String. But if I change it to AUTF8String, then existing JS consumers may stop working if they are storing a descriptor somewhere that they have gotten as an ACString in the past (since I'd need to change setRelativeDescriptor too). So how about I add get/setRelativePath, which does AUTF8String and under the hood just calls get/setRelativeDescriptor?
I was hoping we could just make get/setRelativeDescriptor DTRT, but I don't think that's possible with addon compat. Let's have the separate get/setRelativePath instead.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Comment on attachment 8623819 [details] [diff] [review] Add getRelativePath/setRelativePath to nsIFile Review of attachment 8623819 [details] [diff] [review]: ----------------------------------------------------------------- ::: xpcom/io/nsIFile.idl @@ +458,5 @@ > * Returns a relative file path in an opaque, XP format. It is therefore > * not a native path. > * > * The character set of the string returned from this function is > * undefined. DO NOT TRY TO INTERPRET IT AS HUMAN READABLE TEXT! Are we fixing this text here, or in some other bug?
Attachment #8623819 - Flags: review?(nfroyd) → review+
I don't think we should change that text, since from JS what you get back is pretty whack right now (UTF-8 but with all the bytes exploded into uint16s).
(In reply to Boris Zbarsky [:bz] from comment #5) > I don't think we should change that text, since from JS what you get back is > pretty whack right now (UTF-8 but with all the bytes exploded into uint16s). Ah, right. OK.
Summary: Document that nsIFile.getRelativeDescriptor always returns a UTF-8 relative path → Add an nsIFile.getRelativePath that always returns a UTF-8 path
You need to log in before you can comment on or make changes to this bug.