I cannot view an inline attachment from an aol user (embed images in very deeply nested DIV/TABLE is not shown)

NEW
Unassigned

Status

7 years ago
4 years ago

People

(Reporter: campagna, Unassigned)

Tracking

(Depends on: 3 bugs)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 600703 [details]
A series of pictures in Russia of their winter.

When i view the source of an e-mail, I see the attachment, but not in my mail message. If I send to my yahoo address, the attachments show up. Attached is the show source in .txt of the message.
(In reply to campagna from comment #0)
> When i view the source of an e-mail, I see the attachment, (snip)

There is no ATTACHMENT in the mail from perspective of mail structure.
Any image sub parts is embed image of HTML mail which is encapsuled in multipart/related.

> but not in my mail message.

I could observe it with View/Message Body As/Original or Simple HTML, in Tb 10.0.1 and Tb 13.0a1 2012/02/25 build on MS Win-XP.
If html is replaced by next, 37 images are shown as expected.
> <html><head></head><body>
> Start of mail<br>
> <img id=3DecxMA1.1329232346  src=3D"cid:0C9113C08D644FB0A5FCED0D39F06600@OwnerPC" width=3D640 height=3D442><br>
>(snip, 37 images are embed in the HTML)
<IMG id=3DecxMA9.1329232346  src=3D"cid:92E64C9C7C3A48D1B59B59C8D8FFA99B@OwnerPC" width=3D640 height=3D480><br>
> End of mail
> </body></html>
Note: Slowness in image loading was observed(Bug 563677). While "Loading ...", short freeze of UI was seen.

Meaninglessly very very deep DIV nesting and TABLE nesting may be a cause.
Nesting of BLOCKQUOTE may be relevant. Bug 563677 may also be relevant(timeout in image loading due to slowness)

To see the embed images as if attachment, use following feature.
1. mailnews.display.show_all_body_parts_menu = true
2. View/Message Body As/All Body Parts
Because "All Body Parts" is for trouble shooting purpose, please don't use it as daily use setting.

Confirming per test result with attached mail.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: I cannot view an inline attachment from an aol user → I cannot view an inline attachment from an aol user (embed images in very deeply nested DIV/TABLE is not shown)
If 153 x "<div>" is changed to "", embed images are shown as expected.
Culprit was meaningless very deep <div> nesting.
Summary: I cannot view an inline attachment from an aol user (embed images in very deeply nested DIV/TABLE is not shown) → I cannot view an inline attachment from an aol user (embed images in very deeply nested DIV is not shown)
(Reporter)

Comment 3

7 years ago
OK, is there a way I can set the browser to work at least as well as the yahoo mail program ? I appreciate the help, don't get me wrong, but how can this be prevented in the future with other incoming e-mails ?
(Reporter)

Comment 4

7 years ago
Also, where is this option you people have mentioned ? I can't find it in the option menu structure. 'View/Message Body As/All Body Parts' or 'mailnews.display.show_all_body_parts_menu = true'
(In reply to campagna from comment #3)
> how can this be prevented in the future with other incoming e-mails ?

Ask mail sender not to use too many meaningless <div>s in his HTML mail.

(In reply to campagna from comment #4)
> I can't find it in the option menu structure.
> 'mailnews.display.show_all_body_parts_menu = true'

Set via Config Editor. (Tools/Options/Advanced/General, Config Editor)  

>  'View/Message Body As/All Body Parts'

After setting show_all_body_parts_menu=true, it's shown in the menu, because show_all_body_parts_menu=true is setting to show "All Body Parts" under "View/Message Body As".
(Reporter)

Comment 6

7 years ago
After setting show_all_body_parts_menu=true, it's shown in the menu, because show_all_body_parts_menu=true is setting to show "All Body Parts" under "View/Message Body As".    I set the 'show_all_body_parts_menu=true' , but I can't find the "View/Message Body As" BTW, the images still don't show. We can't expect people to bit twiddle when forwarding e-mail, so telling someone to drop the multiple divs is not a viable option. What does yahoo mail do that we can't ?
Thanks for the help so far, I really do appreciate it.
> the images still don't show.

"All Body Parts" is to show any sub part of multipart as if attachment in attachment pane in order to provie a way to save or open data in unaccessible sub parts. If you need to know about "All Body Parts", do Google search for "All Body Parts", please. 

Tb fails to show embed images if too deeply nested <div> is used. It's simply a bug of Tb(actual Tb's flaw in code). I don't know how to show such never-well-formed html mail by Tb even though Tb has already known this bug.

Comment 8

7 years ago
Is this related to Bug 354161?
(In reply to Alice0775 White from comment #8)
> Is this related to Bug 354161?

I think so.
Depends on: 354161
Summary: I cannot view an inline attachment from an aol user (embed images in very deeply nested DIV is not shown) → I cannot view an inline attachment from an aol user (embed images in very deeply nested DIV/TABLE is not shown)
Depends on: 256180
Depends on: 452038
(Compliment of comment #7)
> It's simply a bug of Tb(actual Tb's flaw in code).

Before HTML5, it was simply mail sender's fault, because HTML4 or before was based on SGML and maximum nest level of a tag(TAGLVL) is defined as 100 by SGML.
After HTML5, HTML is free from SGML, and it looks that HTML5 doesn't have nest level limitation in spec. So, it can be called as Tb's bug.
However, it's similar to "recursive function call" vs "do loop" relevant issue.
  Recursive call;
    function F(N){var X;if(N>1)X=N*F(N-1);else if(N>=0)X=1;else X=1;return X;}
    var factorial=F(10000);
  Do loop;
    function F_Loop(N){X=1;for(var M=N;M>=2;M--){X=X*M} return X;}
    var factorial=F_Loop(10000);
  Because resource for stack is never infinite in any actual system,
  Recursive call will reach stack size limitation sooner or later, if huge N.
I think construction/parsing of DOM resource in Mozilla is rather Recursive call type than Do loop type, because it's natural implementation of DOM.
Woops. Too quick Enter...
To avoid crash/going out of control etc. due to resource shortage caused by too deep nest level, Mozilla has MAX_REFLOW_DEPTH value internally.
Even if this value is increased, it reaches to this limit if deeper tag next level is used by Web site or HTML mail.
So, it's rather a current restriction of Mozilla than actual bug of Mozilla.

I believe there is no need to support such stupid Web site or HTML mail, although, needless to say, appropriate/kind warning message at somewhere is mandatory to avoid confusion by Mozilla users.
You need to log in before you can comment on or make changes to this bug.