can't close windows if 8 bit color depth and ftp or imap threads running.



20 years ago
11 years ago


(Reporter: skasinathan, Assigned: dcone)


Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PR1] This no longer crashes)



20 years ago
Couldn't able to close Messenger after reading an imap folder. This is on 6/1/99
debug build. The Steps I did are

1. Start apprunner.
2. Start messenger using Task, Messenger.
3. Clicked on the imap Inbox folder.
4. Read a message.
5. Close Messenger. It does not respond.


20 years ago
Severity: normal → critical

Comment 1

20 years ago
Windows debug build.


20 years ago
QA Contact: lchiang → suresh


20 years ago
Target Milestone: M7

Comment 2

20 years ago
Setting to M7. I haven't been able to reproduce this yet on my debug build but I
did see it on Suresh's machine. Adding jefft to cc list.

Comment 3

20 years ago
I'm still having trouble getting this to happen on my debug build. Suresh, can
you try it out again for us the next time you pull the tree? Maybe it decided to
go away....

Comment 4

20 years ago
Scott, I still see the same problem in Today's (6/4/99) windows debug build.

Comment 5

20 years ago
I used to have this problem on my home machine but not on my work machine with
the same bits. It went away at some point when I applied various NT service
packs and VC++ service packs on my home machine. I strongly suspect that this is
os and vc++ sepcific related problem. Suresh, can you try to update your system
with latest NT & VC++ service packs. You can download them from the microsoft

Comment 6

20 years ago
I downloaded latest version of Windows NT ServicePack 5 and VC++6.0 ServicePack
3. I still see the problem on 6/4/99 Windows debug build and 6/7/99 Windows
debug build. Any other solution to this problem??

Comment 7

20 years ago
Beats me. It happened on me on my home machine. I don't have the problem any
more. Try to delete your mozregistry.dat from your NT directory and see if that

Comment 8

20 years ago
I asked Suresh to try the release build to see if it's a debug build thing or if
it's something with his IMAP folders/environment/account.

Comment 9

20 years ago
I see the same problem in windows release build, as Lisa suggested.
jefft, deleting mozregistry didn't help me.

I think the problem may be in my pref file or some other files may have been

Comment 10

20 years ago
Yes, removing pref file may help too.

Comment 11

20 years ago
I did more testing on this bug. But none of them doesn't help.
1. File | exit option works, but File | Close or clicking on the little X button
to close messenger doesn't work.
2. Deleted mozregistry, msf files - doesn't work.
3. Changed my pref file to use a different mail server - doesn't work.
4. Tried a different pref file with just one imap, pop and news - doesn't work.
5. After I read a imap message I am able to send/get message in pop/news
folders. But when I try to close messenger it 'freezes';
6. Did a IMAP Logging to capture the stream. Here is the log.

