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

VERIFIED FIXED in M12

Status

SeaMonkey
MailNews: Account Configuration
P3
normal
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: fenella, Assigned: Stuart Parmenter)

Tracking

Trunk
Other
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+] 12/7/99)

Attachments

(3 attachments)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Assignee: alecf → pavlov
Summary: [PP]Regression:Account Setup window does not close after using New Account → [PP]Regression: Modal on top of modal leaves zombie window.

Comment 1

19 years ago
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.
(Assignee)

Updated

19 years ago
Assignee: pavlov → danm
(Assignee)

Comment 2

19 years ago
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..

Updated

19 years ago
QA Contact: lchiang → nbaca

Comment 3

19 years ago
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.
(Assignee)

Comment 4

19 years ago
very interesting.  i will work with dan on this one

Updated

19 years ago
Summary: [PP]Regression: Modal on top of modal leaves zombie window. → [DOGFOOD][PP]Regression: Modal on top of modal leaves zombie window.

Comment 5

19 years ago
Nominate for dogfood

Updated

19 years ago
Whiteboard: [PDT+]

Comment 6

19 years ago
Putting on [PDT+] radar.

Comment 7

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

Comment 8

19 years ago
Created attachment 2460 [details]
mail.xul - load this into browser e.g. resource:/res/../index.xul

Comment 9

19 years ago
Created attachment 2461 [details]
Place in same dir as index.xul

Comment 10

19 years ago
Created attachment 2462 [details]
place in same dir as main.xul

Comment 11

19 years ago
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.

Updated

19 years ago
Blocks: 17513

Updated

19 years ago
Target Milestone: M13

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Target Milestone: M13 → M12

Updated

19 years ago
Blocks: 18951

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+] sched 21 Nov

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] sched 21 Nov → [PDT+]

Comment 12

19 years ago
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

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

Updated

19 years ago
Status: RESOLVED → REOPENED

Comment 14

19 years ago
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...

Updated

19 years ago
Resolution: FIXED → ---

Comment 16

19 years ago
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.

Updated

19 years ago
Assignee: danm → pavlov
Status: REOPENED → NEW

Comment 18

19 years ago
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.
(Assignee)

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+] 12/3/99
(Reporter)

Comment 19

19 years ago
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

19 years ago
*** 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.

Comment 22

19 years ago
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.
(Assignee)

Comment 25

19 years ago
Do you still see this?  I tried it just a minute ago and it looks fine.
(Assignee)

Updated

19 years ago
Whiteboard: [PDT+] 12/3/99 → [PDT+] 12/7/99
And if you do see this, what version of GTK are you using?

Comment 27

19 years ago
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

19 years ago
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

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 30

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

Comment 31

19 years ago
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.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 32

19 years ago
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!

Updated

19 years ago
No longer blocks: 17513

Comment 33

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

Updated

19 years ago
Blocks: 21564

Updated

18 years ago
No longer blocks: 18951

Updated

18 years ago
No longer blocks: 21564
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.