Closed Bug 488697 Opened 15 years ago Closed 15 years ago

SMIMEOverlay CSS shouldn't be reimporting messenger.css

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b3

People

(Reporter: philor, Assigned: philor)

References

Details

Attachments

(1 file)

Attached patch Remove 'emSplinter Review
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).
Attachment #373141 - Flags: review?(jminta)
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.
Attachment #373141 - Flags: review?(jminta) → review+
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.
http://hg.mozilla.org/comm-central/rev/cab8bae24e19
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: