Closed
Bug 260735
Opened 20 years ago
Closed 20 years ago
Crash when viewing a particular email message
Categories
(Thunderbird :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: jake, Assigned: Bienvenu)
Details
(Keywords: crash)
Attachments
(1 file)
54.00 KB,
message/rfc822
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20040914 Firefox/0.10 I have attached a sample HTML message which causes a crash when it is viewed - either automatically in the preview pane or when this is switched off, by double clicking on the message. Reproducible: Always Steps to Reproduce: 1. Open the eml message file that I have attached by File...Open saved message.. 2. 3. Actual Results: Thunderbird opens the message display window very briefly before crashing and exiting. It appears as though the problem occurs during the parsing or rendering of the message. Expected Results: Rendered the message without crashing. Problem experienced with Thuderbird version 0.8 (20040913)
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Updated•20 years ago
|
Assignee | ||
Updated•20 years ago
|
Assignee: mscott → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•20 years ago
|
||
That message is pretty crufty, but it does render without problems for me with TB 0.8, Win2K. I'm assuming you are viewing the message with View|Message Body As|Original HTML set. Do you get a crash if you change to Simple HTML and then view it? If you're using TB 0.8, when the message is first loaded (as Original HTML), there should be a header bar telling you that images are blocked -- do you see that? Or does it crash before it gets that far? The four image attachments are actually unused in the message, since the 'src' elements of each of the <img> tags in the HTML part is an http: reference (to the Web), rather than a cid: reference to the message source. The <img> at the end of the message is a web bug; the URL in that tag's src redirects to http://blahblahblah/Pixel.gif, and the image is not visible in the message. The fifth attachment proves to be the same thing, once renamed to pixel.gif and opened.
Comment 3•20 years ago
|
||
Did you reproduce this, David?
URL: EML file attached
Summary: Thuderbird crashes when viewing a particular email message → Crash when viewing a particular email message
Assignee | ||
Comment 4•20 years ago
|
||
worked fine for me with a trunk build...
Reporter | ||
Comment 5•20 years ago
|
||
The problem was occuring with View|Message Body As|Original HTML set, but I have since tried with Simple HTML and Plain Text with the same results - which presumably indicates that the problem is with the the parsing of the message rather than the rendering. The message window that is opened doesn't appear to show the "blocked images" bar before the crash, but it does disappear very quickly so it is hard to see. I'll check to see if it still happens with the latest nightly.
Comment 6•20 years ago
|
||
Bug 260994 is also about certain messages causing a crash under Linux. Jake Metherell, is the crash generating Talkback reports? If so, please post the talkback ID here. Can you port this message to a Mozilla 1.8a build and see if the crash reproduces there?
Comment 7•20 years ago
|
||
Jake Metherell, are you still encountering this bug? Note that bug 223600 has been fixed.
Reporter | ||
Comment 8•20 years ago
|
||
I have just tried opening the email using version 0.9+ (20041117) and it now opens correctly. This problem is now fixed. Thanks for all your help.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 9•20 years ago
|
||
Reopened to fix resolution; Fixed implies a particular patch is known to have solved the problem. I'm not sure this is a dupe, so =>WFM
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•