Linux (1999-10-13-08 m11) commercial Steps: 1. Launch Messenger 2. Select Edit|Account Setup to open the Account Setings window 3. Click on the New Account button to open the Account Wizard 4. Click on the Finish button from the Account Wizard to close the Wizard 5. Click on the OK button of the Account Settings window ( or the Canel button) Actual result: The Account Settings Window blanks out but it does not close. It stays blank and sits there until I click on the window close button Expected result: expect the Account Settings window to close when I do step 5. Note: If I skip steps 3 and 4 above, it closes using step 5. Also, when I click on the window close button or select the Close drop-down menu, it closes the Account Setting dialog. This bug only occurs on Linux. It does not occur on Mac or win32 on the 10/13 builds.

This sounds like a toolkit issue. Reassigning to Pav since it's linux-specific but adding trudelle to CC in case this goes to someone else. The issue here is that the second dialog is a modal dialog...for some reason the first modal dialog does not close when you call window.close() if you have brough up a second modal dialog on top of it.

don't use modal dialogs. this is a feature I think... modal dialogs get all the events.. so when you pop up another one, the previous one gets the events..

No, that's not the problem. The problem is this: From messenger, bring up modal dialog #1 with window.openDialog() From modal dialog #1, bring up modal dialog #2 with window.openDialog() Close modal dialog #2 with window.close() close modal dialog #1 with window.close() modal dialog #1 is now a zombie window - the content disappears but the windows sticks around. this only happens on Linux.

very interesting. i will work with dan on this one

Nominate for dogfood

Putting on [PDT+] radar.

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

First, references to "index.xul" in the attachment descriptions above should be "main.xul". The issue is we have a dialog that can, via a toolbar button, display a simple modal dialog. If that occurs, closing the dialog (the one the pops up the modal) is buggy. If the modal dialog is not used, the close works as expected. The file main.xul has a button, that when clicked, brings up the dialog (dialog1.xul) and, in dialogs1's onload handler, the modal dialog that causes problems (dialog2.xul) is displayed. Dismiss the modal dialog, then use the file menu close item (the quit item is an artifact of my using an overlay for the menu) to close the dialog. The background of the dialog will clear, but the dialog itself will remain. If you comment out the onload handler code that brings up dialog2.xul, you will notice that the close menu item works just fine. Some notes: I haven't tried this bug on Windows but our IM bug was originally filed on Windows, now we seem, according to QA, to only see it on Linux. The point is it seems to rear its head on one or the other platform, for now, looks like Linux is the best bet. Other thing is I seem only able to traverse the file menu with arrow keys, clicking on the close menu item does nothing. But arrow keying to the item and hitting return works. This is not a problem in the IM situation, and I believe it has no relevance to the bug at hand.

It was the usual "someone holding a reference to the widget never lets go" problem. Added another release of the parent to the twitchy gtk widget destruction code.

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

This is SO *^$%(*)#% re-broken this morning. (*&@%^!@&*%@^#@#

It's broken. It's my fault. I think that I have a patch now but pavlov needs to have a look at it before I go checking it in. If anyone can dig the old man up...

reopened, so clearing resolution.

Ok, pavlov reviewed the patch and thought that it looked ok. Let me know if it works for you. Again, sorry for causing this regression.

On this morning's build, this problem is more pronounced even from yesterday. Recalling the one glorious day when this worked and the strange coincidence of the landing of Superwin code with its breakage, I'm transferring this bug to pavlov. See also probably related bug 19255.

Linux Redhat 6.0 (1999-11-24-08 M12) In today's build. Use the original steps and continue onto step 5. 1. After I click OK. The right pane blanks out initially and eventually the left pane also blanks out. It does not close. 2. Set focus back to the Messenger 3. Back to the Setup dialog and click on the title bar, it crashes about 50% of the time.

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

I'm pretty sure this has been fixed. Someone should probably test it out.

Build 1999120208M12: Linux The problem is still present. After creating an IMAP or POP account with the Account Wizard, the new account displays in the Account Settings window. I select "OK" and the Account Settings window becomes grey/blank. These are the results after trying to create an account 3 different times: - Selecting the "X" box to the close the window caused it to crash. - Selecting the Control menu caused it to crash - clicking on the 3-pane window, clicking back to the blank Account Settings window, then trying to close this window does nothing. The zombie window remains.

