This is gnome specific, mousing over the menubar shouldn't activate the menus. patch coming

test if the menubar is active. if it isn't, then do nothing.

Are you referring to the "hover" effect?

(In reply to comment #2) > Are you referring to the "hover" effect? Yes

Comment on attachment 140727 [details] [diff] [review] patch v1.0 KDE has the same behavior as Windows. Menus react to the mouse. so this patch should read as: -#if defined(XP_UNIX) && !defined(XP_MACOSX) +#if defined(MOZ_WIDGET_GTK) || defined(MOZ_WIDGET_GTK2)

forgot to cc reviewers

(In reply to comment #4) > (From update of attachment 140727 [details] [diff] [review]) > KDE has the same behavior as Windows. Menus react to the mouse. > so this patch should read as: > -#if defined(XP_UNIX) && !defined(XP_MACOSX) > +#if defined(MOZ_WIDGET_GTK) || defined(MOZ_WIDGET_GTK2) Mozilla uses GTK, even under KDE (there is not QT Mozilla). The other widget set Mozilla supports is Xlib.

(In reply to comment #6) > Mozilla uses GTK, even under KDE (there is not QT Mozilla). The other widget > set Mozilla supports is Xlib. sure, but if someone wants to port mozilla to another widgetry, finding gtk specific code will be easier.

Comment on attachment 140727 [details] [diff] [review] patch v1.0 Clearing reviews, I found a glitch with patch: when a dialog is opened via a menuitem command, the menubar menu won't open when it is clicked on. It will only open the second time. This code is so fragile...

This doesn't change the menu code; instead it only sets inHover on toplevel menus if they are actually open.

Comment on attachment 143094 [details] [diff] [review] how about this I did sth similar, but I changed my mind thinking that the above patch was working. I won't have time in the foreseeable future (some weeks) to fix the bugs in the menu code (bookmarksMenu.js is full of crappy workarounds). So yeah, let's get that in.

checked in.

reopening to cover fixing the text color.

In theory, this css rule to set the text color to HighlightText will apply in all the same cases that we draw the highlight on the menu background. Note that I moved the highlight rule before the disabled rule so that the disabled rule would take prescedence, and then I special cased menubar > menu so that HighlightText is only used when the menu is open.

I checked this in with roc's sr. pch, feel free to add review comments.

It seems that the highlight (blue when using the Fedora default Bluecurve) extends too far to the right of the menu titles when they are active ("File", "Edit", "View", etc. I can't get a screenshot with the menus open, but compare the width of the highlight around "View" in Blizzard's screenshot (http://www.0xdeadbeef.com/html/2004/03/Screenshot-firefox.png) to one in a native Gnome app.