31052 - Display attachments inline: Contents & formatting of attached HTML file (background/CSS styles/position:absolute/dir="rtl"...) leak into main HTML part or vice versa (wrong bgcolor/images/unclosed tags...: unreadable; multipart/mime, iframe,send web page)

Status: NEW

(MailNews Core :: MIME, defect)

Description

[laurel]

Using 2000-03-07-09m15 commercial build mac OS 9.0

Even though my message compose window is left at default(black) text, when I do
a send page the message will display my added comments in colored text.  The
compose window doesn't reflect the color but when message is received and
displayed the text is colored (green). Happens when using either plain text or
html compose window.

1.  From browser do a file|Send Page --> a compose window opens.
2.  Address the message to yourself, place cursor on the blank line above the
link in the body portion of the message.  Type a few letters. Note they appear
in the compose window in black text.
3.  Send the message, get it and select it.

Result:  Text you added to the message is in colored text. It shouldn't be.

Comment 1

[Jean-Francois Ducarroz]

HTML or plain text compose?

Comment 2

[laurel]

Turns out it doesn't happen on all pages, maybe background related.
Was using http://www.dead.net   (of course, psychedelic color!)
Happens with either plain text or html compose.
Happens on all platforms.

Comment 3

[Jean-Francois Ducarroz]

But if you display the same message with 4.x, no problem. Seems that text colors  
set by the attachment affect as well the beginning of the message. Message 
display or Layout problem?

Comment 4

[Jean-Francois Ducarroz]

Attachment: Testcase 1: Message that produces the problem

Comment 5

[Jean-Francois Ducarroz]

reassign to rhp

Comment 6

[rhp (gone)]

This is hysterical...this is the only bug all month that made me laugh :-)
Like wow man....its a Feature :-)

- rhp

Comment 7

[rhp (gone)]

*** Bug 31690 has been marked as a duplicate of this bug. ***

Comment 8

[lchiang]

luis - can you try this and see if it still happens with the latest mac build?

Comment 9

[rhp (gone)]

This is not easy to fix. The problem we are having is that 
attached web pages that have color attributes set for that HTML document are 
changing the webshell for the entire message. In 4.x, we enclosed the 
attachment in a LAYER and this wouldn't happen.

Comment 10

[Phil Peterson]

There's no way to wrap this in a <div>?

Comment 11

[rhp (gone)]

*** Bug 57666 has been marked as a duplicate of this bug. ***

Comment 12

[scottputterman]

reassigning to ducarroz

Comment 13

[Jean-Francois Ducarroz]

still appends in 0.9.5!

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 108461 has been marked as a duplicate of this bug. ***

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 155538 has been marked as a duplicate of this bug. ***

Comment 16

[Daniel Wang]

*** Bug 171774 has been marked as a duplicate of this bug. ***

Comment 17

[Daniel Wang]

*** Bug 69199 has been marked as a duplicate of this bug. ***

Comment 18

[esther]

Attachment: image showing mail message with attached images and home.netscape.com

image showing mail message with attached images and home.netscape.com

Comment 19

[esther]

Attachment: image showing mail message with attached images and abcnews.com

image showing mail message with attached images and abcnews.com

Comment 20

[esther]

 I'm renominating this bug.  Our Basic Functional test has a case to send
several attachments including an webpage.  In performing this test, I attached
the following web pages along 2 inline type attachmens and found these web pages
spill their background color over the whole mail message. This is bad, in the
Netscape home page test, text overlaps making the web page non very readable. 
In the abcnews webpage the dark blue background makes the text I typed very hard
to see. We need this fixed.

Comment 21

[esther]

Note, in the test I ran in the above comment I was just adding the web page to a
message I was composing using File|Attach|Webpage.  

Comment 22

[Boris Zbarsky [:bzbarsky]]

*** Bug 198555 has been marked as a duplicate of this bug. ***

Comment 23

[esther]

*** Bug 200396 has been marked as a duplicate of this bug. ***

Comment 24

[esther]

nominating again.  I think people do a Send Page of a web site more these days
and this bug is bad.  To see why it's so bad, bring up abcnews.com and do a Send
page to yourself, adding text above the link, now retrieve the message.   Do you
see the text you typed.  It's black text on a dark blue background, you can miss
it if you don't know it's there.   

