Closed Bug 385231 Opened 18 years ago Closed 18 years ago

Can't start Seamonkey, profile chooser buttons are blank

Categories

(SeaMonkey :: Startup & Profiles, defect)

x86
Windows XP
defect
Not set
blocker

Tracking

(Not tracked)

RESOLVED WORKSFORME
seamonkey2.0a1

People

(Reporter: nelson, Unassigned)

Details

Attachments

(1 file)

Trunk, SM 3.0a1 builds This behavior started sometime between June 12 and June 16, 2007 and is still seen in today's nightly trunk SM build. My SM 2.0a1 profile is configured to always show the profile chooser on startup. Sometime between June 12 and today, it changed, so that the two buttons at the bottom of that little dialog (normally "Start Seamonkey..." and "Exit") are now entirely blank. Consequently, clicking on them does nothing. The only action that works is to click the window close button in the upper right hand corner, in the title bar. This is on Windows XP. This stops ALL further ability to test 2.0a1, because I CANNOT get SM to get past that profile selector dialog any more. Screen shot to follow.
Flags: blocking-seamonkey2.0a1?
I tried the following: In the menu: Tools > Switch profile.. > then I got a blank window and the following message jar:file:///home/bes/suite/seamonkey/chrome/comm.jar!/content/communicator/profile/profileSelection.xul cannot be found. Please check the location and try again. Consequently there is no way to switch profiles. Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/2007062017 SeaMonkey/2.0a1pre
I think comment 2 is probably unrelated to comment 0. The profile chooser sees the profiles and displays them. I'm told that, after SM gets started in one of the profiles, it loses the ability to see the list of profiles after that. If true, that explains the lack of ability to switch profiles after getting going in one. But this bug is about an inability to get past the profile chooser when SM starts up.
Ok, comment 2 shall refer to Bug 382792 – can not switch Profile (edit). It is similar to this bug, but not necessary related.
This seems to be fixed in Gecko/200708100202 SeaMonkey/2.0a1pre ! I wish I knew what checkin to credit the fix to.
Status: NEW → RESOLVED
Closed: 18 years ago
Flags: blocking-seamonkey2.0a1?
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.0alpha
If the fix is unknown, then: -> WORKSFORME
Resolution: FIXED → WORKSFORME
WorksForMe amounts to a denial that the bug ever existed. This bug existed in many builds, for weeks.
Yeah, I also saw this bug. Strange though that I cannot reproduce it anymore, even with older builds from June. From a bug triager's point of view though the WFM resolution is "correct" (or at least I know it that way): When there's no reference to another bug or patch which has fixed the issue mentioned in a bug, then that bug is normally resolved as WFM.
> From a bug triager's point of view though the WFM resolution is "correct" For the purposes of QA, FIXED really means "fixed by something we can identify". A resolution of WORKSFORME, does not mean that it always works, it really just means "it works now" - either because it wasn't broken (which it was in this case) or because it was fixed, but what fixed it is unknown (which is the case here).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: