[PP] [blocker] can't view more than one message under POP



20 years ago
2 years ago


(Reporter: jay, Assigned: rods)


Mac System 8.5

Firefox Tracking Flags

(Not tracked)




20 years ago
if you open up messenger and try to view you mail, you can view the first
message selected in the two frames below the list of email (the header and
body)...but if you try to select another email to view, nothing happens.

1. Launch messenger
2. Open an account folder in the sidebar, goto Inbox
3. Click on a message in the top right frame...see it in the two frames below.
4. Try to click on another message...nothing changes in the header and body
frames (the old message is still displayed).

Machine and Build:
Mac 8.5.1 build 1999071911


20 years ago
Assignee: phil → bienvenu

Comment 1

20 years ago
Local mail or IMAP? This was working for me with imap in today's build. Lisa, do
you see this problem?


20 years ago
Summary: can't view more than one message → [PP] can't view more than one message

Comment 2

20 years ago
The platform on this is on the Mac.  I'll ask Peter to confirm.  (Peter, is this
occurring for you?)

I know today's Win32 builds are fine.

Comment 3

20 years ago
This is only a problem with Mac build 1999071911...and i am using a POP3


20 years ago
Summary: [PP] can't view more than one message → [PP] can't view more than one message under POP

Comment 4

20 years ago
Yes, this problem is occuring on today PPC Commercial seamonkdy build 1999-07-19-
11-m9.  The problem occurs only under POP.  Under IMAP, I can view multiple mail
messages ok.


20 years ago
Summary: [PP] can't view more than one message under POP → [PP] [blocker] can't view more than one message under POP

Comment 5

20 years ago
Pls fix this for tomorrow's release build.  Very hard to test under this
circumstance.  Thanks.

Comment 6

20 years ago
Can anyone with a mac help me out here? With Paul's help, I was able to
determine that we're not spooling the second message out the tempMessage.emf
file, but I don't know where it's failing. Without a mac, I won't be able to fix
this, obviously.

Comment 7

20 years ago
Adding hangas to the cc list as well to bring in all of our mac gurus.

Comment 8

20 years ago
Sorry, I thought I had added Paul...
Ok, I will take a look at it..
result of my first investigation:

The first message you have selected is reloaded every time to try to display
another message. You can fix manually the problem by deleting the temporary file
tempMessage.eml (at the same level that apprunner). Something goes wrong with
this temp file, it seems to stay open even after the message is displayed, thing
that may explains why it will failed next time we try to open it! I am still

Comment 11

20 years ago
JFD or bienvenu, you might want to start by tracing through the the build log to
see what got checked into local during the past week. Maybe there is a
corelation there.

Comment 12

20 years ago
closing the steam does not seem to release/close the file anymore. I suspect
looking at changes in the steam code would be more productive.
Yes, closestream doesn't seems to close the file anymore!
I have a fix for it. As nsFileSpecImpl::closeStream just release the io stream, thing that never close the file!, we

need to do it manually.

Index: nsMailboxProtocol.cpp


RCS file: /cvsroot/mozilla/mailnews/local/src/nsMailboxProtocol.cpp,v

retrieving revision 1.51

diff -r1.51 nsMailboxProtocol.cpp


> 	{

> 		nsCOMPtr<nsIOutputStream> outputStream;

> 		m_tempMessageFile->GetOutputStream(getter_AddRefs(outputStream));

> 		if (outputStream)

> 			outputStream->Close();


> 	}

David, let me know if you want me to check in the fix?

Comment 15

20 years ago
I think there's something more going on here....release shouldn't close the
stream. Only when the ref count goes to zero should it be released.
Not having looked at this at all, my theory would be that last week someone made
a change to local which introduced a memory leak of the mailbox protocol

by leaking the protocol instance we would be leaking the file stream which would
prevent it from getting closed.

I don't disagree with your fix it seems good to add it. But if someone
introduced a leak we should figure out where....
Scott, you are right. My fix is temporary...

Comment 17

20 years ago
Jeff, did you add a flush to nsMailboxProtocol.cpp? I think that could be
causing our problem.


20 years ago
Assignee: bienvenu → rods

Comment 18

20 years ago
sorry, Jeff, not you at all. It was a change to nsIFileStream.cpp made Friday
that introduced a ref-counting bug. Rod, your change to get an nsISupports adds
an extra reference to the file stream object, so it never gets released, and the
file never gets closed, which means no one else can use the file. If you have
any questions, or disagree, please let me know! I'm going to try to find a fix,
but I don't want to break this code, so I'm reassigning to you.

Comment 19

20 years ago
OK, adding NS_RELEASE as follows in nsIFileStream -

    if (NS_OK == rv &&
        NS_OK ==
                                          (void**)&outStr)) {
      *aResult = outStr;

seems to fix the problem. JF, could you try this?

Comment 20

20 years ago
Ahh excellent catch david B. If you check in that change can you change the
NS_OK == stuff to use the NS_SUCCEEDED macro?

rod, you may want to look at using nsCOMPtr for the supports variable if
you end up revisiting that code...that would have prevented this leak I think...

Comment 21

20 years ago
Not only NS_NewTypicalOutputFileStream() requires to call NS_RELEASE(supports)
but also NS_NewTypicalInputFileStream() requires to call NS_RELEASE(supports).
Both routines call NS_NewIOFileStream() which adds a ref count to the supports.
A second QueryInterface() for inStr/OutStr adds another ref count. A
NS_RELEASE(supports) sounds like a must in these two routines.

Comment 22

20 years ago
Too much nsCOMPtr... Sorry, for all of you wasting time on my check in

Here's what I will check in when the tree goes green:
    *aResult = nsnull;
    if (NS_SUCCEEDED(rv)) {
(void**)&outStr))) {
        *aResult = outStr;
    return rv;


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

Comment 23

20 years ago
Checked in the fix.


20 years ago

Comment 24

20 years ago
Verified in the Mac Seamonkey Commercial build 1999072208-m9 build.  I can view

more than one message under POP.  I also tried it under IMAP and I can view more

than one message.

Verified as fixed.

Comment 25

17 years ago
*** Bug 95469 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.