Comment 25

[esther]

I actually use 4.7 to do a Send Page to someone outside our company because I
know this is broken.

Comment 26

[Samir Gehani]

Mail triage team: nsbeta1+/adt3

Comment 27

[(not reading, please use [e-mail] instead)]

taking

Comment 28

[Simon Montagu :smontagu]

Another case which I think is the same bug rather than a dependency: after doing
Send Page or manually adding an HTML attachment with either <html dir="rtl"> or
<body dir="rtl">, my added comments also become right-to-left (in plain text or
HTML email).

Comment 29

[Igor Velkov]

Bug still there. Try to send page from Live Journal -
http://www.livejournal.com/users/yatsutko/500244.html

Comment 30

[steve bowden]

(In reply to comment #10)
> There's no way to wrap this in a <div>?
or even an <iframe> ?
is anything happening in Thunderbird?

Comment 31

[Matthias Bockelkamp]

The problem is here:

http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimei.cpp#1811
http://lxr.mozilla.org/seamonkey/source/mailnews/mime/emitters/src/nsMimeBaseEmitter.cpp#786

A possible workaround would be emitting the html subdocuments data:-encoded
using iframes. But I'm not used to iframes, so I have no idea how to show the
iframe in exactly the size of the contained document. Perhaps someone else has
more knowledge of that.

CCing mscott and bienvenu.

Comment 32

[Mike Cowperthwaite]

Bug 76804 comment 12 (that bug is probably a dupe of this) suggests bug 341059 as a means of addressing this problem.
See also bug 292336.

Comment 35

[Bryan Clark (DevTools PM) [:clarkbw]]

Perhaps also, the inclusion of bug 80713 will mean that we can actually have separate documents via iframes.  

Comment 38

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5pre) Gecko/20091026 SeaMonkey/2.0.1pre - Build ID: 20091026001646

I believe this is a Layout bug, because it happens even in the Browser when viewing a message/rfc822 document containing a text/html attachment, see for example bug 524639 duped to bug 76804 duped to here.

However I have no idea which Layout component of the Core product to move it to.

Comment 39

[Simon Montagu :smontagu]

I think the component is correct: the bug is in mailnews code, in the way we build an HTML representation of the rfc822 document.

Comment 41

[Thomas D. (:thomas8)]

Given that specific bugs with much more descriptive summaries continue to be duped against this bug, the current summary is too fuzzy, unintellegible, and harmless in describing the problem, and STR of comment 0 also look somewhat incomplete.

I am deliberately expanding the summary to the maximum so that we have a better description of what's going on, including more relevant words that help to retrieve this in searches and avoid duplicates.

Comment 44

[Thomas D. (:thomas8)]

Duplicate bug 222892 presents an interesting variant of uncontrolled CSS leaking into unrelated parts that happen to be displayed together in message reader because of "Show attachments inline":

- Unclosed anchor tag with css hover style effects
-> hover effects wrongly applied outside that HTML attachment, e.g. to inline preview of attached image files

This means that broken syntax otherwise contained inside one attached HTML part (confined by <html><body> tags) also leaks uncontrolledly into other unrelated parts displayed inline.

Comment 45

[Thomas D. (:thomas8)]

FTR: Testcase 1 of attachment 6289 [details] is broken, probably because the live images are no longer in their original location at the external server URL.

Comment 47

[Thomas D. (:thomas8)]

Scenarios continued:

Per duplicate bug 525011, backgrounds, styles etc. will even leak from an attached HTML file (content-type:attachment) into the main *plaintext* body part when viewing a *plaintext* mail (with "View attachments inline").

Comment 48

[Sebastian Lisken]

For the record, that was demonstrated in my attachment at bug 441275 comment 1 as well. The styles leak as far as they can possibly get. My attachment shows styles (bold and italics) from either attached HTML document leaking both into the mail (plaintext) part and into the other attached HTML document. If two attached HTML docs set the same style (background colour), it is the later attachment whose setting prevails.

If Thomas' work signifies that this bug is finally taken seriously, that would be very welcome news.

Comment 49

[Sebastian Lisken]

That should have been *main* part (not "mail"). I should proofread my bug comments better, sorry.

Comment 50

[Joshua Cranmer [:jcranmer]]

