304216 - Menu bar highlight too large

Status: VERIFIED WONTFIX

(Firefox :: Menus, defect)

Description

[Warner Young]

Starting with the 2005-08-08 (I think) daily trunk build of Deer Park, the menu
bar highlight rectangles are too large.  I'll attach screenshots of "good" and
"bad" versions.

Not sure which component is correct, so I picked "Menus"

This is on Windows XP using Windows Classic theme (i.e. not the Windows XP
"Luna" theme)

Comment 1

[Warner Young]

Attachment: "Good" menu highlight

Comment 2

[Warner Young]

Attachment: Menu highlight in recent nightlies

Comment 3

[Warner Young]

Possibly, this only shows up if the URLbar is moved up to the menu bar.  Note
that previously, the highlight box for a menu is tall enough to contain the menu
name, but leaves some room at the top and bottom.  With the latest nightlies,
this box is the same height as the menu bar/URLbar.

Comment 4

[Warner Young]

Looks like this may be fallout from bug 253661 patch.  However, I *am* using
Small Icons on my setup, to address Mike Conner's comment 63.

Changing version to Trunk, and severity to Minor, since this is really just a
cosmetic issue.

Comment 5

[Bryan]

(In reply to comment #3)
> Possibly, this only shows up if the URLbar is moved up to the menu bar.  Note
> that previously, the highlight box for a menu is tall enough to contain the menu
> name, but leaves some room at the top and bottom.  With the latest nightlies,
> this box is the same height as the menu bar/URLbar.

I only see this when I place the address bar on the menubar.  Otherwise it's fine!

~B

Comment 6

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

Brian, you made this change, is it necessary?

http://lxr.mozilla.org/seamonkey/source/browser/themes/winstripe/browser/browser.css#50

Comment 7

[Bryan]

(In reply to comment #6)
> Brian, you made this change, is it necessary?
> 
>
http://lxr.mozilla.org/seamonkey/source/browser/themes/winstripe/browser/browser.css#50

Gavin,

Patch coming right up to fix this!  Just need to create a diff and then attach
it.  Hopefully later tonight!

~B

Comment 8

[Bryan]

Removing this solves it in browser.css (can be removed without negative impact):

 46 #menubar-items {
 47   -moz-box-orient: vertical; /* for flex hack */
 48 }
 49 
 50 #menubar-items > menubar {
 51   -moz-box-flex: 1; /* make menu items expand to fill toolbar height */

~B

Comment 9

[Bryan]

Attachment: Restores previous menubar functionality in regards to a fixed menu item size...

Restores previous menubar functionality in regards to a fixed menu item size. 
No Risk, restores previous behaviour.

~B

Comment 10

[Mike Connor [:mconnor]]

-> kevin for handling

Comment 11

[Kevin Gerich]

This may have been an unintended consequence of bug 253661, but it's a fine idea
to have the menu items expand to fill the available space, even though they may
look a little odd along side larger icons. It's much better than having a menu
item floating in the middle of the toolbar with a non-clickable area above and
below it.

Marking wontfix

Comment 12

[Warner Young]

Kevin, I disagree, for 3 reasons:

1) Having a smaller menu item "floating" in the middle is how Mozilla/Firefox
has always behaved, so fixing it would simply be restoring old behavior.

2) Using your argument, the URLbar should expand to fill all available height if
I were to place a large icon on the same toolbar.  For example, in the attached
screenshots, you can see I have the back/forward buttons on the same toolbar, in
small icon mode.  If I uncheck "Use Small Icons" when I customize my toolbar,
the back/foward icons become larger, but the URLbar remains the same height, and
"floats" in the middle.

3) As I understand it, the default theme in Firefox is supposed to replicate the
look and feel of the host OS as much as possible.  If you do the same thing in
Internet Explorer, you'll find the menu bar items also "float" within the
toolbar, instead of expanding to use all available height.

Finally, from the sound of it, this isn't a complicated fix.  It sounds like a
simple CSS change fixes it, unless I misunderstood comment #9.

Comment 13

[miahz]

To clarify, that "flex hack" kinda snuck in on the initial menu updates i did
for bug 253661, and was carried on in the new patches.  It's just two simple,
harmless CSS rules.  Most people would never encounter a situation where they'd
be in-effect.

No, it is not "native" behavior, or anything that has been in previous or
competing products.

My thinking was to dynamically increase the clickable target area when there was
room to expand.  It's something i did in my own theme, and though it may look
odd, it does make it easier to use.  The URL Bar could just as simply expand to
fill the toolbar height - which would likewise make it easier to hit.

The stated mission is "to emulate IE since that's the app that we're replacing,"
but the reason for that is to make transition seamless.  I say if we can improve
things in a transparent way, then why not?  Windows hardly has any ui standards
- there are dozens of different menu "styles" even within just Microsoft's
products.  I would concede for other OSs that might have design rules for these
cases.

Not really arguing for or against this bug or patch or anything - just filling
in with some background info.

Bug 235277 raises a similar issue with the Go Button.

Comment 14

[Mike Connor [:mconnor]]

Agreed.  There's no reason to restore a smaller click target for cosmetic
reasons.  Its not unreasonable behaviour, and I agree with Kevin's call here.