On Windows, calling GetLeafName() on a nsFileURL doesn't unescape the leaf name. Run apprunner, load in "resource:/res/rdf/sidebar.xul" and open up the "File System" container. You'll see all available drives. Open up "C:"... and look for "file:///C|/Program%20Files/". Its leaf name should be displayed as "Program Files" but since GetLeafName() isn't unescaping the name, its being displayed as "Program%20Files".

I don't understand this, really, because GetLeafName is not a method of nsFileURL, but rather of nsFileSpec. Is the problem that nsFileSpec ends up with an escaped name? If so, how was the spec made? (I conjectured at first that the spec was made from a URL, and that the bug is that unescaping is not occurring. However, looking at the code, I see that unescaping is happening in this case.) Could you give me a reference to the code path that leads to this phenomenon?

Here's a code snippet: const char *uri = __some escaped files URL__; nsFileURL url(uri); nsNativeFileSpec native(url); char *basename = native.GetLeafName();

Accepting bug.

Reopening this bug as it has returned. Also, cc'ing dougt.

Set milestone to M5.

I did spot one problem, and checked in a fix for it. I haven't tested it yet, so I'm not presuming to mark it fixed. Feel free to update mozilla/base to get the current fix.

OK, Robert, now I'm confused. The tree widget on windows is still displaying full URLs (instead of leaf names), so how do I reproduce this bug?

I pulled your fix; the bug still persists. :^( John, I'm confused when you say that the tree widget is displaying full URLs. The first column should be the name column [as returned by GetLeafName()], with the second column being the full URL.

Move to M6 (unless you have an easy fix, John :-)

Solved. Fixed (to be checked in after M5). The problem is actually that the two constructors of nsFileURL that take a string parameter were passing the string to the constructor of nsFilePath without UNESCAPING it. So the strings in nsFileURL were doubly escaped. Changed summary from "GetLeafName() doesn't unescape name" to "nsFileURL doubly escapes its escaped input string"

Fix checked in.

Bulk moving to XPCOM, in preparation for removal of XP File Handling component. (XPFH has received two bugs in ~5 months, and is no longer in active use.)