User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081002 Minefield/3.1b1pre Follow-up to bug 54488. When clicking on the help menu, or menus on the right side of the menu bar (non-Firefox menus) or clicking on stacks in the dock, the Firefox window remains in focus as expected but the window scrollbar and form widgets on the page are grayed until the help menu or stack is closed. Reproducible: Always Steps to Reproduce: 1. Click on the help menu, or a menu on the right-hand side of the menu bar, or expand a stack on the dock 2. Observe the scrollbar and form widgets on the page 3. Close the help menu or stack Actual Results: Form widgets and scrollbar become grayed until the menu or stack is closed. Expected Results: Form widgets and scrollbar do not become grayed since the window is still in focus. I don't know if there is any other way to cause this but the bottom line of course is that the widgets should stay active as long as the window is in focus. This happens also on widgets in the preferences window and other dialogs. I am testing on 10.5. I am unable to confirm whether this happens on 10.4.

The help menu doesn't exhibit this behavior on 10.4, but everything else you list does (the apple menu doesn't exhibit it either, for a data point).

The window's key state is apparently not the right criterion for its control tint. Now I'm checking for the window's main state instead, but still set the clear tint when a sheet is open. There are two things that could be done better here: - Popup windows (e.g. the toolbar customization panel) should only get the active look when their parent top level window is main. Steven, is there a way of getting to the top level window? - Opening the Dock menu while a sheet is open breaks everything, but that's a known fundamental problem (see also bug 428071).

Markus, I'm starting to review your patch (and will probably do some testing). But I've already noticed something odd: This bug *doesn't* happen in Firefox 3.0.3, even on OS X 10.5.5. Do you know why?

(In reply to comment #2) > Steven, is there a way of getting to the top level window? The following should work (with a PopupWindow object that's visible): Keep calling [PopupWindow parentWindow] until you get something that isn't a PopupWindow object (and that is ToolbarWindow object or perhaps a BorderlessWindow object). You'll need to confirm this by trial and error, though. The reason this works (if it does work) is that nsCocoaWindow::Show() makes a popup window a child of its (native) parent window (by calling [NSWindow addChildWindow:]) when it "shows" the corresponding nsCocoaWindow. Note that nsCocoaWindow::Show() calls [NSWindow removeChildWindow:] when it "hides" a popup window.

Comment on attachment 341608 [details] [diff] [review] patch v1 I've tested this patch (on OS X 10.5.5) and found that it fixes this bug. And the patch makes sense ... as far as it goes. But you probably want to try out my suggestion from comment #4.

(In reply to comment #4) Thanks, that works. But now I have a different problem: the panel isn't redrawn when its parent window's focus changes, so getting the check right wouldn't have any effect. But I don't think controls in panels are used very often (apart from the toolbar customization palette), so they're probably not worth the effort. I think we should just take this patch as-is and think about panels in a new bug if we really want it.

Comment on attachment 341608 [details] [diff] [review] patch v1 a191=beltzner

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Shiretoko/3.1b3pre ID:20081204020603 Would even be great to have a test in Litmus.

It has been already verified on Dec, 06th last year. Setting flag.

Added to Litmus: https://litmus.mozilla.org/show_test.cgi?id=7465