Open Bug 31052 Opened 22 years ago Updated 2 years ago

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)

Categories

(MailNews Core :: MIME, defect)

defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: laurel, Unassigned)

References

(Depends on 4 open bugs, Blocks 2 open bugs)

Details

Attachments

(3 files)

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.
QA Contact: lchiang → laurel
Keywords: pp
HTML or plain text compose?
Status: NEW → ASSIGNED
Target Milestone: M15
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.
Keywords: pp
OS: Mac System 9.0 → All
Hardware: Macintosh → All
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?
reassign to rhp
Assignee: ducarroz → rhp
Status: ASSIGNED → NEW
Component: Composition → MIME
Target Milestone: M15
This is hysterical...this is the only bug all month that made me laugh :-)
Like wow man....its a Feature :-)

- rhp
*** Bug 31690 has been marked as a duplicate of this bug. ***
Target Milestone: M16
Target Milestone: M16 → M18
Status: NEW → ASSIGNED
luis - can you try this and see if it still happens with the latest mac build?
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.
Target Milestone: M18 → Future
There's no way to wrap this in a <div>?
*** Bug 57666 has been marked as a duplicate of this bug. ***
reassigning to ducarroz
Assignee: rhp → ducarroz
Status: ASSIGNED → NEW
still appends in 0.9.5!
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.9
*** Bug 108461 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1+
Priority: P3 → P2
Blocks: 122274
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.2
No longer blocks: 122274
*** Bug 155538 has been marked as a duplicate of this bug. ***
*** Bug 171774 has been marked as a duplicate of this bug. ***
*** Bug 69199 has been marked as a duplicate of this bug. ***
image showing mail message with attached images and home.netscape.com
image showing mail message with attached images and abcnews.com
 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.
Keywords: nsbeta1-nsbeta1
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.  
Keywords: nsbeta1nsbeta1-
*** Bug 198555 has been marked as a duplicate of this bug. ***
*** Bug 200396 has been marked as a duplicate of this bug. ***
QA Contact: laurel → 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.   
Keywords: nsbeta1-nsbeta1
I actually use 4.7 to do a Send Page to someone outside our company because I
know this is broken.
Mail triage team: nsbeta1+/adt3
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt3]
taking
Assignee: ducarroz → sspitzer
Status: ASSIGNED → NEW
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).
Bug still there. Try to send page from Live Journal -
http://www.livejournal.com/users/yatsutko/500244.html
Flags: blocking1.7a?
Flags: blocking1.7a? → blocking1.7a-
(In reply to comment #10)
> There's no way to wrap this in a <div>?
or even an <iframe> ?
is anything happening in Thunderbird?
Product: MailNews → Core
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.


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.
Assignee: sspitzer → nobody
Priority: P2 → --
QA Contact: esther → mime
Whiteboard: [adt3]
Target Milestone: mozilla1.2alpha → ---
Duplicate of this bug: 441275
Duplicate of this bug: 442491
Product: Core → MailNews Core
Perhaps also, the inclusion of bug 80713 will mean that we can actually have separate documents via iframes.  
Duplicate of this bug: 400903
Duplicate of this bug: 76804
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.
I think the component is correct: the bug is in mailnews code, in the way we build an HTML representation of the rfc822 document.
Depends on: 82280
Duplicate of this bug: 736075
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.
Summary: Send Page received with added text in color. → With "Display attachments inline": Body background & CSS styles of attached or main HTML part leak into other attached or main message parts (wrong bgcolor/bg-images/unclosed tags...-> unreadable text/bad behaviour) [multipart/mime, iframe send web page]
Depends on: 341059
Duplicate of this bug: 222892
Duplicate of this bug: 292336
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.
Depends on: 80713
Attachment #6289 - Attachment description: Message that produce the problem → Testcase 1: Message that produces the problem
Attachment #6289 - Attachment mime type: text/plain → message/rfc822
Attachment #6289 - Attachment filename: rfc822_message.txt → rfc822_message.eml
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.
Duplicate of this bug: 525011
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").
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.
That should have been *main* part (not "mail"). I should proofread my bug comments better, sorry.
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.
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?
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.)
(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.
(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.
Duplicate of this bug: 656802
Duplicate of this bug: 596848
Duplicate of this bug: 223364
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.
Summary: With "Display attachments inline": Body background & CSS styles of attached or main HTML part leak into other attached or main message parts (wrong bgcolor/bg-images/unclosed tags...-> unreadable text/bad behaviour) [multipart/mime, iframe → Display attachments inline: Body attributes (background, CSS styles, dir="rtl"...) of attached or main HTML part leak into other attached or main message parts (wrong bgcolor/bg-images/unclosed tags...-> unreadable) [multipart/mime, iframe
(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.
Duplicate of this bug: 121878
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. ;)
Duplicate of this bug: 186316
Duplicate of this bug: 221559
Depends on: 227872
Summary: Display attachments inline: Body attributes (background, CSS styles, dir="rtl"...) of attached or main HTML part leak into other attached or main message parts (wrong bgcolor/bg-images/unclosed tags...-> unreadable) [multipart/mime, iframe, send web page] → 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)
Duplicate of this bug: 741696
Duplicate of this bug: 1229108
Duplicate of this bug: 1297653
Duplicate of this bug: 1363404
Duplicate of this bug: 1593208
You need to log in before you can comment on or make changes to this bug.