Get into a state where contents won't display in message pane I still need to track down the exact steps, but I'm seeing this consistently on Win32 so far. Symptom: Select Inbox (IMAP or POP); message headers show up in the thread pane, but selecting a message won't update the message pane. Here are some things that I'm doing prior to seeing the problem: 1) Read mail (IMAP) 2) Go to news (netscape.test). Post several messages and read them. 3) Go back to mail - Inbox selected 4) Get messages. See new mail. 5) Select a message. Message is selected, but the message pane still shows the content of the news message (step 2). Another symptom is that when I do a new message now, the compose window never redraws - it shows the contents of window below it. No hang or crash though. I'll try to narrow a bit more - perhaps see a better pattern after more usage. Wanted to log the bug in case anyone has any ideas.

Still investigating the steps....

Scott Putterman and Jefft are looking at this. Reproduced on Jeff's system. Still need to get exact steps down.

Thanks to Scott and Jeff's help, have the reproducible steps: 1) Start Messenger 2) Don't expand or select any folders/servers 3) Click New Msg toolbar button 4) Enter netscape.test in the newsgroups: addressing field 5) Click Send 6) Repeat steps 3-5 about 15/16 times. 7) You'll notice that it gets slower each time to bring up the compose window. On the 15/16th time, you'll see the compose window come up, but the contents of the window don't draw. We tried these same steps for SMTP and don't have a problem. Jeff and Scott suggested assiging to Seth for now. When this problem occurs, you can't run any URL (ie. display a message, open another Navigator window).

I need to try this on Linux and Mac on Monday. More results to come.

I forgot to mention that this was on build 1999061808. I also tried the Linux and Mac builds for those dates: Linux: Apprunner /compose window hangs around the 10/11th compose window coming up. No trace available on Linux. Mac: Apprunner crashes on the 9/10th compose window coming up.

Seth, I have a theory about this bug. We are leaving open the nntp connections because of the nntp protocol leak. Each time you send a news post we create a new connection and leave it open. Do this 15 or 16 times and things will get sluggish as we'll have 15 or 16 open connections on the same server. Maybe the server fights back to the # of connections we are trying to open on it... in other words...I wonder if we track down what's keeping the connection from getting closed at the end of a request, would we fix this bug to? Possibly...

I'm in the middle of a big nntp back end clean up. I'll tackle this afterwards. mscott's theory makes sense.

accepting bug.

Isn't nntp connection a cached connection? If not, we need to be. The connection model needs to be different than smtp and pop3.

we don't have a nntp connection cache yet....something to add to the list.

marking m8. accepting

not a regression, moving to m9. Not sure how necko landing will affect this, if at all.

I think we can move this to M10.

I'll see if this exists still. If so, this is a contender for a "dogfood" bug, I think.

yes, I agree, this is a [DOGFOOD] level problem. marking it as such.

If this needs to be fixed for dogfood, it follows that it needs to be fixed for PR1, do I added a note in the Status Whiteboard

fixed. on linux, there is a way to see how many open nntp connections you have. from the command line, do this: netstat |& grep -i nntp you will see something like this, for each nntp connection: tcp 0 0 sspitzer.mcom.com:2730 secnews1:nntp ESTABLISHED with 5.0 before this fix, you would see a new connection for each news operation! now, you should at most 1.

comments from esther: I worked on this with Seth yesterday and here are the steps to show the problem and to reproduce this bug: 1. Launch Messenger 2. Open a newsgroup 3. Select messages to view going down the list and clicking with pauses of about 2 seconds or less in between clicks. 4. After about 6 messages the newly clicked messages don't display. Message view is displaying one of the previously selected messages and it doesn't chang. When fixed, message view shouldn't get stuck on one message.

Using 1999100617M10 commercial build on win98 and 1999100615M10 commercial build on mac this is fixed. Waiting for linux to verify for that platform.

OK works with 1999100118m10 commercial build on linux. Verified