Closed Bug 333681 Opened 17 years ago Closed 16 years ago
Switching profiles opens chatzilla
If I switch profiles from one particular profile, SeaMonkey opens chatzilla after swtiching profiles. The profile I switch to doesn't seem to matter (it happens with a pristine profile being switched to), but it does depend somewhat on the profile being switched from. If I remove prefs.js, the bug goes away. I can delete some prefs and still get the bug, but I have to leave a lot of prefs in, most of which seem entirely unrelated. I noticed this testing 1.0.1, but it also happens with 1.0 and trunk. During the profile switch, I get a ton of assertions. It looks like something is very seriously wrong.
This starts from where I switched profiles. Note the "Initializing ChatZilla" and "1.598 sec". The stuff between those is chatzilla opening.
Oh, also, after exiting and starting again, it asserts a lot about the fastload file, but it seems to recreate it at that point and further operation is more or less noraml.
Severity: normal → major
I believe this is caused by a lack of general.startup.chatzilla pref in the new profile; do we a) have UI for this pref b) have a default for this pref?
This fixes the problem at hand (opening chatzilla). The preferences we get from startupBranch->GetChildList include the chatzilla pref if it's set in my first profile, but actually trying to retrieve the value fails unless it's also set in the new profile. That seems really bad.
Are the old prefs still around because of: http://landfill.mozilla.org/mxr-test/seamonkey/source/modules/libpref/src/prefapi.cpp#580 ?
Attachment #218568 - Flags: approval-branch-1.8.1?(neil)
Comment on attachment 218568 [details] [diff] [review] handle pref retrieval failure (In reply to comment #5) >Are the old prefs still around because of: >http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/prefapi.cpp#580 >? Yes, basically.
Attachment #218568 - Flags: approval-branch-1.8.1?(neil) → approval-branch-1.8.1+
OK, I'll try to fix up the prefs backend problem in bug 193332
Assignee: nobody → ajschult
so this is fixed
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.