Seamonkey 1999040717 win32 & 99040809 on linux Hardware: compaq 133 System OS: win95, linux 1. Launch apprunner 2. Open Messenger via Task menu 3. Click on a message to display in message pane. Note the Header area displays "XML Parsin Error: not well-formed Line Number1, Column 127:"

Reassigning to rhp.

Alec was seeing this on Linux today too. Adding him to the cc list. Just before M4, they switched the XML parser to be EXPAT. Nisheeth took all of our xul files and ran them through expat and fixed any syntax errors we were having. However, the xml stuff Rich loads when displaying a message is in memory so Nisheeth wouldn't have been able to test it. Rich, you might want to send him the xml your submitting for the message header to see if he sees anything wrong with it..... Or, try loading the XML file yourself using the current apprunner tip which uses EXPAT.

I will update my tree and see what is going on. - rhp

Do you think this is an M4 stopper since this is a regression from M3 builds? Regardless, please assign an appropriate target milestone. Thanks.

Yes, this is a problem we need to fix. I am working on a fix right now and I will update the bug when I have a solution. - rhp

I have a fix. It was the failure to escape the value of the message ID that failed. I have a function that is doing the escaping, but I need to change this to the new world equivalent function that does this. Here is a diff that I could use verified on Linux: Index: nsMimeEmitter.cpp =================================================================== RCS file: /cvsroot/mozilla/mailnews/mime/emitters/xml/nsMimeEmitter.cpp,v retrieving revision 1.4 diff -c -r1.4 nsMimeEmitter.cpp *** nsMimeEmitter.cpp 1999/04/06 22:21:44 1.4 --- nsMimeEmitter.cpp 1999/04/08 23:18:53 *************** *** 167,172 **** --- 167,179 ---- nsresult nsMimeEmitter::WriteXMLHeader(const char *msgID) { + if ( (!msgID) || (!*msgID) ) + return NS_ERROR_FAILURE; + + char *newValue = nsEscapeHTML(msgID); + if (!newValue) + return NS_ERROR_OUT_OF_MEMORY; + UtilityWrite("<?xml version=\"1.0\"?>"); if (mHeaderDisplayType == MicroHeaders) *************** *** 177,183 **** UtilityWrite("<?xml-stylesheet href=\"resource:/res/mailnews/messenger/mailheader-all.css\" type=\"text/css\"?>"); UtilityWrite("<message id=\""); ! UtilityWrite(msgID); UtilityWrite("\">"); mXMLHeaderStarted = PR_TRUE; --- 184,190 ---- UtilityWrite("<?xml-stylesheet href=\"resource:/res/mailnews/messenger/mailheader-all.css\" type=\"text/css\"?>"); UtilityWrite("<message id=\""); ! UtilityWrite(newValue); UtilityWrite("\">"); mXMLHeaderStarted = PR_TRUE;

This has been fixed and checked in. - rhp

Peter - pls help to verify this on Friday. Thanks.

RE: April 9 (1999-04-09-08) on Linux 2.0 The Get Passing error goes away only when I display a plain text message. However, if the message contains a gif attachment, or web page attachment or vcard, the XML Parsing Error still exists.

Can you send me a message that you are seeing this with. I've tested with files attached and it seemed to work fine. - rhp

fenella, can you first go into the directory pointed to by your root mail folder pref and delete all the .msf files there for linux? I think something may have gotten corrupted. I had the same problem you were seeing on linux just now as I was helping Rich debug this. I deleted my summary files and restarted. I was then able to display all my messages okay.

Following Rich and Seth's instruction, I remove the *.msf files in the mail profile directory and rmove the qatest04.msf (my test account is qatest04) in the home directory. The parsor problem goes away. Seth said I can verify this bug as fixed. Since this had to do with corrupted summary file, should we need release note for this problem?

fyi This does not appear to occur under Win98. Sorry it took so long to test, I forgot I had to delete my mozreg.dat file from the windows directory again.

I'm still seeing this with the 1999_04_09_08 linux build in one case: Every time I send a message using seamonkey, I'm getting a return receipt. If I select the return receipt right after getting new messages, I'll see the parsing error. If I exit and return to that same return receipt, the error no longer displays.

This bug is still around. Using the 10th's build on NT 4.0, I can avoid seeing parsing errors if I clean up the msf files, but that only holds for the old messages. If I send a new message and retrieve it (text only, just a word or two in message, no funny stuff), displaying the message will get an xml parsing error. This is not usable. I'm reopening the bug.

Regarding my last comment -- after seeing the xml parsing error on displaying a new message, exit and return still shows that error unless you do the msf file cleanup. So, basically you have to clear out your msf files on each launch.

Talked to rhp and he believes the xml parsing errors we're seeing are due to Get New Messages getting all the old ones, too -- See bug #4886. He believes the original condition for which this bug was written is fixed. So, I'm waiting for him to provide his development insight in comments here before closing this bug.

Yes, this issue turns out to be a problem when new messages are being retrieved. The headers are handled correctly, but the message bodies are being corrupted. When you try to display this corrupted body, you get parts of a couple of messages and this used to display as just some text in the display window, but now with the XML output, you get a big yellow error which is what is being seen here. - rhp

OK, am closing this bug . Will track this symptom under #4886 (Get new messages gets all messages in inbox, duplicating every message and apparently causing corruption).