Closed Bug 41637 Opened 24 years ago Closed 24 years ago

Some author stylesheets ignored

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Future

People

(Reporter: BenB, Assigned: alecf)

References

Details

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

Attachments

(1 file)

sample screenshot - quotes without workaround
4.31 KB, image/png
Details 
Reproduce:
1. View a msg with an attached msg (e.g. after forward as attachment) in
Mailnews.

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
fixed.
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
Reassigned to Mail Window Front End.
Assignee: pierre → putterman
QA Contact: ckritzer → lchiang
reassigning to rhp.
Assignee: putterman → rhp
Ben,
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
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
I forgot to mention the timeframe, sorry. It appeared between May 30 and Jun 3.
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!

libmime outputs |<LINK REL="IMPORTANT STYLESHEET"
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.
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.
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
<http://www.bucksch.org/1/projects/mozilla/31906>.
*** Bug 41997 has been marked as a duplicate of this bug. ***
nsbeta2 nomination. Attached a sample screenshot of a plaintext msg (doesn't
happen for HTML or flowed).
Keywords: nsbeta2
Putting on [nsbeta2-] radar. Bigger fish to fry.....
Whiteboard: [nsbeta2-]
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
Status: NEW → ASSIGNED
Target Milestone: --- → M18
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.
*** Bug 42607 has been marked as a duplicate of this bug. ***
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-]
Putting on [nsbeta2+] radar for beta2 fix. Who should get this bug?!
Whiteboard: [nsbeta2+]
>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.

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.
bryner found out using a brute binary search (thanks!) that the bug appeared
sometime Jun 1.
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
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.
dbaron, read up :).

alecf,
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.
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+]
To PDT: Problem understood. We just need to load the stylesheet in another
place.
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.
> 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.
> and the msg /should/ "inherit" it.

Or not? :(
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 
nsIDocument?

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

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).
Whiteboard: [nsbeta2-]
Putting on [nsbeta2-] radar per putterman's comments 7/5. Not critical to beta2. 
nsbeta3 nomination.
Keywords: correctness, nsbeta3
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 
CSSLoaderImpl::LoadStyleLink().

> 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?

<http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/layout/html/style/src&command=DIFF_FRAMESET&file=nsCSSLoader.cpp&rev1=3.48&rev2=3.49&root=/cvsroot>

> 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
disappears.
*** Bug 43078 has been marked as a duplicate of this bug. ***
The URL is for the missing newlines in a signature (from bug 43078)
URL: news://news.mozilla.org/394E871C.A14D...
Blocks: 40113
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?
*** Bug 40113 has been marked as a duplicate of this bug. ***
No longer blocks: 40113
Adding mail2 nomination keyword for triage effort.
Keywords: mail2
- per mail triage.
Whiteboard: [nsbeta2-] → [nsbeta3-][nsbeta2-]
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.
if you want to spend the time to fix the bug, then please take it
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?

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.
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?

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.
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.
Status: NEW → ASSIGNED
Target Milestone: M18 → Future
Blocks: 18427
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? :(
Be sure not to have the workaround mentioned here enabled while testing.
Keywords: qawanted
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.

OK, closing as fixed per mstoltz comment. We can still REOPENen, if necessary.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: