char *mangleResourceIntoFileURL(const char* aResourceFileName) { // The convertion logic is // resource://<aResourceFileName> // becomes // <exedir as a file url>/<aResourceFileName> nsSpecialSystemDirectory sysdir(nsSpecialSystemDirectory::OS_CurrentProcessDirectory); sysdir += aResourceFileName; -> nsFileURL aUrl(sysdir); char *aUrlString = (char *) aUrl.GetAsString(); aUrlString = PL_strdup(aUrlString); return (aUrlString); } The above marked call doesn't create the right FileURL. The mURL is a junk pointer. If I remove the member initialization and move it into the constructor of nsFileURL::nsFileURL(nsFileSpec &) then things work ok. I am using VC 5.0 on Nt 4.0

This really looks like a bug in the windows compiler. However, the code was incorrect anyway (since filepaths are no longer escaped). I have sent diffs to dp so he can test my fix. Is this worthy of checkin for 70% dogfood?

Marking M3 to get it considered.

Moving to normal P1. Setting QA contact to dp to check fix in code when ready.

Latest update on john's patch. The patch worked. There was a huge performance problem with using it. I think that isn't related to johns change though. So I am going to say GO on the patch. I am using VC5.0 with service pack 3

Fix checked in. When URLs are initialized from file paths or file specs, the result is now escaped (again). This was broken when I stopped escaping file paths (this was done for dp). Since the constructor now has to escape, these mem-initializers are no longer being relied on, except to initalize to null. So this change works around the compiler bug, as well. I don't see how using different code for string manipulation in URLs can be enough of a bottleneck to affect performance. That doesn't smell right to me.

DP, can you please mark this VERIFIED-FIXED? thanks! QA needs help on this one...

can someone please mark this verified-fixed?

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.)