233242 - [GNOME] hovering on the menubar should not activate the menus

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Pierre Chanial]

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

Comment 1

[Pierre Chanial]

Attachment: patch v1.0

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

Comment 2

[[e-mail]]

Are you referring to the "hover" effect?

Comment 3

[Pierre Chanial]

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

Comment 4

[Pierre Chanial]

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)

Comment 5

[Pierre Chanial]

forgot to cc reviewers

Comment 6

[Andrew Schultz]

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

Comment 7

[Pierre Chanial]

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

[Pierre Chanial]

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

Comment 9

[Brian Ryner (not reading)]

Attachment: how about this

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

Comment 10

[Pierre Chanial]

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.

Comment 11

[Brian Ryner (not reading)]

checked in.

Comment 12

[Brian Ryner (not reading)]

reopening to cover fixing the text color.

Comment 13

[Brian Ryner (not reading)]

Attachment: fix text color for active menus

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.

Comment 14

[Brian Ryner (not reading)]

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

Comment 15

[Steven Garrity [:sgarrity]]

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.