I can't reproduce this because I just get a crash in the code: #0 0x41072218 in nsEventListenerManager::ReleaseListeners (this=0x891f2a8, aListeners=0x891f2b4, aScriptOnly=0) at nsEventListenerManager.cpp:166 #1 0x41071ce5 in nsEventListenerManager::~nsEventListenerManager ( this=0x891f2a8, __in_chrg=3) at nsEventListenerManager.cpp:81 #2 0x41071e86 in nsEventListenerManager::Release (this=0x891f2a8) at nsEventListenerManager.cpp:95 #3 0x412b643e in nsGenericElement::~nsGenericElement (this=0x891ea18, __in_chrg=2) at nsGenericElement.cpp:185 #4 0x412b98bb in nsGenericContainerElement::~nsGenericContainerElement ( this=0x891ea18, __in_chrg=2) at nsGenericElement.cpp:1407 #5 0x41253051 in nsGenericXMLElement::~nsGenericXMLElement (this=0x891ea18, __in_chrg=2) at nsGenericXMLElement.cpp:67 #6 0x4125150d in nsXMLElement::~nsXMLElement (this=0x891ea00, __in_chrg=3) at nsXMLElement.cpp:76 #7 0x41284f53 in AnonymousElement::~AnonymousElement (this=0x891ea00, __in_chrg=3) at ../../../../dist/include/nsCOMPtr.h:515 #8 0x412518c6 in nsXMLElement::Release (this=0x891ea00) at nsXMLElement.cpp:96 #9 0x41284156 in AnonymousElement::Release (this=0x891ea00) at nsScrollbarFrame.cpp:215 #10 0x41075d09 in nsEventStateManager::~nsEventStateManager (this=0x891dfe8, __in_chrg=3) at nsEventStateManager.cpp:116 #11 0x41075f90 in nsEventStateManager::Release (this=0x891dfe8) at nsEventStateManager.cpp:133 ---Type <return> to continue, or q <return> to quit--- #12 0x4133e724 in nsCOMPtr<nsIEventStateManager>::~nsCOMPtr (this=0x890f8a0, __in_chrg=2) at ../../../dist/include/nsCOMPtr.h:433 #13 0x412c162a in nsPresContext::~nsPresContext (this=0x890f7e0, __in_chrg=0) at nsPresContext.cpp:115 #14 0x412b33fa in GalleyContext::~GalleyContext (this=0x890f7e0, __in_chrg=3) at nsGalleyContext.cpp:44 #15 0x412c17b2 in nsPresContext::Release (this=0x890f7e0) at nsPresContext.cpp:119 #16 0x412efd64 in nsCOMPtr<nsIPresContext>::~nsCOMPtr (this=0x890f758, __in_chrg=2) at ../../../dist/include/nsCOMPtr.h:433 #17 0x412a88d4 in DocumentViewerImpl::~DocumentViewerImpl (this=0x890f728, __in_chrg=3) at nsDocumentViewer.cpp:320 #18 0x412a84b5 in DocumentViewerImpl::Release (this=0x890f728) at nsDocumentViewer.cpp:252 #19 0x40c17ba2 in nsWebShell::Destroy (this=0x88c2bb8) at nsWebShell.cpp:3784 #20 0x411a6306 in nsGfxTextControlFrame::~nsGfxTextControlFrame ( this=0x895f4d0, __in_chrg=3) at nsGfxTextControlFrame.cpp:300 #21 0x410955d8 in nsFrame::Destroy (this=0x895f4d0, aPresContext=0x8920e10) at nsFrame.cpp:407 #22 0x410b414b in nsLineBox::DeleteLineList (aPresContext=0x8920e10, aLine=0x8884828) at nsLineBox.cpp:232 #23 0x41083613 in nsBlockFrame::Destroy (this=0x895f448, aPresContext=0x8920e10) at nsBlockFrame.cpp:1122 ---Type <return> to continue, or q <return> to quit--- #24 0x410b414b in nsLineBox::DeleteLineList (aPresContext=0x8920e10, aLine=0x8884850) at nsLineBox.cpp:232 #25 0x41083613 in nsBlockFrame::Destroy (this=0x895f378, aPresContext=0x8920e10) at nsBlockFrame.cpp:1122 #26 0x412b0783 in nsFrameList::DestroyFrames (this=0x895f0e4, aPresContext=0x8920e10) at nsFrameList.cpp:34 #27 0x41090ebd in nsContainerFrame::Destroy (this=0x895f0b0, aPresContext=0x8920e10) at nsContainerFrame.cpp:94 #28 0x412b0783 in nsFrameList::DestroyFrames (this=0x895ebfc, aPresContext=0x8920e10) at nsFrameList.cpp:34 #29 0x41090ebd in nsContainerFrame::Destroy (this=0x895ebc8, aPresContext=0x8920e10) at nsContainerFrame.cpp:94 #30 0x412b0783 in nsFrameList::DestroyFrames (this=0x895ebbc, aPresContext=0x8920e10) at nsFrameList.cpp:34 #31 0x41090ebd in nsContainerFrame::Destroy (this=0x895eb88, aPresContext=0x8920e10) at nsContainerFrame.cpp:94 #32 0x412b0783 in nsFrameList::DestroyFrames (this=0x895eb7c, aPresContext=0x8920e10) at nsFrameList.cpp:34 #33 0x41090ebd in nsContainerFrame::Destroy (this=0x895eb48, aPresContext=0x8920e10) at nsContainerFrame.cpp:94 #34 0x410d8326 in ViewportFrame::Destroy (this=0x895eb48, aPresContext=0x8920e10) at nsViewportFrame.cpp:137 #35 0x4109ca16 in FrameManager::~FrameManager (this=0x88f8988, __in_chrg=3) ---Type <return> to continue, or q <return> to quit--- at nsFrameManager.cpp:340 #36 0x4109c962 in FrameManager::Release (this=0x88f8988) at nsFrameManager.cpp:326 #37 0x410c1245 in PresShell::~PresShell (this=0x8957a00, __in_chrg=3) at nsPresShell.cpp:601 #38 0x410c0f04 in PresShell::Release (this=0x8957a00) at nsPresShell.cpp:532 #39 0x412ebc44 in nsCOMPtr<nsIPresShell>::~nsCOMPtr (this=0x8961e44, __in_chrg=2) at ../../../dist/include/nsCOMPtr.h:433 #40 0x412a88c6 in DocumentViewerImpl::~DocumentViewerImpl (this=0x8961e10, __in_chrg=3) at nsDocumentViewer.cpp:320 #41 0x412a84b5 in DocumentViewerImpl::Release (this=0x8961e10) at nsDocumentViewer.cpp:252 #42 0x40c0e63d in nsWebShell::Embed (this=0x8867ed0, aContentViewer=0x8995d98, aCommand=0x891a7f0 "view", aExtraInfo=0x0) at nsWebShell.cpp:870 #43 0x40c0bc14 in nsDocumentBindInfo::OnStartRequest (this=0x8995c00, channel=0x8993128, ctxt=0x0) at nsDocLoader.cpp:1394 #44 0x40cf6453 in nsDocumentOpenInfo::OnStartRequest (this=0x8992cf8, aChannel=0x8993128, aCtxt=0x0) at nsURILoader.cpp:200 #45 0x40c0c850 in nsChannelListener::OnStartRequest (this=0x89936f8, aChannel=0x8993128, aContext=0x0) at nsDocLoader.cpp:1580 #46 0x405f321f in nsFileChannel::OnStartRequest (this=0x8993128, transportChannel=0x89935e8, context=0x0) at nsFileChannel.cpp:482 #47 0x405b1e92 in nsOnStartRequestEvent::HandleEvent (this=0x406056c0) ---Type <return> to continue, or q <return> to quit--- at nsAsyncStreamListener.cpp:198 #48 0x405b17f7 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x406056d8) at nsAsyncStreamListener.cpp:93 #49 0x401b436b in PL_HandleEvent (self=0x406056d8) at plevent.c:522 #50 0x401b427c in PL_ProcessPendingEvents (self=0x87993a8) at plevent.c:483 #51 0x4016ba59 in nsEventQueueImpl::ProcessPendingEvents (this=0x8799380) at nsEventQueue.cpp:193 #52 0x40760a5c in event_processor_callback (data=0x8799380, source=14, condition=GDK_INPUT_READ) at nsAppShell.cpp:233 #53 0x4076036f in our_gdk_io_invoke (source=0x8799480, condition=G_IO_IN, data=0x8799470) at nsAppShell.cpp:54 #54 0x409a5d6a in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #55 0x409a72c6 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #56 0x409a7801 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #57 0x409a78a3 in g_main_iteration () from /usr/lib/libglib-1.2.so.0 #58 0x40761107 in nsAppShell::DispatchNativeEvent (this=0x8813db8, aRealEvent=0, aEvent=0x0) at nsAppShell.cpp:438 #59 0x40540972 in nsWebShellWindow::ShowModalInternal (this=0x87994c8) at nsWebShellWindow.cpp:1768 #60 0x40540761 in nsWebShellWindow::ShowModal (this=0x87994c8) at nsWebShellWindow.cpp:1730 #61 0x40540bee in nsWebShellWindow::ShowModally (this=0x87994c8, aPrepare=0) at nsWebShellWindow.cpp:1806 ---Type <return> to continue, or q <return> to quit--- #62 0x404322c6 in GlobalWindowImpl::OpenInternal (this=0x8541e18, cx=0x8541ed8, argv=0x8709b3c, argc=4, aDialog=1, aReturn=0xbfffc518) at nsGlobalWindow.cpp:2263 #63 0x404317d0 in GlobalWindowImpl::OpenDialog (this=0x8541e18, cx=0x8541ed8, argv=0x8709b3c, argc=4, aReturn=0xbfffc518) at nsGlobalWindow.cpp:2124 #64 0x40426298 in WindowOpenDialog (cx=0x8541ed8, obj=0x858e380, argc=4, argv=0x8709b3c, rval=0xbfffc5c4) at nsJSWindow.cpp:2546 #65 0x4008832e in js_Invoke (cx=0x8541ed8, argc=4, flags=0) at jsinterp.c:665 #66 0x40096aa1 in js_Interpret (cx=0x8541ed8, result=0xbfffcf8c) at jsinterp.c:2226 #67 0x4008838d in js_Invoke (cx=0x8541ed8, argc=0, flags=0) at jsinterp.c:681 #68 0x40096aa1 in js_Interpret (cx=0x8541ed8, result=0xbfffd980) at jsinterp.c:2226 #69 0x4008838d in js_Invoke (cx=0x8541ed8, argc=0, flags=0) at jsinterp.c:681 #70 0x40096aa1 in js_Interpret (cx=0x8541ed8, result=0xbfffe374) at jsinterp.c:2226 #71 0x4008838d in js_Invoke (cx=0x8541ed8, argc=0, flags=0) at jsinterp.c:681 #72 0x40096aa1 in js_Interpret (cx=0x8541ed8, result=0xbfffed68) at jsinterp.c:2226 #73 0x4008838d in js_Invoke (cx=0x8541ed8, argc=1, flags=2) at jsinterp.c:681 #74 0x400886a8 in js_InternalCall (cx=0x8541ed8, obj=0x858e380, fval=140046424, argc=1, argv=0xbfffefd8, rval=0xbfffeecc) at jsinterp.c:758 #75 0x4005d579 in JS_CallFunctionValue (cx=0x8541ed8, obj=0x858e380, ---Type <return> to continue, or q <return> to quit--- fval=140046424, argc=1, argv=0xbfffefd8, rval=0xbfffeecc) at jsapi.c:2752 #76 0x4041cc89 in nsJSContext::CallFunctionObject (this=0x8541ea8, aObj=0x858e380, aFunObj=0x858f058, argc=1, argv=0xbfffefd8, aBoolResult=0xbfffef28) at nsJSEnvironment.cpp:540 #77 0x40457c29 in nsJSEventListener::HandleEvent (this=0x8769c80, aEvent=0x88007dc) at nsJSEventListener.cpp:128 #78 0x41073af9 in nsEventListenerManager::HandleEventSubType (this=0x87469c8, aListenerStruct=0x8769cb0, aDOMEvent=0x88007dc, aSubType=1) at nsEventListenerManager.cpp:632 #79 0x41074faa in nsEventListenerManager::HandleEvent (this=0x87469c8, aPresContext=0x831c460, aEvent=0xbffff604, aDOMEvent=0xbffff384, aFlags=7, aEventStatus=0xbffff644) at nsEventListenerManager.cpp:1168 #80 0x40434ab1 in GlobalWindowImpl::HandleDOMEvent (this=0x8541e18, aPresContext=0x831c460, aEvent=0xbffff604, aDOMEvent=0xbffff384, aFlags=1, aEventStatus=0xbffff644) at nsGlobalWindow.cpp:2969 #81 0x40c15289 in nsWebShell::OnEndDocumentLoad (this=0x8541438, loader=0x85415d8, channel=0x854b758, aStatus=0, aWebShell=0x8541448) at nsWebShell.cpp:2992 #82 0x40c0ad1a in nsDocLoaderImpl::FireOnEndDocumentLoad (this=0x85415d8, aLoadInitiator=0x85415d8, aDocChannel=0x854b758, aStatus=0) at nsDocLoader.cpp:1087 #83 0x40c0a9c3 in nsDocLoaderImpl::DocLoaderIsEmpty (this=0x85415d8, aStatus=0) at nsDocLoader.cpp:977 ---Type <return> to continue, or q <return> to quit--- #84 0x40c0a810 in nsDocLoaderImpl::OnStopRequest (this=0x85415d8, aChannel=0x8783f60, aCtxt=0x0, aStatus=0, aMsg=0x0) at nsDocLoader.cpp:917 #85 0x405c52d2 in nsLoadGroup::RemoveChannel (this=0x8541638, channel=0x8783f60, ctxt=0x0, status=0, errorMsg=0x0) at nsLoadGroup.cpp:531 #86 0x405f32e3 in nsFileChannel::OnStopRequest (this=0x8783f60, transportChannel=0x87845d8, context=0x0, aStatus=0, aMsg=0x0) at nsFileChannel.cpp:495 #87 0x405b210d in nsOnStopRequestEvent::HandleEvent (this=0x406090e0) at nsAsyncStreamListener.cpp:278 #88 0x405b17f7 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x4060ec28) at nsAsyncStreamListener.cpp:93 #89 0x401b436b in PL_HandleEvent (self=0x4060ec28) at plevent.c:522 #90 0x401b427c in PL_ProcessPendingEvents (self=0x80a5c30) at plevent.c:483 #91 0x4016ba59 in nsEventQueueImpl::ProcessPendingEvents (this=0x80a5c08) at nsEventQueue.cpp:193 #92 0x40760a5c in event_processor_callback (data=0x80a5c08, source=7, condition=GDK_INPUT_READ) at nsAppShell.cpp:233 #93 0x4076036f in our_gdk_io_invoke (source=0x814d8b8, condition=G_IO_IN, data=0x811b2a8) at nsAppShell.cpp:54 #94 0x409a5d6a in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0 #95 0x409a72c6 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0 #96 0x409a7801 in g_main_iterate () from /usr/lib/libglib-1.2.so.0 #97 0x409a7979 in g_main_run () from /usr/lib/libglib-1.2.so.0 ---Type <return> to continue, or q <return> to quit--- #98 0x4087ccf9 in gtk_main () at gtkmain.c:476 #99 0x40761035 in nsAppShell::Run (this=0x80b4db8) at nsAppShell.cpp:404 #100 0x40538851 in nsAppShellService::Run (this=0x80a5a10) at nsAppShellService.cpp:488 #101 0x804bfed in main1 (argc=1, argv=0xbffffb74) at nsAppRunner.cpp:611 #102 0x804c339 in main (argc=1, argv=0xbffffb74) at nsAppRunner.cpp:679 (gdb)

The crash seems to have gone away. However, I can't reproduce this problem. There are never gray windows, you always seem to be able to close the windows.

Do you still see this? I tried it just a minute ago and it looks fine.

And if you do see this, what version of GTK are you using?

Tried to duplicate the scopus bug that led to my filing this in the first place, and marked it works for me cause it doesn't happen any more.

blizzard: You say you can't make windows go empty as if it were a bad thing! Problem seems fixed to me in today's build. I say mark it "fixed."

Not fixed, that is supposed to mean "A fix for this bug is checked into the tree and tested." This one should probably be closed as worksforme.

a fix was checked in to the tree for this problem.

Great, but when? There is no comment other than a lot of "seems fixed", "can't reproduce", "doesn't happen anymore". Resolution comment should include date of fix for efficient regression testing.

Build 1999120708M12: Linux/Redhat 6.0 Verified Fixed. After creating a new account with the Account Wizard, focus goes to the Account Settings window. After selecting the "OK" or "Cancel" button, focus goes to the 3-Pane view as expected. The zombie window no longer appears. Thanks!

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