If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Some author stylesheets ignored



MailNews: Message Display
18 years ago
13 years ago


(Reporter: BenB, Assigned: Alec Flett)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-][nsbeta2-])


(1 attachment)



18 years ago
1. View a msg with an attached msg (e.g. after forward as attachment) in

Actual result:
The headers have no backgournd colors.

Expected result:
mailheader.css is honored, e.g. the headers have a grey background.

Additional comments:
- It works for normal author stylesheets for HTML pages. Rich, do we use the XUL
or HTML emitter for msg display?
- This also makes quotes in plain text msgs look really bad, after bug 31906 is

Comment 1

18 years ago
Sorry, I can't take a bug described so vaguely about a problem at the app level. 

The MailNews folks may tell you what's wrong with that file.

Changing product to MailNews.

Component: Style System → Mail Window Front End
Product: Browser → MailNews

Comment 2

18 years ago
Reassigned to Mail Window Front End.
Assignee: pierre → putterman
QA Contact: ckritzer → lchiang

Comment 3

18 years ago
reassigning to rhp.
Assignee: putterman → rhp

Comment 4

18 years ago
For bugs like this, you have to break it down the the bare root of the problem. 
What I would suggest is that you use the mimetest program on a .EML file and 
generate some HTML for the body. Then, load that into a browser window. If this 
fails, then its a layout issue and should be assigned appropriately. 

- rhp
Assignee: rhp → mozilla

Comment 5

18 years ago
I loaded the mimetest output in the browser and it worked fine. I can think of 3
differences, which could trigger the bug:
- I had to modify the chrome:// stylesheet url to file:///
- Do we output XUL in Mailnews? rhp? I used HTML output for the test (mimetest
gives me only that).
- There could be any weird thing in Mailnews which triggers this.

I see no chance for me to do more to track this bug down. Back to you rhp.

Pierre, the timeframe in which the bug appeared is relatively narrow,
considering that we had very strong checkin rules. Do you have no idea which
change could have caused this?
Assignee: mozilla → rhp

Comment 6

18 years ago
I forgot to mention the timeframe, sorry. It appeared between May 30 and Jun 3.

Comment 7

18 years ago
I just looked over the Mailnews changes in that timeframe
especially the changes to mailnews/base/resources
and the only suspicious change I saw was Ben Goodger's utilOverlay change.

In libmime, there was only the nsAllocator change

Comment 8

18 years ago
I don't think that a change a Style or Network could have caused this: we would 
see the same problem in many other places, I guess.

I don't understand your comments from 2000-06-06 12:29. Do you mean that it 
stopped working ever since you changed the URL from chrome:// to file://? In that 
case, I'd say: No wonder!

Comment 9

18 years ago
HREF="chrome://messenger/skin/mailheader.css">|. This won't work anyway, if I
load it into the browser, due to the access rights, right? So, I changed it into
a working file:// url and the stylesheet is used.

Comment 10

18 years ago
to make it clear: I changed it into a file url in the html file I loaded into
the browser for testing. Mailnews loads the chrome url.

Comment 11

18 years ago
Changing qa assigned to pmock@netscape.com
QA Contact: lchiang → pmock
Just so it's in here:

The fix for bug 31906 has finally been checked in, which unfortunately
exposes bug 41637 <http://bugzilla.mozilla.org/show_bug.cgi?id=41637>
very visibly: quotes in plain text msgs (e.g. as sent by 4.x) have a
blue bar *and* ">"s in front of them.

As a workaround use the rules from mailheader.css in your user
stylesheet. To do that, copy
|<mozdir>/bin/chrome/skins/modern/messenger/skin/mailheader.css| to
|<profiledir>/chrome/user.css|. You might have to create the |chrome|
dir. If you already have a |user.css|, just copy the content of
|mailheader.css| over there.

BTW: I'll post some info about bug 31906 later. For now, see

Comment 13

18 years ago
*** Bug 41997 has been marked as a duplicate of this bug. ***

Comment 14

