16310 - [DOGFOOD][PP]Regression: Modal on top of modal leaves zombie window.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Account Configuration, defect, P3)

Description

[fenella]

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.

Comment 1

[Alec Flett]

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.

Comment 2

[Stuart Parmenter]

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..

Comment 3

[Alec Flett]

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.

Comment 4

[Stuart Parmenter]

very interesting.  i will work with dan on this one

Comment 5

[Phil Peterson]

Nominate for dogfood

Comment 6

[leger]

Putting on [PDT+] radar.

Comment 7

[Syd Logan]

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

Comment 8

[Syd Logan]

Attachment: mail.xul - load this into browser e.g. resource:/res/../index.xul

Comment 9

[Syd Logan]

Attachment: Place in same dir as index.xul

Comment 10

[Syd Logan]

Attachment: place in same dir as main.xul

Comment 11

[Syd Logan]

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.

Comment 12

[Dan M]

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.

Comment 13

[Alec Flett]

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

Comment 14

[Dan M]

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

Comment 15

[Christopher Blizzard (:blizzard)]

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...

Comment 16

[lchiang]

reopened, so clearing resolution.

Comment 17

[Christopher Blizzard (:blizzard)]

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.

Comment 18

[Dan M]

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.

Comment 19

[fenella]

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.

Comment 20

[Dan M]

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

Comment 21

[Christopher Blizzard (:blizzard)]

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

Comment 22

[Ninoschka Baca]

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.

Comment 23

[Christopher Blizzard (:blizzard)]

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)

Comment 24

[Christopher Blizzard (:blizzard)]

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.

Comment 25

[Stuart Parmenter]

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

Comment 26

[Christopher Blizzard (:blizzard)]

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

Comment 27

[Syd Logan]

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.

Comment 28

[Dan M]

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."

Comment 29

[Peter Trudelle]

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.

Comment 30

[Stuart Parmenter]

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

Comment 31

[Peter Trudelle]

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.

Comment 32

[Ninoschka Baca]

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!

Comment 33

[Dan M]

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