maybe regression by bug 538187 and/or bug 508482

The menus are greyed out on startup using the default theme. Mousing over them will put them back into the normal state.

Customize Toolbar and Done, make them into the normal state

Yes Alice that is true, but you have to do it everytime you restart Minefield.

Also, the menu bar is not highlighted ever with any other theme.

This just showed up in shredder too. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100322 Shredder/3.2a1pre

I'm not sure what to do here. We don't restyle the document because HasDocumentStateDependentStyle doesn't find the :-moz-window-inactive rule because it's in an XBL stylesheet. For normal content state changes we can inspect XBL stylesheets because we can get the binding from the content node (in nsBindingManager::WalkRules), but when the document state changes we only have the root node and no way of getting to the right binding. Does this mean we'll have to iterate over the whole content tree whenever the document state changes?

I think this is toolkit bug. (and also in seamonkey 2.1 nightlies)

View Source window is also affected and exhibits the same behavior.

(In reply to comment #6) > I'm not sure what to do here. We don't restyle the document because > HasDocumentStateDependentStyle doesn't find the :-moz-window-inactive rule > because it's in an XBL stylesheet. For normal content state changes we can > inspect XBL stylesheets because we can get the binding from the content node > (in nsBindingManager::WalkRules), but when the document state changes we only > have the root node and no way of getting to the right binding. > > Does this mean we'll have to iterate over the whole content tree whenever the > document state changes? It seems like we'd only have to iterate over all XBL binding style sheets in the document... and that the binding manager itself could coalesce all the document state bits into one for all of them. We'd probably need a different WalkRuleProcessors mechanism to do this, though.

As i noted in bug 554574, the gray text only changes permanently to black if the window is in the foreground. if you have two windows and the one in the background has its menu mouse-over'd it will go back to gray

Comment on attachment 434724 [details] [diff] [review] v1 r=dbaron

Darn, I was hoping this would fix the problem with themes other than default, but it does not. Any chance of that happening or do all the themes need to be changed?

All themes need to be changed. Sorry for that.

(In reply to comment #17) > All themes need to be changed. Sorry for that. Something we should mention on MDC, or?

Bug 508482 needs to be documented, not this bug, as far as I can see.

(In reply to comment #5) > This just showed up in shredder too. Verified fixed in Shredder 3.2a1pre and SeaMonkey 2.1a1pre nightly builds. [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100326 SeaMonkey/2.1a1pre]