18 years ago
Created attachment 9866 [details]
sample screenshot - quotes without workaround

Comment 15

18 years ago
nsbeta2 nomination. Attached a sample screenshot of a plaintext msg (doesn't
happen for HTML or flowed).
Keywords: nsbeta2

Comment 16

18 years ago
Putting on [nsbeta2-] radar. Bigger fish to fry.....
Whiteboard: [nsbeta2-]

Comment 17

18 years ago
The workaround causes the OK and Cancel buttons in dialog wondows unclickable.  
Clicking them works like clicking a scroll bar. There is no way to bypass it once 
the dialog is displayed, the only solution being force quit.  The dimention of 
the dialog window as well as that of download window seem wrong after the 
workaround.  I write this as a precaution not to introduce another bug while 
working on a fix.  2000060908-M17 for MacOS


18 years ago
Target Milestone: --- → M18

Comment 18

18 years ago
hirata, thanks for the hint! I also saw this, but didn't know what caused it.
Delete all rules above the "body" rule and it will go away. The workaround for
the quotes will still work, but not for attached msgs.

Comment 19

18 years ago
*** Bug 42607 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
PDT, there are "smaller fishes" [nsbeta2+]. This bug messes up the display of
*all* (non-flowed) plain text msgs with quotes. How do you want to get people
(NS6PR2 users, *we* have a workaround) use a mailer that displays *most* msgs
like in the attached screenshot? Removing [nsbeta-] for reevaluation.

I also don't think, this is rhp's bug.
Whiteboard: [nsbeta2-]

Comment 21

18 years ago
Putting on [nsbeta2+] radar for beta2 fix. Who should get this bug?!
Whiteboard: [nsbeta2+]

Comment 22

18 years ago
I don't know, but rhp didn't check in anything in the relevant timeframe.

BTW: I also didn't find any suspicious changes to xul or css files in Mailnews
in this timeframe

Comment 23

18 years ago
>I also don't think, this is rhp's bug.
Ben, whose bug do you think it is? You originally assigned it to the Style System 
and I explained my position. Have you done any more research, like a testcase, 
that would give us a better idea of where the problem lies? For now, it is still 
in the hand of the MailNews team and they are the most appropriate guys to dig 
into it.

Comment 24

18 years ago
After a note on from kin .editor, I hack the emitters (mailnews/mimem/emitters)
to output a file URL instead of chrome, and the bug still appears. If I take the
output of |mimetest <msg> 2| a testtool, write it to a HTML file and load that
in the browser, it works, i.e. the stylesheet is used.

Comment 25

18 years ago
bryner found out using a brute binary search (thanks!) that the bug appeared
sometime Jun 1.

Comment 26

18 years ago
Check out the changes to MailNews at Jun 1
- nothing suspicious. So, this is most likely a Gecko problem.

Comment 27

18 years ago
Lokking over the layout changes
a checkin from mstoltz
looks suspicious. REASSIGNing to him to check.
Assignee: rhp → mstoltz

Comment 28

18 years ago
I guess, the stylesheet isn't loaded, because it's loaded via <link> from
anonymous (at least, that's what the msg should be) content using a chrome URL.
See bug 16858.

Maybe we should cascade the stylesheet in? REASSIGNing to alecf.
Assignee: mstoltz → alecf

Comment 29

18 years ago
I'm so lost as to what the actual bug is.
is a CSS file not loading?
what CSS file?
This sounds like it *could* be a security issue.  cc:ing mstoltz.

Comment 31

18 years ago
dbaron, read up :).

as for the symptoms, see the inital description plus the screenshot attached
(both show different ones).
The reason is that mailheaders.css is not loaded. A <link> reference to it is
written into the libmime output in the MIME emitters in mailnews/mime/emitters/.
It might be better to reference this stylesheet anywhere in chrome (for perf
reasons near the msg pane) and to remove the direct reference from libmime.

Comment 32

18 years ago
removing nsbeta2+ and asking for consideration to cut from beta2.  We don't
think the side effect as shown in the screen shot needs to be fixed for this beta.
Whiteboard: [nsbeta2+]

