Display attachments inline often does nothing

RESOLVED INCOMPLETE

Status

--
major
RESOLVED INCOMPLETE
12 years ago
10 years ago

People

(Reporter: ggerard, Assigned: mscott)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: closeme 2008-08-28)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9
Build Identifier: 

Not sure describe fully as it's just been experiential.

Basically, I've received several messages from friends where the attachments show up as broken links inline. I switch off display attachments inline and don't see the pictures at the bottom. I switch back on DAI and nothing changes either.

Sometimes I can get TB to load the message successfully after restarting TB but it's not 100% of the time. I think this is a TB problem because of this (TB shouldn't get confused internally and require a restart).

I can't tell if TB is actively trying to load the message, pull just the part, or is hosed as there is no status given to the user whatsoever. Well, that's a lie. I have the "stop" button on the message window but pressing it does nothing ("Owwwww! My eyes! These goggles do nothing!" in the words of Ranier Wolfcastle/McBain...).

Outlook displays the message just fine. Kerio's webmail does too. Using the JavaMail API to go against the server is keen.

Reproducible: Always

Steps to Reproduce:
See details above.
Actual Results:  
A blank message window sometimes. After restarting TB, I'll get a image outlines with the broken link decal instead of the actual image.

Expected Results:  
The pictures attached to be displayed or available to save off.

This happens a lot.

I use the Kerio mailserver which has otherwise been a champ of an IMAP server when I've programmed against it with JavaMail's IMAP implmentation or using Outlook (can I attach a wretching sound?)

I consider this major as other clients work fine against the mail server and the specific message and displaying mail in its full glory is, well, pretty much the reason to use a mail client...

Comment 1

12 years ago
(In reply to comment #0)
> Basically, I've received several messages from friends where the attachments
> show up as broken links inline. 

You mean "broken image icons" within the message body?  The typical cause of the broken-image icon is that the images included with the message have been sent with a MIME type of "application/octet-stream".  When this is the case, TB doesn't display the images inline.  (Nor does it display 
application/octet-stream images inline when they actually *are* attachments.)

(Neither does Firefox, if images in the web page are served up with that same MIME type.  The difference is, webservers usually provide the correct MIME type.  When creating an email with images, Outlook Express often does not.)

When this happens, the parts that are in the message but which were not used within the message body are shown in the attachments panel -- which I'm guessing is what you're seeing.  You can open these attachments, altho the exact behavior at this point is complex -- again, because of the 
application/octet-stream MIME type.


> Sometimes I can get TB to load the message successfully after restarting TB
> but it's not 100% of the time. 

I don't understand this.  Is this mail on an IMAP account, perhaps with very large images?  If you're ever actually seeing the image displayed in the message, then the above explanation doesn't pertain.
(Reporter)

Comment 2

12 years ago
Yes, IMAP being used.
Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies?

(1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 2.0.0.16)
Whiteboard: closeme 2008-08-28
RESO INCO per lack of response to the last question. If you feel this change was made in error, please respond to this bug with your reasons why.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.