Malformed message with content-type:image/jpeg part wrongly declared as text/html part, when displayed in message reader after trying to parse 143 extra pages of base64 encoded image as html, chokes 3.1.1 performance (almost unusable), but not 3.0.6

RESOLVED INVALID

Status

Thunderbird
General
RESOLVED INVALID
8 years ago
6 years ago

People

(Reporter: Charles, Unassigned)

Tracking

({perf})

x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: performance impact probably dupe of bug 568810)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7
Build Identifier: 3.1.1

I'm not sure how else to describe this.

I do have an email to test with, and when opened with 3.0.6, it opens at about normal speed (a second or two), and I see the first .jpg inline, then a bunch of raw/encoded text, like:

PSOCT.jpg

ÿØÿà�JFIF��`�`��ÿí�,Photoshop 3.0�8BIMí������`�����`����ÿâXICC_PROFILE�����HLino��mntrRGB XYZ Î�� ��1��acspMSFT����IEC sRGB��������������öÖ�����Ó-HP �����������������������������������������������cprt��P���3desc��„���lwtpt��ð���bkpt�����rXYZ�����gXYZ��,���bXYZ��@���dmnd��T���pdmdd��Ä���ˆvued��L���†view��Ô���$lumi��ø���measʏ 33;����$tech��0���rTRC��<��gTRC��<��bTRC��<��text����Copyright (c) 1998 Hewlett-Packard Company��desc�������sRGB IEC61966-2.1�����������sRGB IEC61966-2.1��������������������������������������������������XYZ ������óQ����ÌXYZ ����������������XYZ ������o¢��8õ���XYZ ������b™��·…��ÚXYZ ������$ ��„��¶Ïdesc�������IEC http://www.iec.ch�����������IEC http://www.iec.ch����������������������������������������������desc�������.IEC 61966-2.1 Default RGB colour space - sRGB�����������.IEC 61966-2.1 Default RGB colour space - sRGB����������������������desc�������,Reference Viewing Condition in IEC61966-2.1�����������,Reference Viewing Condition in IEC61966-2.1��������������������������view�����¤þ�_.�Ï�íÌ��\ž���XYZ �����L V�P���Wçmeas�����������������������������sig ����CRT curv����������� �����#�(�-�2�7�;�@�E�J�O�T�Y�^�c�h�m�r�w�|���†�‹���•�š�Ÿ�¤�©�®�²�·�¼�Á�Æ�Ë�Ð�Õ�Û�à�å�ë�ð�ö�û %+28>ELRY`gnu|ƒ‹’š¡©±¹ÁÉÑÙáéòú&/8AKT]gqz„Ž˜¢¬¶ÁËÕàëõ�

With thousands and thousands more lines similar to the last two lines, then after that, the second/last jpg is displayed inline.

I could 'Edit as new' and send this to someone if desired, it isn't extremely sensitive. The message is about 2.4MB in size, but takes minutes to fully download and as I said, the UI gets very sluggish, almost unresponsive at times, during this time.

Reproducible: Always
(Reporter)

Comment 1

8 years ago
More info:

When I disable 'Display attachments inline', selecting the message doesn't cause any UI responsiveness problems, but it displays as totally blank in the preview pane.

Comment 2