Comment 33

18 years ago
To PDT: Problem understood. We just need to load the stylesheet in another

Comment 34

18 years ago
problem understood, but fix completely unknown. I have no idea how to load a 
stylesheet into a document, and no idea who to ask for help.

Comment 35

18 years ago
> I have no idea how to load a stylesheet into a document

Doesn't the cascade help? I.e. just load the stylesheet for the Docshell (or
however it is called) around the docshell for the msg, and the msg /should/
"inherit" it.

> and no idea who to ask for help.

Somebody from the browser? They load html.css. If everything breaks, pierre or
somembody else from Gecko.

Comment 36

18 years ago
> and the msg /should/ "inherit" it.

Or not? :(

Comment 37

18 years ago
From alecf:
>I have no idea how to load a stylesheet into a document, 

In HTML or C++?... You don't know how to make a HTML page use a particular 
stylesheet? Or you don't know how to load a nsIStyleSheet and then attach it to a 

Comment 38

18 years ago
C++ or JS, I don't think it matters. Ben? What document am I loading this into?

Comment 39

18 years ago
The problem *is*, that we are loading the stylesheet in the HTML file. libmime
emits HTML for each msg in order to display it, and it currently writes a |<LINK
REL="IMPORTANT STYLESHEET" HREF="chrome://messenger/skin/mailheader.css">| in
the emitted HTML. But the URL loading the msg is a "imap_something" or
"pop_something" or "whateveraccessmethod_something". So, the security system
won't allow the resulting HTML to load a chrome URL. That's completely OK, since
we cannot trust the msg content (it might be a HTML mail).

So, we need any way to load the stylesheet from the chrome (i.e. anything that
is loaded via a "chrome" URL).


18 years ago
Whiteboard: [nsbeta2-]

Comment 40

18 years ago
Putting on [nsbeta2-] radar per putterman's comments 7/5. Not critical to beta2. 

Comment 41

18 years ago
nsbeta3 nomination.
Keywords: correctness, nsbeta3

Comment 42

18 years ago
Ben Bucksch, AlecF: is it a dup of bug 44285?

Ben, you wrote that "the security system won't allow the resulting HTML to load a 
chrome URL". Where does it take place? While investigating bug 44285, I saw that 
the security manager doesn't object loading the stylesheet, or at least not in 

Comment 43

18 years ago
> is it a dup of bug 44285?

Could well be, but I don't know. Not enough info (both about the bug and Mozilla
:) ).

> "the security system won't allow the resulting HTML to load a 
> chrome URL". Where does it take place?


> While investigating bug 44285, I saw that 
> the security manager doesn't object loading the stylesheet, or at least not in 
> CSSLoaderImpl::LoadStyleLink().

I don't know it for sure, it was just a guess (but a relatively safe one,
considering that the bug appeared the same day as the checkin). to know it for
sure, somebody could undo the checkin refered to above and check, if the bug

Comment 44

18 years ago
*** Bug 43078 has been marked as a duplicate of this bug. ***

Comment 45

18 years ago
The URL is for the missing newlines in a signature (from bug 43078)

Comment 46

18 years ago


18 years ago
Blocks: 40113

Comment 47

18 years ago
Adding mscott & hyatt to cc list.  Can either of you recommend a way to get 
mailheader.css loaded in one of our chrome URLs such that it affects the message 
view layout?  Are there other ways to avoid the security problem of loading this 
css in the message's html?

Comment 48

18 years ago
*** Bug 40113 has been marked as a duplicate of this bug. ***


18 years ago
No longer blocks: 40113

Comment 49

18 years ago
Adding mail2 nomination keyword for triage effort.
Keywords: mail2

Comment 50

17 years ago
- per mail triage. 
Whiteboard: [nsbeta2-] → [nsbeta3-][nsbeta2-]

Comment 51

