User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050904 SeaMonkey/1.1a Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050904 SeaMonkey/1.1a My mozilla/seamonkey installation has two profiles: one for Mozilla 1.7, one for SeaMonkey nightly. After starting SeaMonkey, the profile manager dialog (the one with title "Select User Profile") appears. After selecting a profile and clicking "Start SeaMonkey" button, the dialog window is not destroyed. Pressing Windows close button doesn't help. The dialog closes only when the whole application is closed. Reproducible on the today's nightly (see UA string, 2005-09-04). Reproducible: Always Steps to Reproduce:

Is this a recent problem or when did this start to occour?

Well, I didn't use SeaMonkey nightlies before. After trying some investigation, the problem seems to be worse: sometimes the dialog is (unfortunately) correctly destroyed. I have seen the problem like this with Preferences dialog several times as well.

> dialog is (unfortunately) correctly destroyed. I have seen the problem like this > with Preferences dialog several times as well. That's bug 306925.

Sometimes reproducible with SeaMonkey/20050902, -3 and -4, especially when I cancel the creation of a new profile and use a different profile (Tools > Switch Profile > Manage Profiles > Create Profile... > Cancel, select a different profile, > Use Profile).

It's possible this bug is related to bug 307153 which was fixed today. Vladislav, tomorrow, try the nightly build to see if the problem still occurs in Profile manager window. Ok? I'll do the same for bug 306925

(In reply to comment #5) > It's possible this bug is related to bug 307153 which was fixed today. > Vladislav, tomorrow, try the nightly build to see if the problem still occurs in > Profile manager window. Ok? > I'll do the same for bug 306925 On the today's nightly it is still reproducible. I'll wait however for the next build... My build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050907 SeaMonkey/1.1a, build ID: 2005090705

I see this bug in Seamonkey 1.1a rv:1.9a1 build 2005090806 under XP Pro SP2 while using Modern theme. It has the same visual symptoms as bug 306925; the thing is that it's possibly the same bug happening but applied to another modal+dialog window. So probably, Component field in this is incorrect. CONFIRMING adding smoketest keyword since the profile manager window does not close properly http://www.mozilla.org/quality/smoketests/#install

Can someone confirm the bug on other Windows versions? Other OSes (*nix, Mac)? (In reply to comment #7) > modal+dialog window. So probably, Component field in this is incorrect. What might be the correct Component? "XP Apps" should be incorrect if no one can confirm on Unices or Mac. "General"?

Saw the bug one time with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 SeaMonkey/1.0a (todays branch build).

I seem to see this happen most frequently when starting a new nightly build for the first time or when I've patched jar files and starting for the first time after that which seems to suggest some sort of chrome rebuild time issue. The size of my localstore.rdf is 91K What size are other peoples'?

I saw this only immediately after installing the 2005090913 1.8 branch build, which is the only build since August 12 I've used. My localstore.rdf (actually both of them) is 957 bytes.

It happens in Classic theme too and with a brand new profile too. I do not even have to make any changes in any category. I just have to change category and click OK but I have to do this 3 or 4 times. The bug is not reproducible 100%: I can not find a precise, specific set of steps to reproduce. I can reproduce it when switching category and clicking OK and if the Preferences window closes, then I can try again and usually at the 3rd or 4th attempt or so, the Preferences window remains opened.

argh... forget about my previosu comment: it should have been posted in bug 306925 instead.

(In reply to comment #10) > I seem to see this happen most frequently when starting a new nightly build for > the first time or when I've patched jar files and starting for the first time > after that which seems to suggest some sort of chrome rebuild time issue. Well, at my side it happens quite often (more then 50% cases) just at start, without doing anything special. > The size of my localstore.rdf is 91K > > What size are other peoples'? My one is 29853 bytes. I use Classic theme, installed one extension (prefbar). OS is WinXP w/SP2, if it matters.

I'm not sure if this is related but when I run seamonkey.exe (built with mingw/cygwin) with gdb each time it tries to get rid of a dialog box it stops with an error message similar to: warning: HEAP[seamonkey.exe]: warning: HEAP: Free Heap block 30fa8c8 modified at 30fa93c after it was freed Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c901231 in ntdll!DbgUiConnectToDbg () from ntdll.dll

I've downloaded a SeaMonkey built on 10.09 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050910 SeaMonkey/1.1a, build ID: 2005091005) and cannot reproduce the bug anymore. Perhaps the bug is bitrotted? ;-) Can someone still reproduce it? [Cannot test on the latest nightlies because they fail to start after successful installation; I should report this as well.]

(In reply to comment #16) <snip> > > [Cannot test on the latest nightlies because they fail to start after successful > installation; I should report this as well.] This is already filed as bug 308838.

(In reply to comment #16) > I've downloaded a SeaMonkey built on 10.09 (Mozilla/5.0 (Windows; U; Windows NT > 5.1; en-US; rv:1.9a1) Gecko/20050910 SeaMonkey/1.1a, build ID: 2005091005) and > cannot reproduce the bug anymore. > > Perhaps the bug is bitrotted? ;-) > > Can someone still reproduce it? Yes it is still happening, testing using zip builds ID 2005092505

(In reply to comment #18) > Yes it is still happening, testing using zip builds ID 2005092505 OK, I can reproduce this now as well; however with the build 2005-09-10-05 I'm using it happens considerably less often.

*** Bug 311245 has been marked as a duplicate of this bug. ***

Duping to bug 307563, dedupe if the patch doesn't fix this. *** This bug has been marked as a duplicate of 307563 ***

removing nomination, as this is a duplicate (and the bug seems fixed on branch?)

(In reply to comment #22) Yes, at least I cannot reproduce the bug anymore.