8 years ago
(In reply to comment #0)
> I do have an email to test with, and when opened with 3.0.6, it opens at about
> normal speed (a second or two), and I see the first .jpg inline, then a bunch
> of raw/encoded text, like: ...

I'm a little confused. Is the following correct?

* In 3.0.6, the message loads in a couple seconds and it looks like <image1> <line trash> <image2>
* In 3.1.1, the message takes a long time to load but still looks like <image1> <line trash> <image2> when it finishes
(Reporter)

Comment 3

8 years ago
Yes, except the UI in 3.1.1 is *extremely* sluggish the whole time and even after it is finished loading - clicking anywhere can cause it to go unresponsive for dozens of seconds again, while 3.0.6 is fine...

I don't have a 3.1.0 version to try it with to see if it started with 3.1.1, or 3.1

I looked at the source of  the problem message and saw some references to TNEF and Microsoft Exchange (and of course the email body had all of the classic HTML garbage associated with Outlook HTML messages)...

Comment 4

8 years ago
The message is probably invalid in one way or another, but the performance is probably due to something else. The performance part sounds like bug 568810.
(Reporter)

Comment 5

8 years ago
(In reply to comment #4)
> The message is probably invalid in one way or another,

I don't doubt that a bit - but if 3.0.6 can handle it ok, 3.1.1 should be able to...

> but the performance is probably due to something else. The performance part
> sounds like bug 568810.

Nope... we work with very large attachments - some as big as 40MB - and they are fine.

This message is only 2.4MB...

I have the message source in an ODF file - I'll sanitize it in the morning and zip it and attach it to this bug (gotta run for now)...

Thanks for taking a look...

Comment 6

8 years ago
(In reply to comment #5)
> (In reply to comment #4)
> > but the performance is probably due to something else. The performance part
> > sounds like bug 568810.
> 
> Nope... we work with very large attachments - some as big as 40MB - and they
> are fine.

That bug is about large amounts of non-attachment data (regular text) causing performance issues. Having "thousands and thousands more lines similar to the last two lines" sounds like it might be causing the same issue. My guess is that it's a performance regression in the actual rendering of really large amounts of text in the message pane.
(Reporter)

Comment 7

8 years ago
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > but the performance is probably due to something else. The performance part
> > > sounds like bug 568810.
> > 
>> Nope... we work with very large attachments - some as big as 40MB - and they
>> are fine.

> That bug is about large amounts of non-attachment data (regular text) causing
> performance issues. Having "thousands and thousands more lines similar to the
> last two lines" sounds like it might be causing the same issue. My guess is
> that it's a performance regression in the actual rendering of really large
> amounts of text in the message pane.

Could be, but the large amounts of text, in my case, is not actual text, per that bug. This message only contains a few lines of text, but it also has two jpg attachments, and the thousands of lines of gobbledygook text being displayed in  the mail body is obviously the ENCODED jpg files.

So, ok, maybe there are two bugs here - one, which is *causing* TB to improperly display the thousands of lines of ENCODED TEXT that is actually the jpg - then the performance issue could be a result of bug 568810.

I was going to attach an .odt file that contains the sanitized message source after posting this reply, but then realized, it would probably be better to actually send the message to a developer - who can promise to delete it when they are done. It doesn't contain extremely sensitive information, but it is a real email from one of our clients to one of our internal mail lists intended for our sales staff.

So, if a developer picks up on this and wants me to send the message to them, hopefully I'll hear from them directly.

Anyway, I'll attach/upload the .odt file after posting this anyway...
(Reporter)

Comment 8

8 years ago
Created attachment 459387 [details]
Message Source of the problem message (odt-file)

I can 'Edit as new' and send the problem message directly to a developer upon request if necessary.

Comment 9

8 years ago
Charles, sensitive attachments and comments can also be marked private so that only privileged readers can view them

regarding bug 568810, am i correct that we need more info about both bugs before deciding whether there is a duplicate?
Keywords: perf
Whiteboard: dupe of bug 568810?
Version: unspecified → 3.1
(Reporter)

Comment 10

8 years ago
(In reply to comment #9)
> Charles, sensitive attachments and comments can also be marked private so that
> only privileged readers can view them

Cool, I didn't notice that...

But I was thinking it might be easier if the email was 'sent' via normal smtp rather than uploaded as an attachment... either way is fine with me, so I'll go ahead and save it out and attach it marked private...

> regarding bug 568810, am i correct that we need more info about both bugs
> before deciding whether there is a duplicate?

I don't think so. That bug is *only* about large amounts of plain text causing a performance problem.

I think the performance part of my bug could very well be the same, but whatever is causing the raw encoded text for the .jpg to be displayed inline *along with* the graphic would seem to me to be a separate bug.

So, I'll just change the summary for this bug, but if you think I should open a new one let me know and I will.

Thanks...
(Reporter)

Updated

8 years ago
Summary: Message with 2 jpg attachments chokes 3.1.1, 3.0 is fine → Message with 2 jpg attachments improperly displays encoded text representation of .jpg attachment(s) as well as the graphic itself - chokes 3.1.1 performance (almost unusable), but not 3.0.6
(Reporter)

Updated

8 years ago
Whiteboard: dupe of bug 568810? → performance impact probably dupe of bug 568810
(Reporter)

Comment 11

8 years ago
Ok, summary changed - sorry it is so long - if you can think of a shorter way to describe it please feel free to change it... ;)
(Reporter)

Comment 12

8 years ago
Ok... I didn't see any way to flag the .eml file as 'private'...

Also - I seem to recall a 2MB size limit for attachments? This file is about 2.4MB in size...

Comment 13

6 years ago
(In reply to Charles from comment #10)
> I think the performance part of my bug could very well be the same, but
> whatever is causing the raw encoded text for the .jpg to be displayed inline
> *along with* the graphic would seem to me to be a separate bug.

That part isn't a bug. We're just doing what the email tells us to, and trying to render the JPG as HTML (note the first line):

Content-Type: text/html;
        name="PSOCT.jpg";
        x-mac-creator=3F3F3F3F;
        x-mac-type=3F3F3F3F
Content-Transfer-Encoding: base64
Content-Description: PSOCT.jpg
Content-Disposition: attachment;
        filename="PSOCT.jpg"

Updated

6 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
Summary: Message with 2 jpg attachments improperly displays encoded text representation of .jpg attachment(s) as well as the graphic itself - chokes 3.1.1 performance (almost unusable), but not 3.0.6 → Malformed message with content-type:image/jpeg part wrongly declared as text/html part, when displayed in message reader, chokes 3.1.1 performance (almost unusable), but not 3.0.6

Updated

6 years ago
Summary: Malformed message with content-type:image/jpeg part wrongly declared as text/html part, when displayed in message reader, chokes 3.1.1 performance (almost unusable), but not 3.0.6 → Malformed message with content-type:image/jpeg part wrongly declared as text/html part, when displayed in message reader after trying to parse 143 extra pages of base64 encoded image as html, chokes 3.1.1 performance (almost unusable), but not 3.0.6

Updated

6 years ago
Attachment #459387 - Attachment description: Message Source of the problem message. → Message Source of the problem message (odt-file)

Comment 14

6 years ago
Created attachment 633097 [details]
testcase1.eml (image with wrong content-type:text/html)

Here's attachment 459387 [details] (odf-file) as a plaintext .eml, for ease of testing.
Attachment #459387 - Attachment is obsolete: true

Comment 15

6 years ago
Created attachment 633098 [details]
testcase2.eml (image with corrected content-type:image/jpeg)

...and here's testcase2 (based on testcase1 of attachment 633097 [details]), where I corrected the content-type of the trouble-causing image from
text/html (wrong) to
image/jpeg (right)

And voila - everything works fine, 2 secs to load.

Comment 16

6 years ago
Given the extra 143 pages of encoded .jpg garbage that need to be "parsed" as HTML an then displayed in msg reader because of wrong content-type: text/html, and other large pics, I think parsing time of that msg on my slow machine is actually reasonable with about 20secs.

But anyway, performance issue is covered by bug 568810.

The more important part of this bug is invalid per comment 13: TB does the correct thing, the source code is wrong to declare image part as content-type:text/html. If image has correct content-type:image/jpeg, there is no problem whatsoever, as seen from corrected testcase 2 (attachment 633098 [details]), which loads correctly in 2 secs.

Comment 17

6 years ago
FTR: we manage to display malformed message of testcase1 (attachment 633097 [details]), but trying to print makes TB collapse and become unresponsive.
You need to log in before you can comment on or make changes to this bug.