23755 - Status says new headers received but don't display.

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[laurel]

Using jan12 commercial builds on mac OS 8.5.1 and NT 4.0.
Can't yet launch mail on today's linux build

When getting new messages in POP account I'm seeing status bar text indicate
headers are received, but I can't always see the header or sometimes if I see
the header I can't get a display of contents until I exit and return.

1.  New profile: set up POP account.
2.  Go to mail, select Inbox.
3.  Do a Get Msg where you know you have new messages to Get.
    Result:  status bar indicates headers are downloaded, but nothing appears in
the thread pane.
4.  Exit and return.
    Result:  previously downloaded messages are in inbox and selectable,
contents display.
5.  Send yourself some new messages (I did this from another machine). Get the
new messages.
    Result:  headers are indicated as being downloaded but often will not
display.  If they do, the message contents will not display in most cases.

Note:  Saw this for both new and migrated profiles. Migrated profiles could see
and display the contents for messages previously downloaded/in local files, but
could not see contents for newly downloaded headers.

Note:  Haven't tried yet on existing profile(s) from past builds.

Comment 1

[Phil Peterson]

Reassign to putterman for M13

Comment 2

[laurel]

This is also happening for new IMAP profiles.  Not seeing any obvious weirdness
in IMAP after first session, though, as with POP.

Changed summary.

Comment 3

[Colin Blake]

Adding myself to cc list since I'm seeing this on OpenVMS too.

Comment 4

[scottputterman]

I haven't been able to reproduce this yet.

Comment 5

[laurel]

Trying to reproduce in current builds.
New profile is broken in jan18-11 m13 commercial builds on linux and nt (and I
would assume mac, too).
Will work backward to last usable build.

Comment 6

[laurel]

Happens in 2000-01-14-16 commercial on linux (tried using new profile, as in
steps listed with original description)
Happens in 2000-01-17-08 commercial on linux (tried using new profile, as in
steps listed with original description)

Comment 7

[laurel]

OK, since we can't use new profiles in today's (jan18) builds and using
migration on today's builds doesn't always yield the problem and for other
instability reasons, Scott P. and I have decided we're going to wait for the
next build with fix for bug #24254 to further assess the reproducibility of this
bug.  Since it was most evident in the past using new profiles, we'll wait until
we can do new profiles again before commenting further.

Comment 8

[scottputterman]

moving to M14.

Comment 9

[laurel]

Scott, FYI -- using jan19-08 commercial build on linux with new profiles this
still happens. Had some trouble using NT with new profiles, so will have to
investigate after our m13 basic functional test...

Comment 10

[laurel]

This is also happening for me using new profiles on NT 4.0 with 2000-01-19-13
m13 commercial build.

Comment 11

[scottputterman]

I think I'm really close to figuring this out.

It looks like on a 0 byte file, ParseFolder is not calling NotifyFolderLoaded.
This causes me not to add the folder as a listener on the db, which means that
when we get new messages, I do not get notified.  I don't actually know that
ParseFolder isn't calling NotifyFolderLoaded in this case. I have to look into
it.

BTW, I can't reproduce this on my debug build but it happens every time in my
release build.

Comment 12

[scottputterman]

I have a fix.  I caused this last week when I checked in code to automatically
load the Inbox.  I'm not sure why it's not happening in the common case or in my
debug build.  I'd have expected more people to be affected by this. Perhaps it
was just luck.  Anyway, with this fix I was able to get my mail from a new
profile on my NT release build, which I wasn't able to do before the fix.

Comment 13

[scottputterman]

Actually, this is just a js change.  We could actually verify it before I check
it in to make sure I'm on the right track by changing the js on Laurel's build.
It was just flipping two lines.  I'll talk to Laurel about this tomorrow.

Comment 14

[laurel]

Tried the new .js file with this morning's linux and win32 commercial builds --
takes care of the problem, at least as far as new profiles.  Not certain at this
point whether the other instances of not getting new headers to display in
existing profiles is the same thing.  Will watch for that problem separately.

Comment 15

[laurel]

The problem is also seen with newsgroups in new profiles and it's been reported
that the side issue similar to pop is seen for newsgroups -- where even in an
existing profile, you often get status indicating headers were downloaded but
they're not displayed.  Will check the news instance when verifying.

Comment 16

[scottputterman]

I checked in the fix. Changing to M13.

Comment 17

[laurel]

Can't verify with jan21 morning builds because account setup wizard is crashing
-- see bug #24668.  Will try  again in next builds.

Comment 18

[laurel]

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

Comment 19

[laurel]

OK using 2000-01-25-15m13 commercial build on linux 6.0

Comment 20

[Colin Blake]

Just FYI for anyone else reading this, the OpenVMS problem was caused by 
nsFileSpec doing a case-sensitive compare of file names. Files names are
case blind on OpenVMS, and a comparison of "Inbox" with "inbox" was returning
false and causing the new mail not to show up.  I need to get a patch to
xpcom/io/nsFileSpec.cpp checked in (the fix is in the operator == function).

Comment 21

[laurel]

OK using 2000-01-25-14m13 commercial build on NT 4.0

Comment 22

[laurel]

OK using 2000-01-26-01m13 commercial build on mac OS 8.5.1