The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla1.9.1b2

Status

()

Toolkit
Themes
--
minor
RESOLVED FIXED
15 years ago
8 years ago

People

(Reporter: Matthew Paul Thomas, Assigned: dao)

Tracking

Trunk
mozilla1.9.1b2
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

444 bytes, patch
neil@parkwaycc.co.uk
: review+
Details | Diff | Splinter Review
(Reporter)

Description

15 years ago
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 ?
(Reporter)

Comment 2

13 years ago
(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.

Updated

9 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: shrir → xptoolkit.widgets
(Assignee)

Updated

9 years ago
Assignee: hyatt → dao
Component: XUL → Themes
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → themes
(Assignee)

Comment 3

9 years ago
Created attachment 342041 [details] [diff] [review]
patch
Attachment #342041 - Flags: review?(enndeakin)
(Assignee)

Updated

9 years ago
Attachment #342041 - Flags: review?(enndeakin) → review?(neil)

Updated

9 years ago
Attachment #342041 - Flags: review?(neil) → review-

Comment 4

9 years ago
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.
(Assignee)

Comment 5

9 years ago
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)
(Assignee)

Updated

9 years ago
Attachment #342041 - Flags: review?(neil)

Comment 6

9 years ago
(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.

Updated

9 years ago
Attachment #342041 - Flags: review+
(Assignee)

Comment 7

9 years ago
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: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b2

Updated

9 years ago
Depends on: 461650
You need to log in before you can comment on or make changes to this bug.