The problems with inline attachments leaking into the document are very well known, since the MIME parser pretty much displays the message by concatenating the HTML parts together. The fix is to use iframes, but we need bug 80713 to get iframes that autosize. And as long as there is no traction on that other bug, this remains almost impossible to fix.

Comment 51

[Johannes Leushuis]

Are you sure Joshua? It sounds like a common programming error to me. Could using iframes without autosizing already solve this problem? How are other e-mail clients doing this?

Comment 52

[Sebastian Lisken]

Is there no way of separating the parts via XUL? I have very little XUL experience, but that is what I had in mind when writing the first part of bug 441275 comment 9. Currently, it seems that the parts are combined into a single HTML document which is then placed withing a browser element. Could each part get its own HTML document within a browser element or some other XUL container, and could these containers be stacked vertically with some divider in between? One could even consider alternative arrangements, e.g. something close to the way Outlook displays attachments, as a row of buttons on top of the main display window which when pressed switch the contents of the display. (Although personally I would prefer a vertical arrangement.) Which I think partly answers Johannes' question: other clients probably don't follow a browser concept as strictly as TB (with its browser roots) does. The idea to combine all parts into a single HTML document seems natural in a TB context, but it not only leads to the leakage that we're discussing here, it also makes it hard to create UI support for navigating between attachments. (Of course TB has the attachment list at the bottom of the mail window, but I think that was a late addition and in any case, it does not help with navigating between inline-displayed attachments.)

Comment 53

[Joshua Cranmer [:jcranmer]]

(In reply to Johannes Leushuis from comment #51)
> Are you sure Joshua? It sounds like a common programming error to me. Could
> using iframes without autosizing already solve this problem? How are other
> e-mail clients doing this?

Other email clients don't use Gecko and XUL/HTML for their display, or, if they do, they do extremely intrusive HTML parsing that severely limits HTML email capabilities.

(In reply to Sebastian Lisken from comment #52)
> Is there no way of separating the parts via XUL? I have very little XUL
> experience, but that is what I had in mind when writing the first part of
> bug 441275 comment 9. Currently, it seems that the parts are combined into a
> single HTML document which is then placed withing a browser element. Could
> each part get its own HTML document within a browser element or some other
> XUL container, and could these containers be stacked vertically with some
> divider in between?

The solution is to give each HTML part its own document context (I don't know the exact terminology here), but all ways of creating subdocument contexts require fixed viewport sizes. Except for <iframe seamless>, which is what bug 80713 will implement.

Comment 54

[Joe Sabash [:JoeS1]]

(In reply to Joshua Cranmer [:jcranmer] from comment #53)
> 
> The solution is to give each HTML part its own document context (I don't
> know the exact terminology here), but all ways of creating subdocument
> contexts require fixed viewport sizes. Except for <iframe seamless>, which
> is what bug 80713 will implement.

I'm sure the seamless iframe will yield the eventual answer, but I've often thought that opening each part in a separate tab might work as well.
You can do this now with the help of the WAT extension.
Like so with testcase1 of this bug:
Set the pref to show all body parts (mailnews.display.show_all_body_parts_menu)
Open part 1 of the testcase (It will ask for the browser by default)
Copy the mailbox url from the browser display into the WAT searchbar
It will then open that part in a content tab not affected by the other parts.

Of course that is unwieldy for common usage, but it proves that the concept works.

Comment 58

[Thomas D. (:thomas8)]

Duplicate bug 596848, as described in Simon's comment 28, contributes case of <body dir="rtl"> as another major problem when wrong text direction (e.g. from HTML attachment) leaks into other parts and renders them unreadable.

For summary adjustment, I know it looks odd but we need to ensure that this is retrievable from the bug database using popular search words to avoid further duplicates, as laid out in comment 41.

Comment 59

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #58)
> Duplicate bug 596848, as described in Simon's comment 28, contributes case
> of <body dir="rtl">

Sorry, that's Bug 223364 about the text direction.

Comment 61

[Thomas D. (:thomas8)]

Duplicate bug 121878 contributes another nice and nasty variant of this (see testcase.eml from attachment 801262 [details]): When HTML file attachment has body attribute style="position:absolute; top:0px", inline preview of attachment will overlap message body text and cause visual havoc, as seen in Screenshot of attachment 801265 [details]. It's the art of distortion. ;)