Closed Bug 416609 Opened 17 years ago Closed 14 years ago

Select Profile dialog buttons do nothing until window is closed

Categories

(SeaMonkey :: Startup & Profiles, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: nelson, Unassigned)

Details

(Keywords: regression)

This problem began somewhere between 20080123 and 20080203 and is presently seen in 20080207 I have multiple profiles. When I start SeaMonkey, I see a dialog that says "Select Profile", and has buttons that say "Manage Profiles", "Start SeaMonkey" and "Exit". My default profile is selected by default (of course :). The problem is that clicking those buttons does nothing ... until I forcibly close that dialog window by clicking the big red [X] in the Windows title bar. Then, when I do that, the action of the button I clicked finally takes place. For example, if I click "Start SeaMonkey", nothing happens. But if I then click the big red [X], the dialog window goes away and SeaMonkey starts. SeaMonk
Flags: blocking-seamonkey2.0a1?
To narrow the regression window slightly, it was working OK in 20080125.
Keywords: regression
Works fine here on my current Linux build.
Works fine in my current Windows build. If you start SeaMonkey using the option to select a profile from the command line and then select Tools/Switch Profile, do the buttons work then? If not, are there any exceptions in the JavaScript^H^H^H^H^H^H^H^H^H^HError Console?
Try a nightly build. Maybe there's something wrong with them. The switch profile dialog worked as expected. But the Select Profile dialog at startup continues to fail as described in comment 0.
After starting SM, clicking "Start SeaMonkey" and then clicking the [X] button, the XRE_CONSOLE_LOG reports: *** Console log: 2008-02-21 12:49:16 *** [JavaScript Error: "window.close is not a function" {file: "chrome://global/cont ent/bindings/dialog.xml" line: 335}] [JavaScript Error: "window.close is not a function" {file: "chrome://global/cont ent/bindings/dialog.xml" line: 335}]
Still present in Gecko/2008021702
When I install SM nightlies, there are 4 checkboxes for various optional components. They include things like the DOM inspector, Javascript debugger, QA/Debug menu items, and other things (I forget). I uncheck them all except for the QA/Debug menu items. Perhaps that is relevant to why I see this continually, every time I start SM trunk (100%) since I filed this, a month ago today, but others claim to not see it.
This bug vanished in the 20080403 nightly trunk build, and I haven't seen it since. It was fixed sometime between 20080317 and 20080403.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
It's back with a vengeance in Gecko/2008050602
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This bug is apparently only in the nightly trunk builds, not in peoples' own personal builds. It has been on and off for months. It was present for most of February and March, then gone for most of April, and then present again for all of May so far. Can someone please look at this? Comment 5 should be a big clue.
Status: REOPENED → NEW
Is this currently happening on a recent trunk nightly? I use trunk nightlies regularly and have multiple profiles but I have not seen this issue yet. Not blocking 2.0a1 on this issue.
Flags: blocking-seamonkey2.0a1? → blocking-seamonkey2.0a1-
Ian, This happens to me every single time I start SM, without exception, every day, every SM trunk nightly. I suspect that you don't install the downloadable SM builds, but rather test your own builds. As such, the set of things installed on your system is different that the set installed by people who install the nightly installers.
Note especially comment 5.
(In reply to comment #12) > Ian, > This happens to me every single time I start SM, without exception, > every day, every SM trunk nightly. > > I suspect that you don't install the downloadable SM builds, but rather > test your own builds. As such, the set of things installed on your > system is different that the set installed by people who install the > nightly installers. > Note that I did say "I use trunk nightlies regularly", that means that I do install the downloadable SM builds. Do you update or download? If download, do you remove the old version before installing the new one or just overwrite?
I always download, since if I enable update, I lose all control over what I'm running. The installer always offers to install in the same directory where it was previously installed, and I most often let it do that, but occasionally I make a new directory, so that I can preserve an existing old version should I need to fall back. I have a separate icon on my desktop for each directory, so that I can start the version I need. But I don't go backwards to older versions unless I've decided that the new one is just too broken to use. I never do the "express" install (or whatever the option is called that removes all user choices and options). I choose not to install the DOM inspector and the Javascript debugger. I also don't install any new startup icons UNLESS I'm installing into a new directory. The old icons work fine for the existing directories.
I have played with this a lot, and have determined that the problem occurs when a new SM trunk nightly installer is installed in the same directory where a previous version of SM trunk was installed. When I install a SM trunk installer in a fresh directory, this problem is not seen. If I then install newer nightly installers in the same directory, (the EXACT same way that SM 1.1.x users install updates, I might add), then it doesn't take many of these "updtes" before the problem reappears. So, for now, to work around this problem, I am using this technique. I have 3 directories into which I install nightlies. Each time I go to try a newer nightly, I blow away the contents of the oldest of the 3 directories, and then run the installer to install the latest one in the newly emptied directory. This seems to work around the problem.
Ever since I started using the technique described in comment 16, I have had no more problems. I must re-install all my extensions again each time I update. But it's clear to me now, in retrospect, that you just cannot install a new full-installer download into a directory where a previous version has been installed. So, I suppose that errors that occur after trying to install in a directory with an old version can be considered user error. But the installer does allow it. Maybe the installer should say "You're trying to install this full installation into a directory with an old version of the program, and that won't work." and refuse to do it.
The installer should actually clean out everything from and old install that might create problems. You shouldn't need to re-install extensions though, as they usually get installed in the profile in 2.x, and I'd really recommend going through the internal installation routine and therefore doing that if you update/reinstall a lot, exactly because you don't need to wipe them every time in that case. All that said, installing over a previous 2.x version should work, we have the removed-files list exactly for the reason that installer and update mechanism know which files to delete before installing their new ones.
Robert, I agree with you. It *should* work. But I've got WAY too much experience with it not working that I can't and won't ignore or forget.
Sure, and if there is a bug, we should try to find out what it is specifically and try to fix it. Do we have clear steps to reproduce? Do we have a smoking gun?
Does this still happen?
Whiteboard: [CLOSEME 2011-02-01 WFM]
No reply from reporter --> Resolved.Worksforme Reopen if you can reproduce with using an recent Build, and submit actual information, see Comment 20.
Status: NEW → RESOLVED
Closed: 17 years ago14 years ago
Resolution: --- → WORKSFORME
Whiteboard: [CLOSEME 2011-02-01 WFM]
You need to log in before you can comment on or make changes to this bug.