164608 - Menu bars in background windows should be grayed out (disabled appearance)

Status: RESOLVED FIXED

(Toolkit :: Themes, defect)

Description

[Matthew T (active 1999-2002)]

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.

Comment 1

[Steven Garrity [:sgarrity]]

This applies to Firefox too - should another bug be filed for firefox? Perhaps
it will be obsoleted by bug #243078 ?

Comment 2

[Matthew T (active 1999-2002)]

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

Comment 3

[Dão Gottwald [:dao]]

Attachment: patch

Comment 4

[[e-mail]]

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 5

[Dão Gottwald [:dao]]

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

Comment 6

[[e-mail]]

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

Comment 7

[Dão Gottwald [:dao]]

I've moved it to global.css and replaced graytext with ThreeDShadow:

http://hg.mozilla.org/mozilla-central/rev/607bc6cc1cd3