Closed Bug 416609 Opened 16 years ago Closed 13 years ago

Select Profile dialog buttons do nothing until window is closed

Categories

(SeaMonkey :: Startup & Profiles, defect)

Product:
SeaMonkey
Component:
Startup & Profiles
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
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: 16 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: 16 years ago → 13 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.