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: