Closed Bug 107436 Opened 23 years ago Closed 23 years ago

File Send Page and Mail Composition with inline images results in unreadable mail

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Windows 2000
defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: thomas.swan, Assigned: sspitzer)

References

Details

(Keywords: smoketest)

Attachments

(2 files)

Using IMAP/SSL

After composing a message in Mozilla with 4 inline images I cannot open it in
Sent or in my Inbox (sent to myself)  I wind up with an Alert pop up with ]? in
it.  That's all that appears in the alert.   Otherwise the message is not opened
or even marked as read...
Additional notes:

The email composed was valid and can be opened up by other clients and builds of
Mozilla, but not by win32 nightly 2001102811.

The message received fomr the File->Send Page command was valid.  This is
apparently happening on the "reader" end.
Correction:

The only text in the Alert box is ?]
Another correction: 

This is happening on build 2001102903 not on 2001102811 as reported before...
The message will not show in the viewer, but the source can be viewed after
answer the alert box with Ok and then hitting Ctrl+U
Confirmed with 1029 and 1030 mozilla windows trunk builds on win2K. I've seen
this about 15 times this morning already.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 107490 has been marked as a duplicate of this bug. ***
bug 107439 is also a duplicate. (not sure why the dupe notice didn't show up here.)
this fails IMAP read mail smoketest. This is not specific to SSL IMAP. It
affects regular IMAP as well. It seems to affect any mail 28K or larger for me
(bug 107490 suggests the same).
Severity: critical → blocker
Keywords: smoketest
*** Bug 107431 has been marked as a duplicate of this bug. ***
I'll investigate.

cc ducarroz, since it might involve his changes.
Status: NEW → ASSIGNED
I see this on Linux; it's stopping me reading marek's very important 626kb 0.9.6
email.

Gerv
note, it's imap only.  not seeing this on pop.
I got the same problem. My recent change about attachment went into the tree
only this morning. I'll take a look...
This is one of the few times, I'm resorting to webmail to read the stuff Mozilla
can't ... :-(

I am seeing it in multipart/related and multipart/alternative emails...
here's the stack to the call that does the alert:

nsImapProtocol::AlertUserEventUsingId(unsigned int 2) line 4065
nsImapServerResponseParser::HandleMemoryFailure() line 292
nsIMAPGenericParser::AdvanceTokenizerStartingPoint(long 714) line 350
nsIMAPGenericParser::CreateQuoted(int 1) line 495
nsIMAPGenericParser::CreateParenGroup() line 704 + 13 bytes
nsImapServerResponseParser::bodystructure_data() line 2355 + 11 bytes
nsImapServerResponseParser::msg_fetch() line 1207
nsImapServerResponseParser::numeric_mailbox_data() line 962
nsImapServerResponseParser::response_data() line 704
nsImapServerResponseParser::ParseIMAPServerResponse(const char * 0x06921350, 
int 0) line 227
nsImapProtocol::ParseIMAPandCheckForNewMail(const char * 0x06921350, int 0) 
line 1232
nsImapProtocol::Bodystructure(const char * 0x06922d20, int 1) line 2386
nsImapProtocol::ProcessSelectedStateURL() line 1896
nsImapProtocol::ProcessCurrentURL() line 1145
nsImapProtocol::ImapThreadMainLoop() line 966 + 14 bytes
nsImapProtocol::Run(nsImapProtocol * const 0x011486ec) line 760
nsThread::Main(void * 0x06910400) line 120 + 26 bytes
_PR_NativeRunThread(void * 0x069101e0) line 413 + 13 bytes
_threadstartex(void * 0x069100e0) line 212 + 13 bytes
KERNEL32! 77e92ca8()
I don't know if it's related but, the messages that I can see without trouble
that are multipart have really small separator lines.
this line is failing:

+ if (fStartOfLineOfTokens && ((int32) strlen(fStartOfLineOfTokens) >= 
bytesToAdvance))

in nsIMAPGenericParser.cpp, which leads us to call HandleMemoryFailure() which 
throws the alert.

still looking.
ducarroz thinks it might be jag's recent string changes to the imap code.

investigating...
Comment on attachment 55755 [details] [diff] [review]
fix

sr=bienvenu
Attachment #55755 - Flags: superreview+
That's wacky!
fixed, bienvenu is looking into calling truncate.

there might be a real string bug here:  returnString.SetCharAt(0, charIndex) 
isn't adjusting mLength, when it should.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
apologies for pointing the finger at ducarroz.

thanks to bienvenu and ducarroz for helping debug / figure this out.
Comment on attachment 55755 [details] [diff] [review]
fix

For my understanding, nsCString.Length() return a wrong value because earlier we use SetCharAt to set a null character but the length internally has not been recalculated. nsCRT::strlen does not cach the string length and therefore return the right value. R=ducarroz
Attachment #55755 - Flags: superreview+ → review+
Heh, I was about to post this comment, when I conflicted with sspitzer's, and
now with ducarroz':

479         returnString.SetCharAt(0, charIndex);

I think what you really want to do is change that to 

  returnString.SetLength(charIndex);

since the ToNewCString below (which I guess I changed from strdup to
ToNewCString) will also use the string's idea of its length to allocate the copy
buffer, instead of looking at where the first '\0' is.
I think bienvenu is looking at the real fix...
yeah, SetLength, or Truncate. I'll attach my patch.
Comment on attachment 55764 [details] [diff] [review]
proposed fix (I've removed tabs from this function as well)

r=jag

Great, thanks for fixing this. I should've caught that when I was making the change.
Attachment #55764 - Flags: review+
*** Bug 107565 has been marked as a duplicate of this bug. ***
Comment on attachment 55764 [details] [diff] [review]
proposed fix (I've removed tabs from this function as well)

sr=sspitzer
Attachment #55764 - Flags: superreview+
*** Bug 107601 has been marked as a duplicate of this bug. ***
bienvenu, could you check in your new patch?
ok, I've checked in my fix.
using build 20011113 verified.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: