253661 - nine steps to better menus in Firefox

Status: RESOLVED FIXED

(Firefox :: Menus, enhancement)

Description

[Asa Dotzler [:asa]]

This may be partially covered by Firefox bug 243078 and browser bug 37694 but
this bug is to track Firefox improving the usability of menus by making style
and positioning adjustments. If we can do that by moving to nsITheme native
menus, great. If not, we'll need to see how much of this we can do in the
winstripe theme and minor XUL hacks. 

1. Sub-menus should be moved three pixels to the left and raised 4 pixels
vertically.
2. Main menu toolbar menu items need to have a blue highlight hover and click
style rather than the raised and depressed bevel button on highlight and click.
3. Menu border needs to be reduced to 1 pixel from the beveled 2 pixels.
4. Menu checkmark needs to be moved two pixels down and one pixel to the right.
5. Blue selection highlight for menu items needs to be moved down one pixel in
relation to the menu item label (or the label moved up within the highlight,
whichever you like.)
6. Topmost menu item in the menu needs to be raised 2 pixel vertically.
7. Padding below a menu item label and above a separator needs to be increased
by 2 pixels and the padding above a menu item label and a separator needs to be
increased 1 pixel.
8. The entire set of menu item labels need to be moved three pixels to the left.
9. Separators need to be at least two pixels wider, reducing the padding between
the ends of the separator and the right and left borders of the menu to 3 pixels.

Comment 1

[Asa Dotzler [:asa]]

Attachment: Before and After image

Comment 2

[Asa Dotzler [:asa]]

Attachment: zoomed in before and after showing specific problem areas

Comment 3

[Asa Dotzler [:asa]]

This is about aesthetics and, more importantly, usability. If we fix nothing
else about our menus, adjusting the position of the sub-menu really should
happen for 1.0. Current positioning makes hitting those menus extremely difficult. 

Comment 4

[timeless]

asa: you should also try windows classic theme, some of your points apply to
classic (correctly shifting the submenu up and left), some don't (colorizing the
menubar).

Comment 5

[miahz]

Attachment: patch: super-duper menus fix

This patch makes menus, submenus, menuitems, menu checkmarks, menu arrows,
menulists, etc. match their native counterparts on *Windows Classic*. 
Bookmarks in menus appear the same as before because i couldn't find any
consistent reference points in native programs, though their style rules have
been cleaned up a little.  Menu items in submenus align with their parents. 
Menulists (Options > General > Fonts & Colors has a lot) were also fixed - they
used to be too big.  Menubar items will now expand vertically to fill the
height of the toolbar (add a big button to the menubar) - this is an optional
usability hack.  While working on this i noticed that the radio icon is one
pixel too small in each dimension.

Not really sure what this all means for Windows XP (Luna) and other platforms -
i did this on Windows 2000.  Need some folks to test this out.	It may not hold
up with large fonts, or other non-default situations.

For those keeping score, this takes care of the following items on Asa's list:
1. Fixed.
2. NOT FIXED - see bug 243078.
3. NOT FIXED - see bug 243078.
4. Fixed.
5. Fixed.
6. Fixed.
7. Fixed.
8. Fixed.
9. Fixed.
10. NEW. Radio icon should be a 6x6 pixel dot, not 5x5.

Comment 6

[miahz]

Attachment: screenshot: results of menu fixes

I just found a few problems with menulists.  They seem to be using the "menu"
font, not the "message-box" font, but i'm not sure why.  And menulists with
images (Add Bookmarks dialog) have a few minor things with the spacing of the
icon.

Comment 7

[Asa Dotzler [:asa]]

miahz, can you attach a patch that just has the changes without the formatting
cleanup? reviewers might have an easier time reviewing that (and I'd like to
make it as easy as possible for them to review this if we're going to still try
to get it in for 1.0). Also, this is for windows classic only; are you sure it
has no negative impact on winXP?

Comment 8

[Simon Paquet [:sipaq]]

Asa, miahz could just make two patches. One as a normal unified diff with the 
-u switch. And another on with the -uw switch whcih would show just the content
changes and not the formatting cleanup.

Comment 9

[miahz]

(In reply to comment #7)
> ...are you sure it has no negative impact on winXP?

Asa, as i said - i did this on Win2k, and have no easy way to test on XP, so i'm
not sure what effect it has there.  I'll see if i can get to an XP box and set
up a patched version, but i'd be great if someone could test it out as well. 

(In reply to comment #8)
> ...just make two patches. One as a normal unified
> diff with the -u switch. And another on with the 
> -uw switch whcih would show just the content
> changes and not the formatting cleanup.

I'm using gerv's patchmaker script in windows via cygwin - so that's about all i
know about making patches - i don't really know about those diff switches.  I'll
just cook up a second "simple" patch.

Comment 10

[miahz]

Attachment: patch: super-duper menus fix (simplified)

I think this is about as basic as it gets, or else there begins to be redundant
rules.	I added a comment and tried to uncondense it as much as possible. 
There were just a lot of little changes that had to be made across five files.

Also - disregard my note about the wrong fonts in comment #6 - the program i
was using as reference was using the wrong font - it's actually correct in
Firefox.

Comment 11

[miahz]

Attachment: screenshot: before/after comparison of patch on XP

It appears to correct the same layout problems in XP as in Classic with no ill
effects.  If bug 243078's native menu styles in XP gets fixed, then we should
be all set.

Comment 12

[Grey Nicholson (they/them)]

(In reply to comment #11)
> If bug 243078's native menu styles in XP gets fixed, then we should
> be all set.

Bug 243078 has now been minused for 1.0.

Comment 13

[miahz]

(In reply to comment #12)
> (In reply to comment #11)
> > ...then we should be all set.

I should clarify - when i said "all set" i meant that the combination of these
bugs would produce native-matching menus.  But this bug is good to go on it's
own; it doesn't rely on bug 243078 - it just needs reviews on the patch.  The
only thing is i never know who to ask for reviews.

Comment 14

[Robert Parenton]

Comment on attachment 159666 [details] [diff] [review]
patch: super-duper menus fix (simplified)

mizah, I put a review request on your patch based on your last comment.  If I
put it on the wrong patch, please request review on the correct patch from the
same person.

Comment 15

[chris hofmann]

ben can you review?

Comment 16

[chris hofmann]

ran out of time for this one in 1.0.  need to minus

Comment 17

[Asa Dotzler [:asa]]

note that the minus isn't saying that we wouldn't take a reviewed patch, it's
just saying that we won't hold the release for this issue. 

Comment 18

[Simon Paquet [:sipaq]]

*** Bug 258213 has been marked as a duplicate of this bug. ***

Comment 19

[Andrew Saturn]

Attachment: menu on an inactive window

additionally, menus on inactive Firefox windows should use inactive colored
text.

Comment 20

[miahz]

(In reply to comment #19)
> Created an attachment (id=162643)
> menu on an inactive window
> 
> additionally, menus on inactive Firefox windows should use inactive colored
> text.

I don't believe this is currently doable with just theme CSS.

Comment 21

[Andrew Saturn]

(In reply to comment #20)
> (In reply to comment #19)
> > Created an attachment (id=162643)
> > menu on an inactive window
> > 
> > additionally, menus on inactive Firefox windows should use inactive colored
> > text.
> 
> I don't believe this is currently doable with just theme CSS.

so should I create a totally separate bug report for that? a search for
"inactive menu" returns zero boogs. a search for "inactive" finds bug 262389 -
which actually applies to Mac OS X... though it could be related I suppose.

Comment 22

[Simon Paquet [:sipaq]]

*** Bug 247311 has been marked as a duplicate of this bug. ***

Comment 23

[Bryan]

Confirming in latest trunk nightlies!

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614
Firefox/1.0+ ID:2005061405

Here is a current screenshot from the above build:
http://img21.echo.cx/my.php?image=unalignedmenus3cl.jpg

Bookmark dropdown menus also exhibit this bug.  A fix for this would improve the
look and feel of FF greatly in terms of OS integration.

Comment 24

[José Jeria]

Any special reason the patch that asked for review 8 months ago has not been
reviewed?

Comment 25

[Bryan]

Regarding comments 19, 20 and 21, this can certainly be done in FF (at least in
my  opinion) as it's done when you "customize" FF toolbars.

1) Right-click on the FF toolbar and click "customize"
2) Observe that the "File, Edit and View" menus are all "grayed" out!

Can we not use the same "technique" on every "inactive" FF window, like when you
open Tools-> Options?

This is inconsistent behavior...

Comment 26

[:Gavin Sharp [email: [e-mail]]]

Attachment: Updated

Updated to trunk, and a proper CVS patch.

Comment 27

[miahz]

Bryan emailed me asking about the "min-height" vs "_min-height" in the patch.  I
use underscores to temporarily disable properties while debugging CSS (it's
easier than using comments).  I guess i missed them when cleaning up.  The
min-height on the menubar was previously needed because the "innards" weren't
properly defined, but this patch fixes that, so it essentially became a
redundant rule.  So actually, it's safe to remove the second one for the
'toolbar[type="menubar"], menubar' selector.  But the first min-height on the
'toolbar' selector is needed to keep things kosher with empty toolbars
(customizing, etc.).  On the other hand, min-heights don't really do any harm in
this situation, so both could stay, as long as the underscores are removed.

Thanks for the fresh patch, Gavin.  Make sure to request review.

Comment 28

[Bryan]

Attachment: Specific problem areas remaining

With the updated patch the following need to be fixed if possible:

1) XP Luna: Main menu toolbar menu items need to have a blue highlight hover in
addition to click style rather than the raised and depressed bevel button
(needs to stay for Windows 2000 / XP Classic) on highlight and click.

2) XP Luna: Menu border needs to be reduced to 1 pixel from the beveled 2
pixels (needs to stay for Windows 2000 / XP Classic) - leaving a 1 pixel border
around the menu that's drawn as seen in the screenshot of IE.

3) XP Luna/Classic (& 2K): The "File, Edit, View" menu needs to move over about
a 1/32nd of an inch (don't know pixel wise) from the left and the spacing
between the menu "headings - File, Edit) need to be spaced out more as seen in
my second attachment.

4) The following code in the gavins updated patch:

.menu-text {
-  -moz-margin-start: 18px !important;
+  -moz-margin-start: 16px !important;
   font-weight: inherit;
 }

Needs to change to:

.menu-text {
-  -moz-margin-start: 18px !important;
+  -moz-margin-start: 17px !important;
   font-weight: inherit;
 }

To fix a spacing problem in drop-down menus with the "arrow-check mark" such as
View-> Status Bar.

Comment 29

[Bryan]

Attachment: Specific problem areas remaining # II

1) XP Luna/Classic (& 2K): The "File, Edit, View" menu needs to move over about

a 1/32nd of an inch (don't know pixel wise) from the left and the spacing
between the menu "headings - File, Edit) need to be spaced out more as seen in
my second attachment.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

Attachment: Updated - v2

This patch:
 - Corrects the min height error, per Miahz's comments
 - Addresses points 3 & 4 of comment 28 (hopefully)

Testing would be appreciated, on all platforms, especially XP Luna and Classic.

Comment 31

[:Gavin Sharp [email: [e-mail]]]

Attachment: Updated - v2.1

Really address point 4 of comment 28.

Comment 32

[miahz]

Regarding some of the recent comments, IE is actually NOT a good reference for
"native" menus (at least for classic).  Specifically with the menu bar - IE has
"floating" menu/toolbars that don't have the same specs as true native menubars
(extra padding, grippies, etc.).  A good reference to use is one of the stock
Windows apps like WordPad - which is the type of styling the measurements for my
original patch was based on.  Ironically, other Microsoft apps like IE and
Office can have some really weird menubars and menus.  Also note that this only
covers Windows Classic mode.  See bug 243078 for Windows XP/Luna issues.

Comment 33

[Bryan]

There are two issues remaining now:

1) Open the Bookmarks Manager and switch between BM and FF (ALT-TAB), you should
notice that the "File, Edit, View" menu jumps up by one pixel.

2) With the latest patch (v2.1), when you click on any of the main menu toolbar
items they click str8 down instead of down and to the right like IE or Windows
Explorer.  This was not the case BEFORE I began testing this patch.

Note: My previous issues 1) and 2) (comment 28) are addressed by BUG: 243078.

Comment 34

[miahz]

(In reply to comment #33)
> There are two issues remaining now:
> 
> 1) Open the Bookmarks Manager and switch between BM and FF (ALT-TAB), you should
> notice that the "File, Edit, View" menu jumps up by one pixel.
> 
> 2) With the latest patch (v2.1), when you click on any of the main menu toolbar
> items they click str8 down instead of down and to the right like IE or Windows
> Explorer.  This was not the case BEFORE I began testing this patch.

Can you test one of the other 2 patches ("Updated" or "Updated v2"), and see if
it's a regression with the latest 2.1 patch?  The changed .menu-text margins in
the 2.1 patch is what broke the click action from your #2 point.  The "click"
effect relies on 2 complementing values, so changing just the one breaks the
effect.  Not sure about #1 without testing it myself.  I'll try to grab a
nightly and play with the patches to see what's going on tonight.

Comment 35

[Bryan]

> Can you test one of the other 2 patches ("Updated" or "Updated v2"), and see if
> it's a regression with the latest 2.1 patch?  The changed .menu-text margins in
> the 2.1 patch is what broke the click action from your #2 point.  The "click"
> effect relies on 2 complementing values, so changing just the one breaks the
> effect.  Not sure about #1 without testing it myself.  I'll try to grab a
> nightly and play with the patches to see what's going on tonight.

I've tested the Updated, v2 and v2.1 of the updated patches Gavin modified.  I
believe the issue in my comment 33 point 2) is a simple regression.  I asked
Gavin if he could change the code for the "File, Edit, View" main menu toolbar
back to what it currently is.  I'm assuming he just deleted what was there or
something.  I can check with him tonight on IRC if he has the time.

Regarding your statements in comment 32, I guess we should determine what we're
looking to emulate?  If you look at Word 2003 you'll see something totally
different compared to Wordpad.  IE and Windows Explorer are virtually identical
in terms of the main menu toolbar and spacing for submenus.  I for some reason
thought we (FF) was looking to not only match the Windows look and feel but also
emulate/replicate IE to some extent only when it comes to menu / toolbar look
and feel.  Please correct me if I'm wrong.

Comment 36

[Asa Dotzler [:asa]]

re: comment (In reply to comment #32)
> Regarding some of the recent comments, IE is actually NOT a good reference for
> "native" menus (at least for classic). 

We're working to improve the visual display as well as the alignment and
location of the click/hover target areas for IE. Firefox is an IE replacement
and anything we can do to utilize the muscle memory of IE users and avoid the
little mentally confusing differences between Firefox and IE is the goal here. 

The goal is not to follow the native menu standard, but rather to emulate IE
since that's the app that we're replacing.

Comment 37

[Bryan]

> The goal is not to follow the native menu standard, but rather to emulate IE
> since that's the app that we're replacing.

That being the case then comment 28, 3) should be addressed to bring us inline
with the IE main menu toolbar in terms of spacing (see
https://bugzilla.mozilla.org/attachment.cgi?id=186765) - we're pretty close with
the change Gavin made to the initial patch.  Also, in that attachment
you should see a "separator" if you will that is drawn the full length of the
main menu toolbar right above "File, Edit, View, etc.".  If we could replicate
that then that would resolve one more spacing issue.

Also the spacing of keyboard accelerators (right term? talking about View-> Full
Screen     F11<--) should be addressed here if possible (I think Gavin said
there was another bug that addresses this?).  If you look at IE, the keyboard
accelerators are about 1/4 of an inch from the longest line in each of the main
menu, sub-menus.  We're all over the place with ours.

Comment 38

[Bryan]

> If you look at IE, the keyboard accelerators are about 1/4 of an inch from the
>longest line in each of the main menu, sub-menus.  We're all over the place
with >ours.

EEK!  Sorry, I meant to say 1/16 of an inch!  All references to 1/4 should be 1/16. 

Comment 39

[Bryan]

Attachment: menu.css diff's off the latest patch (v2.1)

This resolves issues discovered in the latest patch updated by Gavin.

Attachment 1 [details] [diff] of 2

Comment 40

[Bryan]

Attachment: toolbar.css diff's off the latest patch (v2.1)

This resolves issues discovered in the latest patch updated by Gavin.

Attachment 2 [details] [diff] of 2

Comment 41

[Bryan]

Attachment: Final changes.

The following issues have been resolved:
1. Fixed.
2. NOT FIXED - see bug 243078.
3. NOT FIXED - see bug 243078.
4. Fixed.
5. Fixed.
6. Fixed.
7. Fixed.
8. Fixed.
9. Fixed.

This is my first time doing this and I would like to thank, Gavin Sharp,
ISpiked (IRC), Unpresent (IRC, he did most of the new coding changes - thanks
man) and Miahz for all of the original code / patch work.  Also thanks everyone
for putting up with me!  :-)

Comment 42

[Bryan]

Requesting blocking1.8b4!

Comment 43

[Kevin Gerich]

Attachment: Bookmarks menu after patch on Linux

The only problem I see is that the Bookmark This Page and Manage Bookmarks menu
item text looks indented by a couple of pixels too much. It also looks like
Open in Tabs is indented too much as well.

Comment 44

[miahz]

I've been meaning to check over your latest updates, Bryan.  Does anyone know if
there's a checkin/freeze deadline we're shooting for?

Comment 45

[Bryan]

(In reply to comment #44)
> I've been meaning to check over your latest updates, Bryan.  Does anyone know if
> there's a checkin/freeze deadline we're shooting for?
Miahz, I'm hoping this will be part of 1.8b4 is at all possible but the freeze
is quickly approaching and then branch!!!

There are a few ppl looking over the code, including KMGerich and MConnor. 
There are a few potential issues on Linux.  We're working to resolve those as I
type this...

Comment 46

[Asaf Romano (gone)]

Comment on attachment 189498 [details] [diff] [review]
Final changes.

> .menulist-label {
>-  margin: 1px 3px !important;
>+  margin: 0 0 0 1px !important;

This would break the RTL case, please use:
margin-top :0;
margin-bottom: 0;
-moz-margin-start: 1px;
-moz-margin-end: 0;


>+menupopup > menu > menupopup,
>+popup > menu > menupopup {
>+ /* align submenus */
>+  margin-left: -3px;

ditto. please use -moz-margin-start.

Comment 47

[Bryan]

Attachment: Addressing Asaf Romano's comments...

(In reply to comment #46)
> (From update of attachment 189498 [details] [diff] [review] [edit])
> > .menulist-label {
> >-  margin: 1px 3px !important;
> >+  margin: 0 0 0 1px !important;
> 
> This would break the RTL case, please use:
> margin-top :0;
> margin-bottom: 0;
> -moz-margin-start: 1px;
> -moz-margin-end: 0;
> 
> 
> >+menupopup > menu > menupopup,
> >+popup > menu > menupopup {
> >+ /* align submenus */
> >+  margin-left: -3px;
> 
> ditto. please use -moz-margin-start.

Comments addressed!

Comment 48

[Bryan]

I've been testing the patched changes to classic.jar for more then a month
without any issues as have a few others (using the latest nightlies)

Gavin is working to update Gnomestripe (Reconciling the padding/margins in
browser.css and menu.css).

Comment 49

[Bryan]

Attachment: Combined patch.

GNOMESTRIPE PATCH: Hopefully this will bring Gnomestripe up to par with the
Winstripe changes this bug applies.  I have no way of testing this.  Changes
were made for me by Gavin.  Please contact either him (Gavin) or myself
(BoxerBoi76) on IRC (FF) or via email if need be.

The previous patch (One that addresses Asaf Romano's comments) is for
WINSTRIPE!

Comment 50

[Bryan]

I really need someone that can help test GNOMESTRIPE as I have no means of
testing the patch nor do I believe it's complete as only one change was made to
the GNOMESTRIPE menu.css by Gavin.  We've modified the following files in Winstripe:

browser.css
menu.css
menulist.css
popup.css
toolbar.css

I'm assuming the same changes would need to be made to the same files in
GNOMESTRIPE.  HELP!!!  :-)

Comment 51

[Bryan]

Comment on attachment 190347 [details] [diff] [review]
Combined patch.

In regards to GNOMESTRIPE only one change was made (menu.css).	I nor Gavin are
in a position to make the changes we did in Winstripe to GNOMESTRIPE. I need
someone to assist me in getting this done ASAP as this bug is blocking 1.8b4!!!

Comment 52

[Bryan]

I've been testing a patched classic.jar for close to two months now without any
issues on Windows XP in both classic and luna.

I really need someone that can help test GNOMESTRIPE as well as complete the
work needed to make the same changes in GNOMESTRIPE as we've made in WINSTRIPE!
 We've modified the following files in Winstripe:

browser.css
menu.css
menulist.css
popup.css
toolbar.css

I'm assuming the same changes would need to be made to the same files in
GNOMESTRIPE.  Let's get this done ASAP, so we can get this patch checked in.

HELP!!!

Comment 53

[Adam Guthrie]

I really don't think that Asa intended for us to make the menus look like this
on Linux. I think we need to fix the issue that kmgerich pointed out, and leave
it at that. The default GTK theme is not the same as the default Windows theme
and we shouldn't be mimicking it in this patch.

Comment 54

[Kevin Gerich]

Comment on attachment 190347 [details] [diff] [review]
Combined patch.

Does this obsolete the patch above it? I tested this and it looks fine with
Bluecurve. What does "needs further work" mean?

Sorry I took so long to test this.

Comment 55

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 189986 [details] [diff] [review]
Addressing Asaf Romano's comments...

Yes, this later patch supersedes the previous patch.

Comment 56

[Bryan]

(In reply to comment #54)
>What does "needs further work" mean?

If this resolves the previous issue on linux (
https://bugzilla.mozilla.org/attachment.cgi?id=189697 ) then this patch is ready
for checkin as far as I'm concerned.  I agree with comment 53 in regards to the
look and feel of FF on that platform.  I'll see if we can get this checked in ASAP!

Comment 57

[Bryan]

Comment on attachment 190347 [details] [diff] [review]
Combined patch.

According to comment 54 this is ok on Linux now per KMGerich.

Comment 58

[Bryan]

Combined patch checked in by " timeless%mozdev.org ".  Waiting on Pacifica to
spit out a new build!

Comment 59

[Jos Vermeulen]

I do not know if there's another bug filed for this, but it seems like this is
ideal bug to mention this.

Native Windows applications don't underline the "ALT-hotkey" unless you hold
ALT. Firefox always underlines them however. This is one of the most notable
"imperfections" when it comes to menus.

Comment 60

[Bryan]

(In reply to comment #59)
> I do not know if there's another bug filed for this, but it seems like this is
> ideal bug to mention this.
> 
> Native Windows applications don't underline the "ALT-hotkey" unless you hold
> ALT. Firefox always underlines them however. This is one of the most notable
> "imperfections" when it comes to menus.

That is a "feature" that was introduced in XP.  Right-click your desktop and
click on properties-> appearance-> effects-> "Hide underlined letters for
keyboard navigation until I press the Alt key".  Certainly I would think a fixed
could be created to give FF the ability to respect this setting.

Comment 61

[James Slaughter]

Attachment: Contrasted with native looking menu

The new theme beats my toolbar configuration with the ugly stick. Here's a
side-by-side comparision demonstrating the problems:
  1) the menu is too close to the left, which makes it lose definition against
     the frame.
  2) the menu highlight is not as Asa originally suggested, and has poor
contrast.
  3) the extra height of the menu makes things look weird. The menu is
separated
     by some margin from the text
It's nothing I *can't* live with, but like the ugly focus rects on list/tree
controls (try the bookmark manager), it makes the application feel less
comfortable than applications native to the OS.

Comment 62

[Bryan]

(In reply to comment #61)
> Created an attachment (id=192037) [edit]
> Contrasted with native looking menu
> 
> The new theme beats my toolbar configuration with the ugly stick. Here's a
> side-by-side comparision demonstrating the problems:
>   1) the menu is too close to the left, which makes it lose definition against
>      the frame.

This was part of nor caused by this bug but was "fixed" three or four weeks ago.

>   2) the menu highlight is not as Asa originally suggested, and has poor
> contrast.

The menu highlight is not part of this bug but is bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=243078

>   3) the extra height of the menu makes things look weird. The menu is
> separated

Is there an extension or something you've done that is increasing the height?  I
can't reproduce this without intentionally making it "higher".  What do you mean
by "The menu is seperated"?

>      by some margin from the text
> It's nothing I *can't* live with, but like the ugly focus rects on list/tree
> controls (try the bookmark manager), it makes the application feel less
> comfortable than applications native to the OS.

The "ugly focus rects" is not part of this bug but another "acessibility bug"
that was checked in a couple of weeks ago.

Comment 63

[Mike Connor [:mconnor]]

<snark>If you want the menubar to not be huge, try using Small Icons like you
are in IE</snark>

Comment 64

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #59)
> Native Windows applications don't underline the "ALT-hotkey" unless you hold
> ALT. Firefox always underlines them however. This is one of the most notable
> "imperfections" when it comes to menus.

That's bug 25894, and it's completely unrelated to this bug.

Comment 65

[James Slaughter]

(In reply to comment #62)
> (In reply to comment #61)
> >   1) the menu is too close to the left, which makes it lose definition > 
> This was part of nor caused by this bug but was "fixed" three or four weeks 

Fixed? To put it close to the left?

> The menu highlight is not part of this bug but is bug:
> https://bugzilla.mozilla.org/show_bug.cgi?id=243078

Thanks for the reference.

> >   3) the extra height of the menu makes things look weird. The menu is
> > separated
> 
> Is there an extension or something you've done that is increasing the height?  
> I can't reproduce this without intentionally making it "higher".  What do you
> mean by "The menu is seperated"?

Mike Connor pointed out the reason in his comment; I'm not using small toolbar
buttons and have the buttons adjacent to the menu. His snarkiness was misplaced
in so far as the difference in behaviour still exists when IE uses large icons,
and of course in that large icons is not an unreasonable configuration.

When I said 'separated', I meant that I expect the top edge of the popup to
appear immediately below the text of the menu name, as in the IE screenshot.
Instead, it appears aligned with the bottom edge of the toolbar. It's probably
because the highlight/selection size is different, which is part of the other bug.
 
> The "ugly focus rects" is not part of this bug but another "acessibility bug"
> that was checked in a couple of weeks ago.

Oh. :-(

Well, if everything is as you'd expect, there's nothing to worry about. Thanks
for clarifying, and for your work on this bug; I was just checking that it was
supposed to be that way.

Comment 66

[Grey Nicholson (they/them)]

(In reply to comment #0)
> 2. Main menu toolbar menu items need to have a blue highlight hover and click
> style rather than the raised and depressed bevel button on highlight and click.

This part still isn't fixed.

Comment 67

[Markus Faßbender]

Maybe you should do the same work for the classic.jar in Thunderbird, too.

Comment 68

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #67)
> Maybe you should do the same work for the classic.jar in Thunderbird, too.

That's clearly another bug, and not this one, since this bug is filed in a
Firefox component, with "Firefox" in the summary.

Comment 69

[Markus Faßbender]

I created a thunderbird specific bug for this issue.
See bug 304127

Comment 70

[Chris Cunningham]

(In reply to comment #66)
> > 2. Main menu toolbar menu items need to have a blue highlight
> > hover and click style rather than the raised and depressed bevel
> > button on highlight and click.
> This part still isn't fixed.

See Bug 303806 - this bug has morphed into doing it the Classic way and the 
two aren't currently compatible. Sorry for bugspam.

 - Chris

Comment 71

[Daniel C]

Attachment: Screenshot of FF and IE after bug 303806

Here are some screenshots comparing IE and the latest tinderbox build
(Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050907
Firefox/1.6a1) on Windows XP with Classic theme.

It shows a focused window, a focused menu, an unfocused window and a pull-out
menu with arrows and ticks.

Zooming in shows some subtle problems. FF has no left groove in all
screenshots. Menus are not greyed out in the disabled FF window. The arrows are
1 pixel too far to the left in FF from the left edge of the pull-out. The ticks
are 1 pixel too far to the right in FF from the left edge of the pull-out.

Hope this is useful (this is assuming that FF wants to emulate IE's menu
appearance, which I assume is true, since it uses a native appearance.)

Comment 72

[miahz]

The groove is a toolbar/toolbox issue, not menus.  Comment 25 mentioned a
possibility for "disabled" menus on non-focused windows.  Not sure if there's
anything new in that area.  The arrow graphics appear to be smaller in IE.  And
just looking at that screenshot, the menuitems are a few pixels too tall in
Firefox.  But since both this and bug 303806 are resolved, those issues will
probably have to go in a new bug.