Startup fails in OS X Beta Classic

RESOLVED WORKSFORME

Status

SeaMonkey
General
P3
minor
RESOLVED WORKSFORME
18 years ago
13 years ago

People

(Reporter: mstearne, Assigned: Conrad Carlen (not reading bugmail))

Tracking

({crash, pp})

Trunk
mozilla0.9
PowerPC
Mac OS X
crash, pp

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm-])

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; N; PPC; en-US; m18) Gecko/20000926
BuildID:    2000092612

Startup of the browser will fail under the OS X Beta if a Documents folder that
is writeable by all is not present in the root of the filesystem at startup.

Reproducible: Always
Steps to Reproduce:
Start browser!

Actual Results:  Browser crashed and crashed Classic with it.

Expected Results:  Start browser.

Comment 1

18 years ago
cc: pinkerton, who rumours has it has os x
Keywords: crash, nsmac2, pp, rtm
yup, i've seen this. i'd suggest we fix this for rtm, but i know marketing will
nix it.

Comment 3

18 years ago
setting bug status to New.  pinkerton, who should the bug go to.  I'm not a good
owner for it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: asa → ccarlen
--> conrad
(Assignee)

Comment 5

18 years ago
Sounds like we need to put the :Mozilla:Users50: folder elsewhere on OSX. This
location is now put in "Documents" which is found using the Toolbox FindFolder
routine. This bug is another good reason not to use the "Documents" folder which
I don't think we should use anyway. We have some nasty fallback code to create
it if it doesn't exist and it is not localized in any way. I think we should use
the Preferences folder as the default location to store our profiles. I don't
have an OSX system, so  can't say for sure whether FindFolder will return a
good, writable directory in that case either. Anybody know this? As a
(temporary) workaround, try dragging "Profile Manager" onto the app, create a
new profile, and choose another directory.
Status: NEW → ASSIGNED
We originally chose Documents because the idea behind the prefs folder is for
application data that can be tossed away w/out really harming the user. It's
user settings, not user _data_.
(Assignee)

Comment 7

18 years ago
That's a good point. I'll look at the Carbon docs having to do with
FolderManager and see what the reccomendation is for a user data folder.
(Assignee)

Comment 8

18 years ago
Folders.h has the constant kSharedUserDataFolderType which sounds like what we
need. Will look at what it takes to make use of it.

Comment 9

18 years ago
Why not the Application Support folder? I believe it is present in 8.6 (the
functionality goes back to 8.1).
(Assignee)

Comment 10

18 years ago
I think we need to keep it where it is (in "Documents") on any pre-OSX machine
for the sake of QA, documentation, and support. On OS X, it should go in
kSharedUserDataFolderType. The problem I ran into when trying this was that
kSharedUserDataFolderType works on OS 9 as well which would introduce too much
of a change. I asked somebody and they said there was a Gestalt selector for
determing whether you were running Classic emulation on OS X but I could not
find it. If anybody knows the answer to this or knows what Gestalt returns for
the system version under Classic, it's easy.

Comment 11

18 years ago
rtm-, not supporting OS X in this release.  Good to look at for the trunk 
though.
OS: All
Whiteboard: [rtm-]
OS: All → MacOS X

Comment 12

17 years ago
enum {
    gestaltMacOSCompatibilityBoxAttr = FOUR_CHAR_CODE('bbox'),
                /* Classic presence and features */
    gestaltMacOSCompatibilityBoxPresent = 0,
                /* True if running under the Classic */
    gestaltMacOSCompatibilityBoxHasSerial = 1,
                /* True if Classic serial support is implemented. */
    gestaltMacOSCompatibilityBoxless = 2
                /* True if we're Boxless (screen shared with
                   Carbon/Cocoa) */
};

static Boolean RunningOnClassic(void)
{
    UInt32 response;

    return (Gestalt(gestaltMacOSCompatibilityBoxAttr,
                    (SInt32 *) &response) == noErr)
                && ((response && (1 << gestaltMacOSCompatibilityBoxPresent))
                    != 0);
}

Comment 13

17 years ago
That should detect whether a user is running in the Classic environment. Note
that this isn't possible using version 3.3.2 of the Universal Interfaces as they
don't contain these definitions. You'll need to wait until the 3.4 (currently
alpha 6) final release to do this (probably alongside CarbonLib 1.2 and Mac OS
9.1 in December/January).
(Assignee)

Comment 14

17 years ago
That would explain why I couldn't find that in the Universal Interfaces we're
building with. Large thanks though. This will do it.

Comment 15

17 years ago
Wouldn't this problem also occur for users with OS X installed on the same
drive/partition as Mac OS 9? The Documents folder would be in 'Mac HD/Mac OS 9/'
and not the root level. Then it wouldn't really matter whether the user was
running in Classic or real OS 9.
(Assignee)

Comment 16

17 years ago
Until we're building with the new headers, the Gestalt constants for testing for
Classic testing could be conditionally defined.
Target Milestone: --- → mozilla0.9
(Assignee)

Comment 17

17 years ago
I tried this with a clean install of OSX beta and 9.? on the same disk and it
worked. More recently, I tried this with OSX final and 9.1 on a different drive
and it worked.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.