I always wondered where these came from... STR: 1. Open DOMi, inspect a 3pane chrome, find an element that's styled from messenger.css, like the throbber, or indirectly the quick-search-button, which gets styled by content/messenger.css which is imported by skin/messenger.css. 2. Look at the "CSS Style Rules" page for the element 3. Note that the same rule from messenger.css is listed three times. The theory behind messenger.css is that every window has its CSS file which is included in the XUL, like msgReadSecurityInfo.xul includes msgReadSecurityInfo.css, and then that CSS file imports skin/messenger.css which imports skin/global.css and content/messenger.css, giving everything those CSS files that should always be present. Where it fell down was when SMIME cargo-culted it, and put the @import in its *SMIMEOverlay.css sheets: as the name says, those are applied to overlays, which are then overlaid on windows which already have their own @import, and fun ensues when you try to override something from the first import, but do it in a place that comes before the second (and third, if you're in a message window and not compose).

Comment on attachment 373141 [details] [diff] [review] Remove 'em Did you check customize-toolbar stuff? The pathological use of an "overlay" css directly in a window (and an "extension's" overlay at that) makes me nervous. http://mxr.mozilla.org/comm-central/source/mail/base/content/customizeToolbarSheet.xul#53 r=jminta with that sorted out.

Heh. I don't remember whether that was actually required in the 1.8 days, or I just didn't know what on earth I was doing, but at the moment that stuff's all double-applied (at least: some parts are actually applied more like four times, sometime intentionally and sometimes not), since it's all in % style rules in jar.mn too, and we package customizeToolbarSheet.xul as customizeToolbar.xul, so they apply to it. Luckily, it doesn't matter, since I've got a patch in bug 489047 that will remove every trace of my shame. And surprisingly enough, using an "extension's" overlay isn't one of the problems that building with --disable-crypto causes: we blow up and toast startup trying to prompt for the master password, and blow up a few more times in loginmanager code, but customizing compose is perfectly happy not to find the stylesheet to apply to the button that isn't there anyway.