8503 - [PP]Can't run apprunner in Mac if directory has "/" in it

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Paul MacQuiddy]

If you change the seamonkey folder name (such netscape5-mac-M7) to include a
forward slash (such as 'seamonkey6/18') then apprunner will not run. Removing
the forward slash and you can run again. I'm guessing it is a registry problem.

The forward slash is a legal character in MacOS, apparently, as I'm allowed to
enter it when changing the directory name.

Comment 1

[Suresh Duddi (gone)]

This is a known bug. I have a fix on hand. Since it was a api change, we are
checking it into M8.

Comment 2

[Suresh Duddi (gone)]

This one should be fixed with xpcom using nsIFileSpec.

Comment 3

[Paul MacQuiddy]

Same behavior with 6/23 builds. Re-opening.

Comment 4

[Suresh Duddi (gone)]

Could you describe behaviour.

Comment 5

[Paul MacQuiddy]

Sure.

Double-click on apprunner. App begins to launch, then quits after 2-3 seconds.
No crash, just doesn't do anything. Take forward slash out of folder name and
apprunner starts up no problem.

Comment 6

[Paul MacQuiddy]

This is still failing on 7/8 builds. I will release note it, assuming it will
not be fixed more M8.

Comment 7

[Suresh Duddi (gone)]

Yes paul. Moving to m9.

Comment 8

[Daniel Veditz [:dveditz]]

dp, is this something I should be looking into?

Comment 9

[Suresh Duddi (gone)]

Yes. I just talked to simon and he says that the first instance of fail is the
PR_OpenFile() that libreg does. I dont know how you are going to solve this. Is
using filespec an option for libreg. I didn't think so.

Anyway I will let you figure it out.

Comment 10

[Daniel Veditz [:dveditz]]

Actually that would be pretty easy -- originally the registry used stdio calls
to open the registry, taking purely native paths not the
pseudo-cross-platform-not-really NSPR paths. Those calls are all in working
#ifdefs because we build libreg "standalone" (without NSPR) for the 4.x
installs.

McMullen switched libreg to nspr because it supposedly ran faster, but
"working" is better than not-working faster. If I add the buffering maybe that
would make up for it.

Comment 11

[chris hofmann]

dveditz just started looking at this. moving to m10.

Comment 12

[Paul MacQuiddy]

this causes a crash in M9 milestone builds, FWIW

Comment 13

[Daniel Veditz [:dveditz]]

The registry code now uses native pathnames, avoiding slash confusion.