279773 - Firefox trunk isn't coming up on OS/2

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Mike Kaply [:mkaply]]

Found four issues.

1. nsNativeAppSupportOS2.cpp needs to be reported (Rich Walsh did that)
2. need some changes for commandline service (Rich Walsh did that)
3. Need a SHORT_LIBNAME for permissions.dll
4. GetWorkingDirectory wasn't working on OS/2.

Patches coming.

Comment 1

[Mike Kaply [:mkaply]]

Attachment: GetWorkingDirectory Fix

Comment 2

[Mike Kaply [:mkaply]]

Attachment: add SHORT_LIBNAME for permissions.dll

Comment 3

[Rich Walsh]

Attachment: nsCommandLine changes needed by OS/2

adds platform-specific code to nsCommandLine::ResolveFile and defines
"cmdlines" as the SHORT_LIBNAME for the commandlines library

Comment 4

[Mike Kaply [:mkaply]]

Comment on attachment 172513 [details] [diff] [review]
nsCommandLine changes needed by OS/2

r=mkaply

Comment 5

[Rich Walsh]

Attachment: updates to nsNativeAppSupportOS2.cpp

revisions to use nsICommandLine, largely ported from nsNativeAppSupportWin

Comment 6

[Rich Walsh]

Attachment: an alternative for GetWorkingDirectory Fix

a simpler way to fix OS/2-specific code in SpecialSystemDirectory.cpp (see
attachment 172354 [details] [diff] [review])

Comment 7

[Rich Walsh]

The startup code in nsCommandline.cpp & nsBrowserContentHandler.js produces
inconsistent results.  The first invocation of Firefox can successfully load a
file with a relative path.  Subsequent invocations fail unless the filename
specified on the commandline is fully-qualified.  I suspect, but can't confirm,
that this is an XP problem rather than OS/2-specific.  Should I open a new bug?

Comment 8

[Mike Kaply [:mkaply]]

(In reply to comment #7)
> The startup code in nsCommandline.cpp & nsBrowserContentHandler.js produces
> inconsistent results.  The first invocation of Firefox can successfully load a
> file with a relative path.  Subsequent invocations fail unless the filename
> specified on the commandline is fully-qualified.  I suspect, but can't confirm,
> that this is an XP problem rather than OS/2-specific.  Should I open a new bug?
> 

We need to get someone to verify that first.

Comment 9

[Rich Walsh]

(In reply to comment #8)
> > The startup code in nsCommandline.cpp & nsBrowserContentHandler.js produces
> > inconsistent results.  [...]  I suspect, but can't confirm, that this is an
> > XP problem rather than OS/2-specific.
> 
> We need to get someone to verify that first.

I tried reproducing this using the Windows nightly from Jan 27th - no problems
there.  I'll keep investigating why it fails on OS/2.  Unfortunately, I don't
understand how nsBrowserContentHandler.js & nsDefaultCLH.js fit into the big
picture :-(

Comment 10

[Mike Kaply [:mkaply]]

Comment on attachment 172519 [details] [diff] [review]
an alternative for GetWorkingDirectory Fix

r=mkaply

We should fix these all over the code :)

Comment 11

[Mike Kaply [:mkaply]]

These patches are all in, so this is fixed.

Let's open another bug for the command line problem.