Ky sajt do të funksionojë me kufizime, teksa bëjmë mirëmbajtjen e tij për të përmirësuar punën tuaj. Nëse një artikull nuk e zgjidh problemin tuaj dhe dëshironi të bëni një pyetje, kemi bashkësinë tonë të asistencës, e gatshme për t’ju ndihmuar, te @FirefoxSupport në Twitter dhe/r/firefox në Reddit.

Kërkoni te Asistenca

Shmangni karremëzime gjoja asistence. S’do t’ju kërkojmë kurrë të bëni një thirrje apo të dërgoni tekst te një numër telefoni, apo të na jepni të dhëna personale. Ju lutemi, raportoni veprimtari të dyshimtë duke përdorur mundësinë “Raportoni Abuzim”.

Mësoni Më Tepër

Thunderbird is not displaying the html version of certain emails

  • 6 përgjigje
  • 1 e ka hasur këtë problem
  • 1 parje
  • Përgjigjja më e re nga jetkins

more options

For the most part, Thunderbird is displaying the HTML version of my received emails, as I have asked it to (View --> Message Body As --> Original HTML), but for one particular daily report I receive, it only displays the text/plain version and appears to completely ignore the text/html version.

I have examined the message source and can see no obvious problems; I've run the HTML through an online parser with only a couple of minor warnings detected; I can forward the emails to my work account where my Lotus Notes happily displays the HTML-formatted version, but Thunderbird steadfastly refuses to show me anything but the plain text.

Before I go to VMware and tell them their software is generating problematic emails, is there some form of debugging that I can turn on that might give some idea why this is happening?

Thanks!

For the most part, Thunderbird is displaying the HTML version of my received emails, as I have asked it to (View --> Message Body As --> Original HTML), but for one particular daily report I receive, it only displays the text/plain version and appears to completely ignore the text/html version. I have examined the message source and can see no obvious problems; I've run the HTML through an online parser with only a couple of minor warnings detected; I can forward the emails to my work account where my Lotus Notes happily displays the HTML-formatted version, but Thunderbird steadfastly refuses to show me anything but the plain text. Before I go to VMware and tell them their software is generating problematic emails, is there some form of debugging that I can turn on that might give some idea why this is happening? Thanks!

Zgjidhje e zgjedhur

For the sake of completeness, I researched the relevant RFC based on jcrammer's comment. It's RFC2046, which states in part,

As with "multipart/mixed", the order of body parts is significant. In this case, the alternatives appear in an order of increasing faithfulness to the original content. In general, the best choice is the LAST part of a type supported by the recipient system's local environment.

Now to go file a bug report with VMware. Thanks, Matt!

Lexojeni këtë përgjigje brenda kontekstit 👍 0

Krejt Përgjigjet (6)

more options

open the error console on the tools menu. Clear it. Open the relevant mail Check the error console for new errors and warnings.

Like your online parser, there is a lot of noise, so you have to be selective. Look also in the source for a contenteditable... that will trip Thunderbird almost every time.

more options

Hi, Matt.

Thanks for responding. Unfortunately, opening the troublesome mail doesn't generate any errors or warning, no any sign of anything that looks even remotely like an error in the regular messages that are produced. And no sign of contenteditable in the source, either. :/

more options

Do you have a simple you could zip and email me?

more options

Matt said

Do you have a simple you could zip and email me?

On its way. Thanks!

more options

Updating here on behalf of Matt:

It is a bug, but according to jcrammer (something on a MIME GURU in the Thunderbird world) it is not in Thunderbird. Apparently if you have a multipart/alternative mime email the plain text part must be before the HTML. This email it is HTML first.

more options

Zgjidhja e Zgjedhur

For the sake of completeness, I researched the relevant RFC based on jcrammer's comment. It's RFC2046, which states in part,

As with "multipart/mixed", the order of body parts is significant. In this case, the alternatives appear in an order of increasing faithfulness to the original content. In general, the best choice is the LAST part of a type supported by the recipient system's local environment.

Now to go file a bug report with VMware. Thanks, Matt!