55115 - convert chrome registry to use nsIFile (not nsFileSpec)

Status: RESOLVED FIXED

(Core Graveyard :: Skinability, defect, P2)

Description

[Dan Rosen]

nsFileSpec is obsolete and causes problems with drive mappings on win32. migrate
chrome registry to newer nsIFile.

Comment 1

[Dan Rosen]

targeting, setting qa contact to john morrison (who's babysitting 36532 and
54947), adding keywords.

relnote needed: this ain't getting fixed for rtm. it should be noted that the
workaround for the bustage this causes is not to use mozilla with mapped drives
in windows.

Comment 2

[Dan Rosen]

just to make clear, the relnote needed is something like: using mozilla with
mapped drives in windows causes crashes on startup, the problem being that the
chrome registry is trying to access files through obsolete code. this will be
fixed rsn.

Comment 3

[John Morrison]

Er, the issue is the reverse actually: You can launch from a mapped 
drive (e.g., S:\mozilla), but not from a UNC name (e.g. 
\\myserver\apps\mozilla). No?

Comment 4

[Dan Rosen]

gah, that's right...

Comment 5

[Dan Rosen]

triaging for post-rtm. this and related bugs (36532, 54947) may have to be
pushed back to mozilla1.0 if this doesn't mesh with the 0.9 milestone plan, or
is too difficult.

Comment 6

[Dan Rosen]

hyatt claims that conrad and dougt came through and whacked all this code to fix
some similar problems on the mac. jrgm: can you verify whether this is actually
fixed?

Comment 7

[John Morrison]

yes, ccarlen did a filespec-ectomy in revs 1.162 and 1.164 of 
nsChromeRegistry.cpp. 

I do see one lingering use that got left behind (see URL field for this bug).

Judging by the stacks in the other bugs, they are likely fixed, but I don't 
have any great desire to go testing for crashes when I know there is still 
more filespec-ectomy to come. 

Comment 8

[Dan Rosen]

Attachment: Converts from nsFileSpec and nsFileURL to nsILocalFile and nsIFileURL

Comment 9

[Dan Rosen]

Hmm... Not sure if this code, or hyatt's old code, ever executes at all. It
seems like all the entries in dist/bin/chrome/installed-chrome.txt are of type
"url" rather than "path," and this code only executes if the type is "path."

Also, if it does execute, I'm not sure the string munging (adding "jar:" to the
beginning and "!/" to the end) does everything it's supposed to.

I'll try to figure this out tomorrow. cc'ing brendan who helped me grok the new
interfaces.

Comment 10

[Doug Turner (:dougt)]

Assuming that chromeLocation is a native path, the code looks about right. And
yes, it is alot bigger.  

You could use GetURL off of nsIFile instead of creating a necko url parser. 
However, this is a new addition and has not been implemented fully on mac or
unix.  I believe that ccarlen has diffs for this somewhere.  I am ccing him.

Comment 11

[Dan Rosen]

Sounds good (we were wondering why there wasn't such an API), but I think I'll
stick with the current model until ccarlen's diffs get checked in and see some
use. This code runs on startup, and we know that nsIFileURL works. That's good
enough for me, for the moment. I'll be tracking this anyway, to make sure I
don't foul something up.

Comment 12

[Peter "jag" Annema]

r=jag

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

a=[e-mail]

Comment 14

[Dan Rosen]

fixed (cvs rev. 1.175).