Closed Bug 23755 Opened 25 years ago Closed 25 years ago

Status says new headers received but don't display.

Categories

(MailNews Core :: Backend, defect, P3)

Product:
MailNews Core
Component:
Backend
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: laurel, Assigned: scottputterman)

References

Details

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.
QA Contact: lchiang → laurel
Assignee: phil → putterman
Target Milestone: M13
Reassign to putterman for M13
Summary: POP: Status says new headers received, but not always appearing → Status says new headers received but don't display.
This is also happening for new IMAP profiles.  Not seeing any obvious weirdness
in IMAP after first session, though, as with POP.

Changed summary.
Adding myself to cc list since I'm seeing this on OpenVMS too.
I haven't been able to reproduce this yet.
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.
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)
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.
Target Milestone: M13 → M14
moving to M14.
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...
This is also happening for me using new profiles on NT 4.0 with 2000-01-19-13
m13 commercial build.
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.
Status: NEW → ASSIGNED
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.
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.
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.
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.
I checked in the fix. Changing to M13.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Target Milestone: M14 → M13
Can't verify with jan21 morning builds because account setup wizard is crashing
-- see bug #24668.  Will try  again in next builds.
*** Bug 21732 has been marked as a duplicate of this bug. ***
OK using 2000-01-25-15m13 commercial build on linux 6.0
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).
OK using 2000-01-25-14m13 commercial build on NT 4.0
OK using 2000-01-26-01m13 commercial build on mac OS 8.5.1
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.