2.35 MB, message/rfc822
2.35 MB, message/rfc822
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) 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
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.
(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
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)...
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.
(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...
(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.
(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...
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.
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?
(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...
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... ;)
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...
(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"
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.
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.
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.
FTR: we manage to display malformed message of testcase1 (attachment 633097 [details]), but trying to print makes TB collapse and become unresponsive.