Build: Mozilla 1.1b (I know it's not a nightly, but if the bug's been fixed since then I'll eat my hat), Windows 98 To reproduce: 1. Place any window in front of a Mozilla browser window. 2. Move/resize the window in front so that the menu bar in the browser window is visible. What you should see: * The menu bar is grayed out, as it would be if it were disabled. What you actually see: * The menu bar appears just as it would if the window was frontmost. Microsoft changed the behavior of native Windows menu bars from Windows 98 onwards, once they discovered that when more than one menu bar was visible, people often went for the wrong one. (Which is one of the reasons why Mac OS has only one menu bar.) This is the Windows equivalent of the Mac's bug 54488 -- they probably depend on the same as-yet-unfiled bug about window controllers or whatever.
This applies to Firefox too - should another bug be filed for firefox? Perhaps it will be obsoleted by bug #243078 ?
(1) No, because having four versions of nearly every open XP Toolkit/Widgets bug report (one for Firefox, one for Thunderbird, one for standalone Composer, and one for the Mozilla suite) would be a waste of time. (2) No, firstly because Windows XP is not the only Win32 platform on which Firefox runs, and secondly because fixing that bug won't fix this one anyway.
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: shrir → xptoolkit.widgets
Assignee: hyatt → dao
Component: XUL → Themes
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → themes
Attachment #342041 - Flags: review?(enndeakin) → review?(neil)
Comment on attachment 342041 [details] [diff] [review] patch 1. This doesn't belong in formatting.css 2. GrayText is the wrong colour; I know because I set to yellow while I was patching bug 69710.
Comment on attachment 342041 [details] [diff] [review] patch Where does it belong if not formatting.css? If you have menu.css in mind, as I had, I don't think |window| can be used there. I don't understand your comment about graytext being the wrong color. Bug 69710 combines two border colors, which makes sense, but a single border color as text color would be wrong (not guaranteed to be visible).
Attachment #342041 - Flags: review- → review?(neil)
(In reply to comment #5) > (From update of attachment 342041 [details] [diff] [review]) > Where does it belong if not formatting.css? If you have menu.css in mind, as I > had, I don't think |window| can be used there. Ah, it turns out that dynamic changes on window don't work, so the rule has to go into formatting.css or global.css [note that the formatting (pun intended) of formatting.css is somewhat wacky]. (Static references are fine though, c.f. menulist > menupopup > menu styles.) > I don't understand your comment about graytext being the wrong color. Bug 69710 > combines two border colors, which makes sense, but a single border color as > text color would be wrong (not guaranteed to be visible). Well, I tried under both the default Windows theme and Windows Standard and they both draw inactive menus using ThreeDShadow [I don't like these all-lowercase colour names], so r=me with that fixed.
I've moved it to global.css and replaced graytext with ThreeDShadow: http://hg.mozilla.org/mozilla-central/rev/607bc6cc1cd3
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2
You need to log in before you can comment on or make changes to this bug.