Closed
Bug 138213
Opened 22 years ago
Closed 17 years ago
mozilla stalls fetching content of particular mails, possibly due to 8bit data
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: david, Assigned: cavin)
References
()
Details
Attachments
(2 files, 2 obsolete files)
Moz mail hangs while trying to fetch the content of a particular email [email and IMAP log located at URL]. I suspect it may be due to the 8bit data in the Subject or From headers. Kryptolus loaded the example email in a debug build and will post some stack traces. I'm using build 2002 0413 07 on Linux. IMAP server is UW and SSL is enabled. Once that particular email is attempted, moz mail is useless for that mailbox and everything must be restarted. No crash, just stall. Note, only that particular mailbox is affected. Other mailboxes can be browsed and operated on normally.
Comment 1•22 years ago
|
||
I'll hold off on the stack a bit. The email consists of a *lot* of nested tables. The problem goes away if you remove the charset from meta. Further email will follow shortly. Trying to make a testcase.
Comment 2•22 years ago
|
||
41 seconds to render on 1.5ghz machine ... I'll hold off confirming until I create a minimal test case
Comment 3•22 years ago
|
||
8 nested tables with a form inside the deepest level removing 'marginheight' and 'marginwidth' from the root table causes the message to be rendered instantly will attach the 'somewhat' simplified message (it's still rather large)
Just to clarify, the initial problem with this email is during the IMAP fetch procedure on startup. There are 761 emails in my INBOX, this particular one is #740. Moz starts fetching new emails, gets up to #740, and stalls. Moz isn't trying to render a message body just yet.
Comment 5•22 years ago
|
||
Comment 6•22 years ago
|
||
can you attach an imap log? http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
IMAP log is at http://blue-labs.org/mozbugs/imap.stall.log.138213 -d
Comment 8•22 years ago
|
||
Looking at the log it does indeed look like an 8 bit character parsing issue o our end. cavin loves these 8 bit bugs. re-assigning.
Assignee: mscott → cavin
Status: UNCONFIRMED → NEW
Ever confirmed: true
Would someone -please- do something about this. Even a hack that displays raw data would be fine. Totally stalling access to the mailbox is unacceptable.
Severity: normal → major
Reporter | ||
Comment 10•22 years ago
|
||
Reporter | ||
Comment 11•22 years ago
|
||
Attachment #82669 -
Attachment mime type: application/octet-stream → message/rfc822
Attachment #82670 -
Attachment mime type: application/octet-stream → message/rfc822
Reporter | ||
Comment 12•22 years ago
|
||
Viewing the offending emails in mozilla works fine, loading them in the mailbox breaks messenger.
Assignee | ||
Comment 13•22 years ago
|
||
I could not reproduce the problem using message from http://bugzilla.mozilla.org/showattachment.cgi?attach_id=82669. I sent the message to an imap account and I saw garbage chars in both the From: and Subject: headers but the body text showed the right Korean chars. I copied the message to a local folder and it worked fine as well.
Reporter | ||
Comment 14•22 years ago
|
||
That one works fine. Odd, I must have attached the wrong one. I'm attaching another email that it does stall on. Simply append it to $mailbox. -d
Attachment #82669 -
Attachment is obsolete: true
Attachment #82670 -
Attachment is obsolete: true
Assignee | ||
Comment 15•22 years ago
|
||
I still could not reproduce the problem using message from http://bugzilla.mozilla.org/showattachment.cgi?attach_id=82808. I compared the my log against the one from comment #6 and the downloaded headers are all the same. The difference is that the command used to download the header in the log from comment #6 is: 15 UID fetch 2728:2750 (UID RFC822.SIZE BODY.PEEK[]) and the server response is: * 740 FETCH (UID 2728 RFC822.SIZE 24273 BODY[] {24273} whereas mine is: 7 UID fetch 1:2 (UID RFC822.SIZE BODY.PEEK[HEADER] FLAGS) and the server response is: * 2 FETCH (FLAGS (\Seen) UID 2 RFC822.SIZE 25045 BODY[HEADER] {1195} Note that mine does not try to load the message body yet (ie, it uses BODY.PEEK[HEADER] instead of BODY.PEEK[]). I'm running a build from this week so I think some fixes might have been made to fix the fetch command for similar problems. David, are you still running the build from 04/13/02? Can you try the latest build to see if the behavior changes. Can you also attach an IMAP log if it still does not work? Thanks.
Reporter | ||
Comment 16•22 years ago
|
||
Ok, latest build tested, 5/11 08. Still have problems. I put the original email I'm using (http://blue-labs.org/mozbugs/mail.stall.138213) in a folder, tried loading it, no go. I've updated my mozbugs page (http://blue-labs.org/mozbugs/) and here is the URL to the IMAP log.http://blue-labs.org/mozbugs/mail.stall.log2.138213 I've added some comments inline w/ the logfile indicating where I was doing things. Here's the summary of the unmodified log file: startup, 463 lines copy eml file load bluelist folder now have 499 lines clicked on broken email now have 520 lines clicked on INBOX again now have 565 lines
Updated•20 years ago
|
Product: MailNews → Core
Reporter | ||
Comment 17•17 years ago
|
||
i believe the rewrite that dealt with embedded NULLs also fixed this. this bug is WFM now.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Updated•15 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•