17 years ago
I strongly disagree. Please see the screenshot. Without the workaround, quotes
in plaintext (which are *very* usual, I guess they happen in very third mail or
so) at the very least look bad. Signatures are also messed up completely. If we
didn't have the workaround, I'd even argue, this were dogfood. Don't tell me, we
can ship with that bug.

Comment 52

17 years ago
if you want to spend the time to fix the bug, then please take it

Comment 53

17 years ago
I don't understand what the difficulty in this bug is. What css-file is used to 
style the mail window? What happens if one includes (@import or whatever) 
mail-header.css there?

Comment 54

17 years ago
Daniel, I think this would be messenger.css. This would not be a good idea for
performance reasons. The rules in mailheader.css are not very fast to evaluate,
and using them for all of Messenger would propably slow things down, e.g. the
thread pane.

Comment 55

17 years ago
It's too bad if we couldn't find a good solution since much of the work Ben has 
done and possibilites he has created won't be seen and it causes quite a lot of 
other bugs since the output from mime heavily depends on those style sheets. 

Now, I'm in no way any expert on css performance wise. I guess that it would be 
hyatt who could give most information on that, but some of the rules in 
mailheader.css doesn't look too bad for me. If we cleaned it up and made the 
rules as specific as possible (if they are not already), do you think that 
would help, Ben?

Then there in one more thing I'm wonderign. I see rules in the mailheader.css 
file that applies solely to the "mail header" and the mail header seems to 
work. Do that mean that this style sheet is applied for the mail header in some 
way but not for the mail content?

Comment 56

17 years ago
Daniel, thanks for your attribution! And thanks for caring about this bug. I am
also completely puzzled, why this bug is minused. Fixing it is propably a matter
of a one-line change (and finding out that line, of course). I can only guess,
the "mail triage team" thinks, I will fix this bug anyway. I not sure, I would
like that strategy.

> Now, I'm in no way any expert on css performance wise.

All I know comes from <http://www.mozilla.org/xpfe/goodcss.html>. It is pretty
comprehensive, so I don't think, hyatt could add much to that.

> If we cleaned it up and made the rules as specific as possible (if they are
> not already), do you think that would help, Ben?

No, to make them faster, we'd have to mess up the C++ source completely, and I'm
not willing to do that. Even then, they would still slow things down (not sure
how much, however), if included in messenger.css.

> I see rules in the mailheader.css file that applies solely to the "mail
> header"

They are intended for the case, an attached rfc822 message is displayed (e.g.
for forwarded msgs). The header *section* uses different ones.

Comment 57

17 years ago
like other nsbeta2- bugs, this was minused because netscape feels that it's 
resources could be better allocated on other bugs. It doesn't mean that this bug 
can't be fixed. If it's really this simple, then submit a patch.
Target Milestone: M18 → Future


17 years ago
Blocks: 18427

Comment 58

17 years ago
I don't see this bug anymore. Removed my user stylesheet, but everything still
looks OK. Can somebody please verify?

Did anybody silently fix this bug? :) mstoltz, did you change the security
stuff? Did it break? :(

Comment 59

17 years ago
Be sure not to have the workaround mentioned here enabled while testing.
Keywords: qawanted

Comment 60

17 years ago
Yes, indeed, it works again, but only because the change which initially caused
this bug has practically been undone for bug 41876. I am not sure, this will
stay that way, so I'm leaving this bug open for now.
Keywords: qawanted
What's the issue? Ben, bug 41876 was about remote files not being able to load 
chrone:// style tags. This is now allowed; all remote content can access chrome. 
This is permanent, and if it fixes this bug, then please close it. I'm unclear 
from your comments whether the bug is fixed or some problem remains.

Comment 62

17 years ago
OK, closing as fixed per mstoltz comment. We can still REOPENen, if necessary.
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 63

17 years ago
Verified as fixed on win32, linux, and macos using the following builds:
 win32 commercial seamonkey build 2000-092909-mn6 installed on P500 Win98
 linux commercial seamonkey build 2000-092909-mn6 installed on P200 RedHat 6.2
 macos commercial seamonkey build 2000-092911-mn6 installed on G3/400 OS 9.04
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.