441275 - CSS styles in attached or main HTML leak into other attached or main message parts

Status: RESOLVED DUPLICATE of bug 31052

(Thunderbird :: Mail Window Front End, defect)

Description

[Sebastian Lisken]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: 2.0.0.14 (20080421)

When attachments are displayed inline in a message window, CSS changes made in one HTML part - an attached file or the main text - leak into the other parts of the message window, including the main window. This can cause all sorts of unwanted changes, including parts becoming unreadable if an attached HTML file sets its background colour to black.

Reproducible: Always

Steps to Reproduce:
1. Have Thunderbird set to displaying attachments inline.
2. Compose or receive a (plain-text or HTML message with attached HTML files that contain "global" styles, e.g. affecting the body tag. Or compose a HTML mail containing such styles, and attach either a HTML or text file.
3. View the message
Actual Results:  
Styles in one part affect the whole content of the message window.

Expected Results:  
All parts are displayed in some kind of "sandbox" (i.e. an invisible iframe) that causes styles in one part to only affect that one part.

Comment 1

[Sebastian Lisken]

Attachment: saved message

This saved message has a plain-text main part, one attachment with a style setting the body tag to yellow background and bold text, and one with a style setting the body tag to grey background and italics text. As a result, the whole message has a grey background and bold, italics text.

Comment 2

[Joe Sabash [:JoeS1]]

When viewing attachments "inline" there is only one "body" therefore the last body style will be applied. Arguably, stylesheets should be ignored in the body and only appied if they are in the head section, but in this case they are in fact included in the head section of the attachments.
A simple workaround is to set View..Message body to...simple html
and open the attachments separately if desired.

IMO this bug should be marked as INVALID

 

Comment 3

[Sebastian Lisken]

I struggle to find any kind of point in that previous comment. It gives a vague (and somewhat obvious) analysis of the problem, then advocates for a questionable distinction (stylesheets in the body are just as valid as in the head, so TB should not change behaviour there) that is completely irrelevant to the problem (as admitter later), then goes on to mention an unsatisfactory workaround that many people will not want to use or know about. All this certainly provides no argument whatsoever for marking this bug as invalid.

Comment 4

[Joe Sabash [:JoeS1]]

When you choose Display attachment inline, the attachments are displayed as part of the same document. The first attachment sets the body style
body {
  background: yellow;
  font-weight: bold;
}
The second attachment then sets:
body {
  background: grey;
  font-style: italic;
}
There is only one document body, so this leaves the body background set to grey

This is as expected, no bug.
If you think thunderbird should handle styles in inline attachments differently, then file a request for enhancement.
It sounds like a good idea for tb to handle styles uniquely for each part of a multipart message, so I would probably vote for it.

in the meantime, marked INVALID

Comment 5

[Sebastian Lisken]

Like I said before, the explanation is obvious. But it starts from a false premise: Viewing attachments inline does not have to imply being in the same HTML document. IFRAMEs are one example where the same window features more than one document. The current state in which the attachments and the main part indeed share the same HTML document is *not* something users would expect or even care about. What they do expect or care about, I'd say, is a view in which one part does not interfere with others. The fact that TB does not behave in this way is a bug. Because styles can actually hide text (e.g. by setting the background to black, the main part is hidden) might even make this a security issue.

In other words, this bug needs to be reopened.

Comment 6

[Joshua Cranmer [:jcranmer]]

(In reply to comment #5)
> Like I said before, the explanation is obvious. But it starts from a false
> premise: Viewing attachments inline does not have to imply being in the same
> HTML document.

You want to pick nits? How about this: inline, to my mind, implies a continuation of running documents, running together fragments because a single part cannot have multiple MIME-types. That's the very definition of inline: it's shown /in line/ with the other text.

> IFRAMEs are one example where the same window features more than
> one document.

Frames are the only examples [1] where this happens. If you want multiple documents to be shown in the same screen but not interacting with each other... use frames.

> The current state in which the attachments and the main part
> indeed share the same HTML document is *not* something users would expect or
> even care about.

To most users, the only things that matter or whether or not attachments are involved. There is only the "message" and the "attachments." I think a user would like far more to see that the styles all combine together rather than seeing interlacing flashes of a myriad of backgrounds.

> What they do expect or care about, I'd say, is a view in which
> one part does not interfere with others.

You may think in parts. I may think in parts. Most users don't. All they see is a message. A message which seems to them as one part.

I think the idea of continuity in presentation here matters more than author-specified decisions. Especially since the workaround is of brain-dead simplicity: change the HTML in your message.

> The fact that TB does not behave in
> this way is a bug. Because styles can actually hide text (e.g. by setting the
> background to black, the main part is hidden) might even make this a security
> issue.

Issues:
1. One can always disable HTML.
2. One can always disable seeing inline.
3. To implement this change is, as a understate, a very non-trivial task involving several hacks.
4. There are workarounds, and none that are very difficult.
5. Inline attachments are displayed as one unit, and theoretically should be styled as such.
6. The case of an inline HTML attachment is already uncommon to begin with, followed with the basic notion of a styled inline attachment.

In short, this is a high-risk, low-value bug. I see no compelling use case.

My recommendation is to RESO INVALID. CC'ing resident UX expert for his say, which I think is sufficiently final for all invalid. Clark?

Comment 7

[Joshua Cranmer [:jcranmer]]

(In reply to comment #6)
> which I think is sufficiently final for all invalid. Clark?

Sorry, that should be `involved'.

/me wishes for bug 540 yet again.

Comment 8

[rsx11m]

xref bug 148742 and bug 222892.

Comment 9

[Sebastian Lisken]

(in reply to comment #6)
> Frames are the only examples [1] where this happens. If you want multiple
> documents to be shown in the same screen but not interacting with each other...
> use frames.

That's of course true in HTML. I just wasn't sure if there were other means
available within Mozilla's UI structures. I'm a developer, but not a Mozilla
developer.

Your comment contains what seems to me like three ways of saying roughly the
same thing: Users want to see the message with the attachments as a whole
document in which styles in one part SHOULD affect the others. (Let's not pick
nits about "parts" vs "message/attachments", please; all I was trying when I
said "parts" is to have a single term to refer either to the main message or to
any attachments.)

I can't believe you really mean that. For sure there is a separation between
the main message and the other parts. This separation is currently visualised
as a horizontal bar between the parts. Would you propose to remove that? I'm
certain that you'd respond "no". And I'm certain that when users select what TB
calls inline mode, they do not have an intention or even a concept of all the
attachments running together into one (HTML) document. What they do intend to
do is to see as many attachments in the message window as TB is able to display
there - text, HTML, images. If TB could display PDF they'd be happy to see that
too. But I can't believe you're seriously telling me that users want every
separation between the parts to go away.

You suggest that if one part is an HTML document with a grey background and
another is an HTML document with a yellow background, users want to see a
yellow background across the whole window: the two mentioned HTML documents
(one of which explicitly setting a background that is not yellow), the main
text, any attached images. Sorry, that is just ridiculous.

> I think the idea of continuity in presentation here matters more than
> author-specified decisions. Especially since the workaround is of brain-dead
> simplicity: change the HTML in your message.

That is not possible because the HTML is produced by TB by combining the parts
of a message. All I (as the sender of the message) can do is change the HTML
documents I'm sending. That might be possible if they are mine to change. But
if I'm just sending some HTML document for someone to see I don't want to
manipulate it just because I'm expecting the recipient to use TB in inline
mode.

> 1. One can always disable HTML.

I'm thinking of a user that's confused by something like my test message, and
who might not even be aware of the original/simplified/plain modes.

> 2. One can always disable seeing inline.

See previous response. And the user might want to view inline.

> 3. To implement this change is, as a understate, a very non-trivial task
> involving several hacks.

I suspect that this point is the main reason for your reaction. That's fine,
but you shouldn't try to convince yourself that the bug is not a bug.

> 4. There are workarounds, and none that are very difficult.

These would be 1 and 2. But they both cause a loss of desired functionality.

> 5. Inline attachments are displayed as one unit, and theoretically should be
> styled as such.

That to me is a repitition of what you're trying to convince me (or yourself?)
of. I categorically disagree. You're thinking in terms of TB's current
implementation and the name "inline mode". I propose that what users are
looking for is to display as many attachments as possible within the same
window, but do not have a concept of that window being an HTML document, only a
view of the parts within it.

> 6. The case of an inline HTML attachment is already uncommon to begin with,
> followed with the basic notion of a styled inline attachment.

In practice, attaching an HTML document is probably not that uncommon. They are
out there in high number. They are being sent as attachments to emails.

> In short, this is a high-risk, low-value bug. I see no compelling use case.
> 
> My recommendation is to RESO INVALID. CC'ing resident UX expert for his say,
> which I think is sufficiently final for all invalid. Clark?

I'm glad to see this issue being discussed and more people getting involved,
and will not get into a reopening war if you decide to close it, even if the
reasoning I've seen so far is entirely unconvincing to me.

Comment 10

[Joshua Cranmer [:jcranmer]]

(In reply to comment #6)
> Frames are the only examples [1] where this happens. If you want multiple
> documents to be shown in the same screen but not interacting with each other...
> use frames.

Forgot the key part:
[1] Actually, if you consider the stratification between SVGDocument and whatnot, and include XHTML sources, I believe one can fudge a document in more arbitrary places. But I am not an expert on content...

Anyways:

(In reply to comment #9)
> Your comment contains what seems to me like three ways of saying roughly the
> same thing: Users want to see the message with the attachments as a whole
> document in which styles in one part SHOULD affect the others.

What I'm saying, to be put better, is that authors SHOULD NOT (in an RFC 2119 sense) expect inline-disposed parts to not have an affect on each other.

> I can't believe you really mean that. For sure there is a separation between
> the main message and the other parts.

I do. Inline means everything is run together.

> You suggest that if one part is an HTML document with a grey background and
> another is an HTML document with a yellow background, users want to see a
> yellow background across the whole window: the two mentioned HTML documents
> (one of which explicitly setting a background that is not yellow), the main
> text, any attached images. Sorry, that is just ridiculous.

Your alternative: a striped message with a block of grey followed by a block of yellow. That, IMO is even worse.

> I suspect that this point is the main reason for your reaction. That's fine,
> but you shouldn't try to convince yourself that the bug is not a bug.

Show me, then, that the majority of other email clients implement it the way you describe. Outlook, Mail.App, Evolution, etc. If there is an implied standard among these, and if it is different from Thunderbird's implementation, then it can be called a bug. But if neither is true, then it's hardly a bug if multiple major clients do it in multiple ways. Specs are completely mum on this topic, and so is google searches. I believe inline was originally intended for pictures to be displayed inline, not multiple HTML parts.

> > 4. There are workarounds, and none that are very difficult.
> 
> These would be 1 and 2. But they both cause a loss of desired functionality.

I'm talking about changing styles on messages.

> > 5. Inline attachments are displayed as one unit, and theoretically should be
> > styled as such.
> 
> That to me is a repitition of what you're trying to convince me (or yourself?)

Not repetition, summary. When I write longer posts, I feel the need to summarize.

> I'm glad to see this issue being discussed and more people getting involved,
> and will not get into a reopening war if you decide to close it, even if the
> reasoning I've seen so far is entirely unconvincing to me.

This is not an area in which I have proficient knowledge (indeed, my general response to most UI bugs is to run in the opposite direction), so your quarrel need not lie with me, but with the drivers or UX experts or developers who work on this bug. I myself will probably never see any role in any of these roles, so I must defer to them in decision-making on this bug and only outline my opinions.

Comment 11

[Sebastian Lisken]

(in reply to comment #10)
> What I'm saying, to be put better, is that authors SHOULD NOT (in an RFC 2119
> sense) expect inline-disposed parts to not have an affect on each other.

I don't think it even matters whether the disposition is inline, but whether the TB option "Display Attachments inline" is selected. Which means it's out of message authors' control.

> Inline means everything is run together.

I think you're continuing a basic mistake here: thinking from a developer perspective and in terms of either the current TB option (and its exact name) or the Content-Disposition header. Let's instead try to take a user perspective: what do they expect of an option that says "Display Attachments inline"? Do they base their expectations on the first two words, or on the fairly technical meaning of the last?

If you take that step out of what is a very specific and technical perspective, I am still convinced that the only conclusion one can draw is this: when users are viewing a message with several parts, one of which happens to be a HTHML document setting a font or background colour or whatever for *its* body, it would be very wrong to apply that setting to all parts, some of which may not even be HTML at all. The parts are only combined into one HTML document by Thunderbird. I am saying that the way this combination is performed SHOULD change.

> Your alternative: a striped message with a block of grey followed by a block of
> yellow. That, IMO is even worse.

I don't think so, if the message contains grey-background HTML document followed by a yellow-background HTML document then that is a true representation of the message. And if there's a plain-text main part in front then that should have its white-background "stripe" too. Currently TB inserts a horizontal ruler. Maybe this is an occasion to consider better designed separators between those parts or "stripes", but it is my determined opinion that my test message needs to be displayed basically in that way. It's not an issue of asthetics, but of a faithful representation of what the message contains.

> Show me, then, that the majority of other email clients implement it the way
> you describe. Outlook, Mail.App, Evolution, etc. If there is an implied
> standard among these, and if it is different from Thunderbird's implementation,
> then it can be called a bug. But if neither is true, then it's hardly a bug if
> multiple major clients do it in multiple ways. Specs are completely mum on this
> topic, and so is google searches. I believe inline was originally intended for
> pictures to be displayed inline, not multiple HTML parts.

Yes, I too believe that inline was intended for that. It was probably not thought through what impact attaching a whole HTML would have. Therefore one should be prepared to think outside the box established by the old state of things.

I'd love to give you more input on other mail clients right now as I see that discussion process taking place, but I'm in time zone GMT+2 and need to take several hours off now. I agree that researching other clients would be helpful, and I'm not surprised if there's little to find in the standards because it's a mail agent display issue. Why should the way TB combines several parts, all with their own MIME types, into one HTML document? Here's RFC 2183:
   Two common ways of presenting multipart electronic messages are as a
   main document with a list of separate attachments, and as a single
   document with the various parts expanded (displayed) inline. The
   display of an attachment is generally construed to require positive
   action on the part of the recipient, while inline message components
   are displayed automatically when the message is viewed.
[...]
   A bodypart should be marked `inline' if it is intended to be
   displayed automatically upon display of the message.  Inline
   bodyparts should be presented in the order in which they occur,
   subject to the normal semantics of multipart messages.

That level of specific-ness is all one could expect.

> I'm talking about changing styles on messages.

And I'm talking about composing a plain-text message, innocently attaching a HTML file that happens to set styles on its body, and sending that to an unsuspecting TB user.

> Not repetition, summary. When I write longer posts, I feel the need to
> summarize.

No problem with that. I didn't mean to criticise when I used the word repetition, only to make sure I wasn't missing some new point.

Comment 12

[Joe Sabash [:JoeS1]]

Please see bug 18427 which resulted in the View.."message body as" options.

I agree that an new user might not know what those options do, but that is a matter of "user education" rather than software design.

If the basic method of displaying attachment inline could be improved (and I agree that it could be) then that would be in an enhancement request.

One small part of the problem can be handled through a userContent.css file to force the background color on text divisions to white. This is the part that I will address in a proposed RFE

In the meantime, for your personal use, I've attached a file to this bug that will do the job. Just rename the file to userContent.css and put it into your chrome folder, and all text parts will have a white background.

I'll comment here when that RFE happens, and thanks for your interest in improving TB

Marking INVALID  

Comment 13

[Joe Sabash [:JoeS1]]

Attachment: userContent file

Comment 14

[Magnus Melin [:mkmelin]]

This is bug 31052 (or one of the related bugs discussed there)

Comment 15

[Thomas D. (:thomas8)]

fwiw:

Magnus, thanks for rescuing this bug from its entirely nonsensical invalidations, while duplicates are on the increase.

Sebastian, 100% +1 and thanks for insisting on your valid point with solid arguments, defending common sense user expectations in this bug which exposes a clear case of an ux-implementation-level problem:

> User experience principle: interfaces should not be organized around the
> underlying implementation and technology in ways that are illogical, or require
> the user to have access to additional information that is not found in the
> interface itself.

/shaking-my-head in disbelief...