174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: * OK IMAP4
service (Netscape Messaging Server 4.1 (built Jun  2 1999))
174[872f820]: nsmail-5:NA:SendData: 1 capability
174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: * CAPABILITY IMAP4 IMAP4rev1
174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: 1 OK Completed
174[872f820]: nsmail-5:NA:SendData: 2 authenticate plain
174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: +
174[872f820]: nsmail-5:NA:SendData: AHFhdGVzdDM3AE5lIXNjLXBl
174[872f820]: nsmail-5:NA:CreateNewLineFromSocket: 2 OK User logged in (no
174[872f820]: nsmail-5:A:SendData: 3 namespace
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * NAMESPACE (("" "/"))
(("Shared Folders/User/" "/")) NIL
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 3 OK Completed
174[872f820]: nsmail-5:A:SendData: 4 lsub "" "*"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\NoInferiors) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/"
"My folder"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasChildren) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasChildren) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/"
"Trash/Shared Folders/Goofy one"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasChildren) "/"
"Trash/Shared Folders/User/qatest38/bob"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LSUB (\HasNoChildren) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 4 OK Completed
174[872f820]: nsmail-5:A:SendData: 5 lsub "" "Shared Folders/User/*"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 5 OK Completed
174[872f820]: nsmail-5:A:SendData: 6 list "" "INBOX"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * LIST (\NoInferiors) "/"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 6 OK Completed
174[872f820]: nsmail-5:A:SendData: 7 select "Inbox"
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * FLAGS (\Answered \Flagged
\Draft \Deleted \Seen)
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * OK [PERMANENTFLAGS
(\Answered \Flagged \Draft \Deleted \Seen \*)]
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * 24 EXISTS
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * 0 RECENT
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: * OK [UIDVALIDITY 899281869]
174[872f820]: nsmail-5:A:CreateNewLineFromSocket: 7 OK [READ-WRITE] Completed
174[872f820]: nsmail-5:S-Inbox:SendData: 8 UID fetch 1:* (FLAGS)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 1 FETCH (FLAGS
(\Deleted \Seen) UID 73)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 2 FETCH (FLAGS
(\Deleted \Seen) UID 74)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 3 FETCH (FLAGS (\Seen)
UID 75)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 4 FETCH (FLAGS
(\Deleted \Seen) UID 76)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 5 FETCH (FLAGS (\Seen)
UID 77)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 6 FETCH (FLAGS (\Seen)
UID 79)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 7 FETCH (FLAGS (\Seen)
UID 80)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 8 FETCH (FLAGS
(\Deleted \Seen) UID 83)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 9 FETCH (FLAGS (\Seen)
UID 84)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 10 FETCH (FLAGS
(\Seen) UID 86)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 11 FETCH (FLAGS
(\Seen) UID 88)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 12 FETCH (FLAGS
(\Seen) UID 89)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 13 FETCH (FLAGS
(\Seen) UID 90)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 14 FETCH (FLAGS
(\Deleted \Seen) UID 91)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 15 FETCH (FLAGS
(\Deleted \Seen) UID 92)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 16 FETCH (FLAGS
(\Seen) UID 93)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 17 FETCH (FLAGS
(\Seen) UID 94)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 18 FETCH (FLAGS
(\Seen) UID 95)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 19 FETCH (FLAGS
(\Seen) UID 96)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 20 FETCH (FLAGS
(\Seen) UID 97)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 21 FETCH (FLAGS
(\Seen) UID 98)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 22 FETCH (FLAGS
(\Seen) UID 99)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 23 FETCH (FLAGS
(\Seen) UID 100)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 24 FETCH (FLAGS
(\Seen) UID 101)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 8 OK Completed
174[872f820]: nsmail-5:S-Inbox:SendData: 9 UID fetch 90 (XSENDER UID RFC822.SIZE
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: * 13 FETCH (UID 90
RFC822.SIZE 1073 XSENDER {0}
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket:  BODY[] {1073}
174[872f820]: nsmail-5:S-Inbox:STREAM:OPEN Size: 1073: Begin Message Download
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Return-Path:
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Received: from ([]) by
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket:           (Netscape
Messaging Server  4.0b2 )  with ESMTP id 0EZ1IOD0.008
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket:           for
<>; Wed, 9 Sep 1998 16:31:25 -0700
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Received: from ( [])
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 	by
(8.8.5/8.8.5) with ESMTP id QAA04593
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 	for
<>; Wed, 9 Sep 1998 16:31:24 -0700 (PDT)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Received: from (localhost []) by (8.7.3/8.7.3) with
ESMTP id QAA13841 for <>; We
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Sender:
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Message-ID:
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Date: Wed, 09 Sep 1998
16:32:11 -0700
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: From: Test37
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: X-Mailer: Mozilla 4.5b2
[en] (X11; U; IRIX 6.3 IP32)
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: X-Accept-Language: en
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: MIME-Version: 1.0
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: To:
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Subject: 4:31
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: Content-Type: text/html;
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket:
Content-Transfer-Encoding: 7bit
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket:
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: <!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.0 Transitional//EN">
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: <HTML>
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 4:31</HTML>
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket:
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: )
174[872f820]: nsmail-5:S-Inbox:STREAM:CLOSE: Normal Message End Download Stream
174[872f820]: nsmail-5:S-Inbox:CreateNewLineFromSocket: 9 OK Completed

Comment 12

20 years ago
Interesting.  A bug report came from the outside with this similar problem.  I
can reproduce the hang as well on my system.

Comment 13

20 years ago
*** Bug 7945 has been marked as a duplicate of this bug. ***


20 years ago
Target Milestone: M7 → M8

Comment 14

20 years ago
I talked to Phil about this and we don't think we're going to hold M7 trying to
figure this one out. I thought it was only 2 people that it happened for but now
I see it happens on Lisa's machine too.

Lisa, anything special you're doing to reliably trigger it?

Moving to M8.

Comment 15

20 years ago
Nothing special at all.  Let me see if anyone else in my group who is running NT
has this problem.

Comment 16

20 years ago
This happens to me when I click the close corner, but not when I do a File |
Exit. It only happens with Imap, not with Pop.

Comment 17

20 years ago
Yippee.  Someone else besides Suresh and I have this problem.  And yes, as we
reported, File | Exit works fine and this is only on IMAP.


20 years ago
Last Resolved: 20 years ago
Resolution: --- → FIXED

Comment 18

20 years ago
this works for me now. Can you try it again?

Comment 19

20 years ago
Can someone else try it? I don't have a tree with the running tip, I'm on a
necko landing branch...thanks...


20 years ago
Target Milestone: M8 → M9

Comment 20

20 years ago
I'm sorry, this still happens to me at work, but not at home. Moving to m9,
though, since there's an easy work-around.


20 years ago
Resolution: FIXED → ---

Comment 21

20 years ago
clearing resolution.
*** Bug 9364 has been marked as a duplicate of this bug. ***

Comment 23

20 years ago
Moving all Mail/News Networking bugs to Mail/News Networking-Mail

This may re-open previously Verified bugs due to a Bugzilla bug...if so, I will
fix those bugs.


20 years ago
Target Milestone: M9 → M10

Comment 24

20 years ago
Bienvenu has made some progress on this bug but we still aren't there yet. I'm
going to be gone until Monday which will be after M9 has passed (hopefully) so
I'm triaging this to M10.

Comment 25

20 years ago
*** Bug 11757 has been marked as a duplicate of this bug. ***


20 years ago
Whiteboard: [PR1]

Comment 26

20 years ago
Sounds like this needs to be fixed by PR1, so I added a note to the Status
Whiteboard field


20 years ago
Assignee: mscott → bienvenu

Comment 27

20 years ago
I've spent a lot of time on this. It definitely has to do with our imap threads
- if they are convinced to finish with debugger trickery, the window will close.
It does not seem to have to do with having an open connection to a socket - if I
leave the connection open but get the thread to finish, the window stil closes.
After a suggestion from Rick Potts, I tried pumping pending events when the idle
thread wakes up, but that did not help. Rick said there can be problems if a
thread other than the ui thread creates windows, but I don't think that's


20 years ago
Target Milestone: M10 → M11

Comment 28

20 years ago
moving to m11 - still a mystery. I'm going to try playing with thread priority
to see if that has any effect.

Comment 29

20 years ago
More info - changing thread priorities did not have an effect. I switched
to nsIThreads - no difference (except that the default JOINABLE threads
causes the hang to persist after the imap part of the thread has finished,
because nsIThread keeps threads running in a pool, which seems to be
sufficient to cause this problem - this means that the imap code is very
unlikely to be the issue because we've cleaned up completely by the point the
thread returns to the pool). After debugging some more, I believe that we get
in a state that closing the window causes us to start processing windows
messages in such a way that processing the messages causes more messages to get
put on the windows event queue than we can deal with. I noticed
WM_PALETTEISCHANGING messages getting passed faster than we can handle them.

Comment 30

20 years ago
thanks to a helpful suggestion from Phil, I believe I've isolated this to a
problem with WM_PALETTE messages. If I change my color depth to 8 bits == 256
colors, I can reproduce this problem at home. Before I did this, when I close a
window, I get the following messages:
after close got msg 10
after close got msg 46
after close got msg 47
after close got msg 2

If I change to 256 colors, I get the following wm messages:

after close got msg 10
after close got msg 311
after close got msg 310
after close got msg 310

I'm cc'ing you, Rod, because Peter Trudelle said you would be a good person to
contact about windows-specific xpfe problems, and I think this is an xpfe
problem...which is exposed by having multiple threads running.

Comment 31

20 years ago
Great work, phil & david. It puzzles me for such a long time why I can reproduce
at the early stage but not recently. All because of the color depth change.

Comment 32

20 years ago
OK, I verified that this problem happens if you get an ftp thread spinning, so
it has nothing to do with IMAP. So, I'd like to reassign this to Rod. Rod,
please let me know if there's someone else I should assign it to, or if this
doesn't make any sense.


20 years ago
Assignee: bienvenu → rods
Summary: Messenger 'freezes' on imap close → can't close windows if 8 bit color depth and ftp or imap threads running.

Comment 33

20 years ago
If I change the code in nsWindow.cpp to ignore the WM_QUERYNEWPALETTE and
WM_PALETTECHANGED messages, this problem goes away. Obviously, that's not the
right fix (and I don't know what the fix should be)...

Comment 34

20 years ago
I'll take a look because it has to do with nsWindow.cpp but I am not sure I am
the right guy. I'll see what I can find out.


20 years ago
Severity: critical → blocker

Comment 35

20 years ago
Upgrading severity to blocker for mail/news dogfood.

Comment 36

20 years ago
Well, I am at a complete loss here. Are there any super Windows gurus around?
Here is a summary:
Basically, viewer hangs when using 256 colors and an additional thread has been
started (like ftp) and you try to quit or close. If I comment out
the WM_QUERYPALETTE code in nsWindow it closes/quits. If I change the last
parameter in the SelectPalette from FALSE to TRUE, it
closes/quits. If I don't start the additional thread it close/quits.

As a stop gap I will be changing the SelectPalette call so the last param is
TRUE which may not provide the best viewing experience, but the hanging of the
app will go away until we can figure this out.

Help! Please someone!

Comment 37

20 years ago
More info:
The viewer is running i have 3 threads (in the thread window), then I click on
an FTP link, now I have 6 threads. The viewer window is still active (because I
don't get WM_ACTIVATE when I click on the ftp link or when I go to close the
window), when I press on the close button (the X in the uper right), the last
message to come through is WM_CLOSE and then it hangs. When I stop the debugger
it is spinning in the ftp thread. I check the other threads and the nsWindow has
stopped at the bottom of the processing method at the line:

::CallWindowProc((WNDPROC)someWindow->GetPrevWindowProc(), hWnd,
                            msg, wParam, lParam);

Now, what role the palettes play in this whole threading situation I have no

I check the threads, I


20 years ago
Whiteboard: [PR1] → [PR1] This no longer crashes


20 years ago
Assignee: rods → troy


20 years ago
Assignee: troy → rods

Comment 38

20 years ago
I have no idea why this is assigned to me...


20 years ago
Assignee: rods → troy

Comment 39

20 years ago
Please read the mail I sent to you, before I reassigned the bug. Summary: Rick
suggested I reassign this to you because I am buried with my bugs and helping
Tom P. out.

It appears it has as much to do with threading as it does the palette, Rick
thought maybe rpotts could help you solve it.


20 years ago
Blocks: 11091

Comment 40

20 years ago
(sorry for the extra bug notification - this affects mailnews and target
milestone is M11 or M12 so I'm just adding to mail beta tracking bug)


20 years ago
Blocks: 14742


20 years ago
Severity: blocker → normal
Target Milestone: M11 → M14


20 years ago

Comment 41

20 years ago
Because there's a workaround checked in to the widget code, I assume this is no
longer a blocker...

Comment 42

20 years ago
mscott or jefft, please verify the workaround

Comment 43

20 years ago
Using 256 colors and running my debug build, the problem indeed went away. I can
close the messenger window without a problem.


20 years ago
No longer blocks: 14742


20 years ago
Assignee: troy → rods

Comment 44

20 years ago
Assigning bug back to you, because with the workaround in place we do shut down
(therefore it's not an urgent bug), and it's not a layout issue

Comment 45

19 years ago
moving to M15

Comment 46

19 years ago
reassign to don
Assignee: rods → dcone

Comment 47

19 years ago
Last Resolved: 20 years ago19 years ago
Resolution: --- → FIXED

Comment 48

19 years ago
I'm able to close messenger now. Marking this as verified.

Comment 49

19 years ago
I'm seeing this again: filed bug 33928.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.