Closed Bug 20230 Opened 26 years ago Closed 26 years ago

[DOGFOOD][PP]IMAP:Regression:Subject,Sender&date columns are messed up

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fenella, Assigned: jefft)

References

Details

(Whiteboard: [PDT+])

Mac (1999-11-29-08 M12) commercial 1. Launch Messenger 2. Select the Inbox folder, click on Inbox Actual result: Two situations: Messages that were sent on 11/21 - 11/24 shows blank in the Sender and Subject column. Date looks OK. Message that were sent on 11/29 shows blank in the Sender and Subject column. In addition, the date column shows dated 12/31/69. (Note: I do not have any mail that are dated between 11/25 to 11/28) Expected result: Sender and Subject and Date columns should display correct information. This occurs on Mac only
Summary: [PP]Regression:Subject, Sender and date column are messed up → [PP]IMAP:Regression:Subject, Sender and date column are messed up
This problem only occurs on IMAP
Summary: [PP]IMAP:Regression:Subject, Sender and date column are messed up → [PP]IMAP:Regression:Subject,Sender&date columns are messed up
Severity: normal → major
Component: Back End → Front End
Hardware: Sun → Macintosh
Summary: [PP]IMAP:Regression:Subject,Sender&date columns are messed up → [DOGFOOD][PP]IMAP:Regression:Subject,Sender&date columns are messed up
I believe that the messages can still be selected and viewed, but the pertinent information in the thread pane is missing.
You are right. Lisa. I forgot to mention that.
Assignee: phil → hyatt
Another tree bug for hyatt. cc'ing alecf, selmer and putterman
Whiteboard: [PDT+]
Putting on PDT+ radar.
Don't see this as being tree-related. More likely trouble with RDF and IMAP. Pushing back to mailnews.
Assignee: hyatt → phil
Assignee: phil → putterman
Scott, can you take a look?
cc'ing bienvenu. I can't check the Mac today. Is this still happening? Is this really only happening on IMAP? Are these messages being sent from 5.0? Is it possible headers aren't being filled in properly when sent? Does correct header info show up in the message pane? Are messages sent before 11/21 showing up correctly? Since this is only happening on the Mac, is it possible that you need to unplug it first (that was a joke, but then again you never know).
QA Contact: lchiang → fenella
fenella - can you check into this?
QA Contact: fenella → lchiang
It's the last day of a month with 30 days, which causes all sorts of problems on the mac. I'm trying it on my Mac with yesterday's build.
actually, any day of the week that ends with the letter "y" causes the mac to fail unpredictably.
david, you can't be serious right?
I can be, but I'm not in this case :-) Seth was serious, however.
*** Bug 20561 has been marked as a duplicate of this bug. ***
adding pink (he was on the other bug)
For me, it starts looking wrong at 11/23 at around 5pm. Everything before that is fine. What's interesting is that I copied a message from imap to pop and the message show up fine in the pop folder. David, is there a difference between how an imap and pop message are stored?
Not really, the messages go through the same parser to populate the database.
Sorry I cannot answer Scott P.'s questions using today's Mac build because I cannot display message in the Message pane (see bug 20649). Will follow up this using tomorrow's build.
the db is returning these values. For example when getting the subject, nsMsgDatabase::RowCellColumnTonsString returns nothing because hdrCell is null. I imagine sender and date are returning similar results.
My guess would be that these values aren't getting set, for some reason.
*** Bug 20658 has been marked as a duplicate of this bug. ***
*** Bug 20658 has been marked as a duplicate of this bug. ***
This is what is happening. When it tries to parse the headers, the headers end in \r\n. It determines where the next header is based on MSG_LINEBREAK which on the mac is \r. When it tries to find the next header, it is left with \nheader. Then it says that if it starts with a \n we must be at the end and no more headers are parsed. The question is, why is this happening all of a sudden? MSG_LINEBREAK and NS_LINEBREAK haven't changed any time recently. Is Imap on the Mac suddenly downloading \r\n when it didn't use to? Why isn't this happening on Linux? Are the \r\n actually downloaded or are we putting this in ourself?
adding simon to the cc list as he's been working with linefeed issues recently.
cc'ing Jeff, who likes to play with line endings. What has changed is the parser, not the imap code, is my guess. I believe it has always given CRLF lines to the parser, on all platforms.
Assignee: putterman → jefft
This could be my bug. Reassign to me. I thinks I know what went wrong.
*** Bug 20696 has been marked as a duplicate of this bug. ***
jefft: note that I checked in a handy class for doing linebreak conversions. It's nsLinebreakConverter.cpp in xpcom/io.
Status: NEW → ASSIGNED
Target Milestone: M12
sfraser, thanks for the information. The problem here is a little bit twisted. I made a mistake on checking whether a message needs to be download with CRLF line ending. That is needed for messages appending up to the imap server. It needs to be in canonical format.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
This should be fixed by now. Please remove the old .msf file and retest.
QA Contact: lchiang → pmock
Peter, can you handle this one on verification? Thanks.
Sure. I will be looking at this bug shortly. :)
Status: RESOLVED → VERIFIED
Verified as fixed on MacOS commercial seamonkey build using today build. ftp://sweetlou/products/client/seamonkey/macos/8.x/ppc/1999-12-06-08-M12/netscap e5-mac-M12.sea.bin The column information is present and back to normal. I checked the columns under IMAP and POP (just to be sure). :-)
Blocks: 21564
No longer blocks: 21564
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.