[PP] Crash opening preferences on Macintosh

VERIFIED FIXED in M4

Status

SeaMonkey
Preferences
P3
major
VERIFIED FIXED
19 years ago
13 years ago

People

(Reporter: Paul MacQuiddy, Assigned: mcmullen)

Tracking

Trunk
PowerPC
Mac System 8.5

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Using 41209 build on Macintosh, if you open the Preferences from the Edit Menu
*twice*, you will crash. You try to open it twice because nothing happens the
first time you open Preferences. Not sure if this is an M4 stopper or not. Will
mark as such.

No crash on windows 41211 though you still have to open prefs twice to get a
window. On unix you only have to open it once on 41208 build.

It's not that important because preferences really aren't functional yet, maybe
we should just disable it? I don't know.
(Reporter)

Updated

19 years ago
Target Milestone: M4

Updated

19 years ago
Assignee: matt → mcmullen

Comment 1

19 years ago
Reassigning to mcmullen since i don't have a mac build on my desk.
Works on windows?
(Assignee)

Comment 2

19 years ago
What date is the "41209" build from? These are the symptoms you get if there is
no preferences file. I checked in a fix for this last Friday, so it should be in
any build after that time.
(Reporter)

Comment 3

19 years ago
41209 means April 12 (today) 9am. It turns out these are actually M5 builds. The
official M4 builds are actually from April 9 (we just found out), and the
problem exists there also. Perhaps your check-in was into the M4 branch and we
actually haven't got builds yet that contain the fix? That would make the most
sense.
(Assignee)

Comment 4

19 years ago
Except that I checked in on the trunk. Dang.
(Assignee)

Comment 5

19 years ago
My windows M5 build from just now performs flawlessly. YOu don't even have to
open it twice.
(Reporter)

Comment 6

19 years ago
We'll be getting another M4 build later (today, I think). I'll check it out on
all platforms and report the results, then we can figure out if it needs to be
fixed in M4 branch.

Updated

19 years ago
Severity: normal → major

Updated

19 years ago
QA Contact: 3819 → 1698

Comment 7

19 years ago
elig, in an M4 mtg, mcmullen cannot reproduce this.  paulmac at home, can you
try to reproduce this on the mac with the following build and give us results
ASAP please?  We need a reproducible case in house!
ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-04-09-15/
If this is still occuring, we will release note for M4.
(Reporter)

Comment 8

19 years ago
Well, no Mac here (at home sick), but I reproduced it just yesterday with our
latest M4 builds, which are from Friday. Anyone is free to use the Mac in my
office.

Comment 9

19 years ago
Yup. Re-reproduced in cube using the most recent (Friday) M4 builds.

Comment 10

19 years ago
Wait. I didn't see a crash. I saw a user break/debugging assert. (Sorry, had
leftover Macsbug stuff from showing trudelle stuff yesterday, and didn't add two
plus two.)

I'll go check this in Paul's cubicle, and add comments as appropriate.

Comment 11

19 years ago
mcmullen, could you go see this in Eli's cube please?
(Assignee)

Comment 12

19 years ago
OK.

Comment 13

19 years ago
I've checked, and this is just a user break. It does quit the application if
you're not running Macsbug.

(Paul, I'd highly encourage you to run Macsbug on your system. I'll come by,
install the latest version, and show you the basics of how to use it if you don't
already know.)
(Reporter)

Comment 14

19 years ago
well, yeah I'd be happy to install macsbug, but it will still crash people who
don't have macsbug installed, so I don't really see the difference. (Keep in
mind I am fairly Mac-illiterate.)

Regardless, if it's not fixed in the M4 builds that come out today, it should
just be release-noted.

Comment 15

19 years ago
Sure. John agrees that it's valid whether user break or crash. (In general,
Macsbug makes a huge difference, since engineers can look at your crash and
generally get an idea of what happened, or whether it's a duplicate of another
crash that's invoked through other means. Especially if it's not fully
reproducible.)

P.S. I've stolen your last thin mint. muah ha ha ha ha
(Assignee)

Comment 16

19 years ago
I know what the problem is. The bug does not happen if you have a folder called
"Netscape {option-f}" in your preferences folder. I shall fix this now, by
creating the needed folder.
(Assignee)

Comment 17

19 years ago
I have the fix. Need permission to check in to the M4 branch.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

19 years ago
Fix checked in a few minutes ago. Hope I made the cut.

Comment 19

19 years ago
yes. this will make the next m4 candididate builds which we should start soon.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 20

19 years ago
Verified fixed using 4.13.99 afternoon M4 candidate build.

(Specifically, removed the Netscape ƒ folder that mcmullen created, and then
selected Preferences. No crash. Didn't crash on the second summoning of the
dialog, either.)

Thanks, John!

Comment 21

18 years ago
Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.
Component: Pref UI → Preferences
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.