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)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: thomas.swan, Assigned: sspitzer)
References
Details
(Keywords: smoketest)
Attachments
(2 files)
784 bytes,
patch
|
bugzilla
:
review+
|
Details | Diff | Splinter Review |
1.07 KB,
patch
|
jag+mozilla
:
review+
sspitzer
:
superreview+
|
Details | Diff | Splinter Review |
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...
Reporter | ||
Comment 1•23 years ago
|
||
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.
Reporter | ||
Comment 2•23 years ago
|
||
Correction: The only text in the Alert box is ?]
Reporter | ||
Comment 3•23 years ago
|
||
Another correction: This is happening on build 2001102903 not on 2001102811 as reported before...
Reporter | ||
Comment 4•23 years ago
|
||
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
Comment 5•23 years ago
|
||
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
Comment 6•23 years ago
|
||
*** Bug 107490 has been marked as a duplicate of this bug. ***
Comment 7•23 years ago
|
||
bug 107439 is also a duplicate. (not sure why the dupe notice didn't show up here.)
Comment 8•23 years ago
|
||
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
Comment 9•23 years ago
|
||
*** Bug 107431 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 10•23 years ago
|
||
I'll investigate. cc ducarroz, since it might involve his changes.
Status: NEW → ASSIGNED
Comment 11•23 years ago
|
||
I see this on Linux; it's stopping me reading marek's very important 626kb 0.9.6 email. Gerv
Assignee | ||
Comment 12•23 years ago
|
||
note, it's imap only. not seeing this on pop.
Comment 13•23 years ago
|
||
I got the same problem. My recent change about attachment went into the tree only this morning. I'll take a look...
Reporter | ||
Comment 14•23 years ago
|
||
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...
Assignee | ||
Comment 15•23 years ago
|
||
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()
Reporter | ||
Comment 16•23 years ago
|
||
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.
Assignee | ||
Comment 17•23 years ago
|
||
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.
Assignee | ||
Comment 18•23 years ago
|
||
ducarroz thinks it might be jag's recent string changes to the imap code. investigating...
Assignee | ||
Comment 19•23 years ago
|
||
Comment 20•23 years ago
|
||
Comment on attachment 55755 [details] [diff] [review] fix sr=bienvenu
Attachment #55755 -
Flags: superreview+
Comment 21•23 years ago
|
||
That's wacky!
Assignee | ||
Comment 22•23 years ago
|
||
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
Assignee | ||
Comment 23•23 years ago
|
||
apologies for pointing the finger at ducarroz. thanks to bienvenu and ducarroz for helping debug / figure this out.
Comment 24•23 years ago
|
||
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+
Comment 25•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
I think bienvenu is looking at the real fix...
Comment 27•23 years ago
|
||
yeah, SetLength, or Truncate. I'll attach my patch.
Comment 28•23 years ago
|
||
Comment 29•23 years ago
|
||
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+
Assignee | ||
Comment 30•23 years ago
|
||
*** Bug 107565 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 31•23 years ago
|
||
Comment on attachment 55764 [details] [diff] [review] proposed fix (I've removed tabs from this function as well) sr=sspitzer
Attachment #55764 -
Flags: superreview+
Comment 32•23 years ago
|
||
*** Bug 107601 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
bienvenu, could you check in your new patch?
Comment 34•23 years ago
|
||
ok, I've checked in my fix.
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•